Windows 10.
The Crop:Rectangles position keyframe is broken. When the stopwatch icon is pressed the position and size coordinates are reset to zero. If the playhead is at the beginning of a clip one keyframe node is generated. If the playhead is at any other position, 2 nodes are created. One at the beginning of the clip and one at the playhead.
Mac OS10.11.6
Same observation as @Sauron
The new button for creating keyframes is very convenient.
However, it does not correct the creation of 2 keyframes at a frame interval.
I think that the calculation of the position of the playhead is different according to the section where we are. Maybe a different rounding calculation between 2 files?
See the video below. When I command the playhead from the source drive’s controls, it’s at 2; 16 sec. When I click on the button a keyframe is created at 2; 16 s, but the playhead moves at 2; 17 s https://streamable.com/42x97 https://streamable.com/42x97
In the next video, I do the same thing, but I position the playhead directly in the Keyframes title bar. The keyframe is well positioned at 3: 13 sec and the playhead remains at this position. https://streamable.com/ak6u4 https://streamable.com/ak6u4
When opening a project containing Keyframes, the “chronometer” button in the filter section is no longer selected.
I tried a project today with the same configuration as the last 8.
To know:
V1: Video 1920x1080 mkv format.
V2: SVG image with transparent template for marks.
V2: Song cover.
Effects in track V1: Video fade (input and output), Gain and volume through keyframes in the beginning and end of the video.
Normalization: two steps (-16 LUFS)
Effects on track V2: None (hidden)
Effects on track V3: Size and position to adjust the cover to its position. Video fade in-out
I exported with YouTube preset (as many other times), however, the video appears reduced. The resolution of the video is finally 1920x1080, but it’s really less because the content is framed.
Here I show an image.
I tested the project in the stable version and was able to export the video correctly.
This is the project in the beta version: Nik Kershaw.mlt (14.1 KB)
This is the project repaired when I ran it in the last stable version. Nik Kershaw - Reparado.mlt (13.1 KB)
Edition 2019:06:09
The problem does not seem to be related to any filter as I tried an export of a video without any filter or clipping and the video obtained was within a frame.
I tried disabling hardware encoder but the result was the same.
I created a new project to provide more data:
Data from the source video file: Video source data.txt (2.8 KB)
Additionally, I imported a wallpaper.png (1920x1080) I added it to the timeline and exported it to YouTube preset. The result was correct. The resulting video was not within a frame.
This is not a new problem and is intermittent. I need to spend more time on this, but fixing may require changing every filter UI, and this might not be done for the next release, which has some much more critical bug fixes to get out.
I do not reproduce this, and there might be something about your OS display or text size that is affecting this. Qt Quick, which is used for the UI is supposed to account for these sort of OS settings to prevent this, but this filter integrates some custom C++ widgets that may be affecting things.
That’s why I’m using the workaround I mentioned in another post.
The problem with this workaround is that it simply adds 150 to every filter UI’s (ui.qml) declared width. That is what we call a “fudge factor” and is not acceptable because then developers unknowingly start to configure the declared width with this constant in place and not remembering about it. Suddenly, you are back in the same place because, for example, something that should have been 450 is now configured as 300.
The problem with simply increasing the width and height of this filter is that it simply makes the custom circular control larger and require more space.
In qml/filters/color/ui.qml , can you please experiment with the lines that set implicitWidth for each ColorWheelItem? Maybe it needs something like -20 appended to each one because the current expression does not factor in scrollbars that might be showing.
Ah hah! Now, I did and reproduce it. Yes, the row of colorwheel labels has a minimum width requirement that is not satisfied. The following fixes it for me:
Does this fix also cover this bug when it happens with the mouse scroll wheel? @Namna had reported it before a couple of times here in this thread and also made a whole thread devoted to it here. I also have had the very same problem of two keyframes being created side by side when trying to create a new keyframe by scrolling the mouse wheel up and down.
No, it does not, and it is not the scroll wheel specifically; it is changing the value when frame-dropping is enabled. I just fixed it for the next version.
It seems the auto save feature is no longer working. The last files saved in the autosave folder are dated June 2, 2019. Since then no files have been added to that folder. I believe auto save was working in 19.04-30.