This, bellow, is not really a bug. Just a difference from the previous version. I don’t see mention of it in the fix/changes list.
In older versions, after splitting a clip in the timeline, the clip to the right automatically get selected.
In 21.06, no clip is selected after the split.
Version 20.05
Version 20.06
Whether this change is intentional or not, as far as I’m concerned, it’s an improvement. It used to take, say, half a second after the click for the clip to be cut, now it’s almost instantaneous.
Aside from that, even if I just started to test this new release, I find that it runs smoothly. I made a couple of exports from different projects, and they seem to be faster. In 21.05.18, I often experienced having to wait between 30 seconds to 60 seconds before an export would start, all the projects I exported with 21.06 started almost immediately.
Oh! and thanks for the Apply button in Properties. Works perfectly.
Shotcut 21.06.15 seems to be working pretty well for me (and an issue with the prior version where it froze up and required a reboot of the application– which it did pretty consistently – doesn’t seem to be happening).
I use Shotcut multiple times a week so I’ll let you know if any weirdness turns up.
As I mentioned earlier, I haven’t had an issues with Shotcut 21.06, though I noticed this behavior (which the screenshot I’ve included should help illustrate.
Notice that the lowest pane (level?) hasn’t been turned off, yet the image it’s supposed to show isn’t visible.
I have tried replacing it, but the particular file doesn’t seem to appear. As I said, I don’t know if this is a bug per se, though it is a behavior I don’t understand.
The same image has worked fine in other files (in Shotcut) so I don’t think this is a case of corruption of the particular file or a broken linkage.
I regret to report that the analysis of the stabilizing filter is still giving me problems.
I realized that it is not necessary to do several consecutive analyses. Just raise the precision set to 9 (or above) and the problem appears (and in this version Shotcut closes as well - something that didn’t happen in the previous stable version).
In the screenshot, the progress of the analysis is at 99%.
On the system monitor, it indicates that the processes Shotcut and melt 7 are running and waiting (alternately) until finally, Shotcut shuts down.
Even after Shotcut shuts down, melt 7 is still running for a while longer.
It is there and working. You cannot add Time Remap to the clips in a project created (or repaired) with a version older than 21.05.01. Or there could possibly be some situations where the filter is not showing due to a bug, but we need the steps because I do not know.
Yes, I am using projects created with versions prior to 25.05.01. I think the Snap installation only upgraded to the current stable version (21.03.21).
I will create a new project when I finish rendering my current work and comment here.
I got it. I created a new project and the filter appeared.
Dan and I both reproduced this. It tracks back to the latest version of the underlying stabilization library that Shotcut uses. The developers of that library have made a change that causes it to break for precision higher than 9. The Shotcut Windows build does not have this problem because it still uses an older version of the stabilize library.
We have a couple of options:
Revert the linux version back to the older stabilize library. That would make Shotcut incompatible with projects created with past Shotcut version before November
We could limit the precision parameter to be limited to 8 (or whatever the highest working version is)
We could remove the precision parameter and always fix it to a default value that works.
Do you have an opinion of the importance of this precision parameter? Does it make a lot of difference? Or could there be a default value that works for everyone?
Most of the time (and this is recent with two projects of my home SD PAL recordings) I use the default settings of the stabilize filter and it works fine. I don’t have much experience with this and unfortunately, I started to use this filter on footage that is perhaps not the most suitable.
In my current project (fireworks over the sea), the sudden brightness produces a very jerky movement with the stabilize filter, so in several scenes, I was trying different settings and that’s why I found that behavior with the precision.
Finally, the camera shakiness was less annoying than the sudden movement generated by the stabilising filter.
I don’t know if I interpreted the stab filter documentation correctly, but I think it says that the default value is 15 (from a range between 1-15).
In my case, there was no appreciable difference that would make me decide that I need an analysis precision higher than 8 (but this is my case and I was using the filter with two SD PAL projects).
Hello:
I was wondering if there is a reason why different filters with keyframes, have different track heights.
I thought that perhaps filters with multiple keyframe values spread the height between them and filters with only one adjustable keyframe value might take up more height, however this doesn’t seem to be the case.
Some examples:
Small height
The track height is set to its default value. Still there are these differences.
Additionally, filters whose keyframes are displayed on a reduced height track are those that do not include a range setting value to the left of the track and are also those that do not display lines between keyframes. Is this expected behaviour?
Yes. Keyframes for complex parameters like the colorgrading colors and rectangles do not allow manipulation in the keyframes panel. So they can have a shorter height in the keyframe panel. Keyframes for simple parameters can be manipulated in the keyframes panel - so they need more height.
I will not be too heavy with this to argue otherwise knowing all theall the work you developers do at Shotcut , and that the resources are surely better used in other developments. I understand that.
I just found it strange (in my inexperience) because as seen in the screenshots, the filters with reduced height in the keyframes panel, is so tight that it even seems that the icons almost do not fit.
I still don’t see the advantages of having that short height by default, if there are other filters with normal height (with the same complexity).
Also, since it happens in filters with only one keyframe field, it doesn’t seem to be space-saving (as it could happen in filters with 3 or 4 stacked keyframe fields) that are displayed at the same time in the keyframes panel.
Here is an example of two filters where I don’t understand why that difference in height.
Brightness
)
