Okay, I think I discovered a way to reproduce the problem.
Here we have a clip with keyframes
And it splits as expected
But add fade in video to the clip before splitting, and suddenly…
1 Like
Reproduced!
It happens when the Ripple Twins are used; it is a track that is NOT the one split and dragged, rather, one that was split and brought along by the use of both Ripple Twins.
It appears, so far, that nothing else causes this.
…
…
Oops, I spoke too soon.
Short version:
A clip split by being cuaght in the ripple does NOT have its Keframes split at the split; rather, it now has Keyframes starting at the split point with timings, not from that point, but from the original unsplit beginning of the clip.
If you had a clip with Keyframes at +0 frames, +5 frames, +17 frames, and +51 frames, and it was split at frame 40, you should habe a second frame with a split at frame 11.
That is what you DO get if this is the clip that was split explicitly.
But if that split was from the Ripple Twins, the second clip now has Keyframes at +0 frames, +5 frames, +17 frames, and +51 frames from its own new beginning, which has now correlation now with the video (and audio) content.
I reproduced this just now on an AUDIO track while splitting a VIDEO clip with the Ripple Twins.
(Photo details to follow.)
I have a project with Keyframes on the Gain filter on the Audio A1 track.
I split that A1 track explicitly, and move it may frames to the right, later in the video.
The earlier fragment clip is fine…
…and the later fragment of the clip is also good…
Notice how nicely Shotcut has split a rising Gain transition perfectly.
So Undo, Undo, Undo…
Back to the original unsplit state.
Turn on the Ripple Twins.
Split V2 and drag V2, and everyone else, to the right, later in the video.
Now we look at the send fragment of the A1 track, the piece that got split and dragged along with V2.
The pattern of these Keyframes bears no relationship with the audio.
It is exactly the pattern of the Keyframes in the original, unsplit video, but now reference to the wrong starting frame.
What version is everyone working with?
I tried to replicate the problem in an earlier version appimage, but the MLT will not open.
I think I read somewhere that the “Try it in an earlier version appimage” debuging tool was being taken away in the new release. (When “it” is an actual project, as opposed to a conceptual series of steps to be laboriously and identically, hopefully identically, reenacted.)
The previous times I have seen this were in earlier versions, dating nearly back to last Christmas, but I do not remember which numbered SaveAs of which project was where it occurred.
I’m not understanding the use of splitting the clip, and leaving it in place.
If it’s for adding another filter to the same clip, wouldn’t it just be easier to trim the filter, instead of splitting?
???
Who is splitting a clip and leaving it in place?
I was looking at the example in Post #7.
Ah, yes.
If one splits a clip. with the intention of moving it, and immediately after the split discovers that it is ruined, why proceed to move a ruined clip-fragment?
Two observations:
-
Post #7 was not “I tried to make a video and this stopped me”, it was deliberate search for circumstances in which the Keyframes did not behave in their usual way upon a split. So the particular procedure may have been a bit odd.
-
I am beginning to think that the problem reproduced in Post #7 and the problem reproduced in posts #8 & #9 are NOT the same problem.
I think I read somewhere (and I could be mistaken) that Keyframes and fades shared some of the same resources. If that is so, the post #7 problem would have an explanation unrelated to posts #8 & #9.
Also, if that is the case, I would hope that the pursuit of that issue would not obscure the issue of what happens when Ripple is used, splitting and moving another track.
I was able to reproduce the problem in an earlier version, by using the same clips and the same sequence of steps (but not the same project file, its a 5.01 thing…)
Keyframes before…
…make the Ripple split, acting upon V2…
…the Keyframes are now out of sync with the audio.
Note that the pattern of the Keyframed Gain is preserved in its entirety, now reference to the new beginning of the split-by-ripple clip, instead of referenced to the original mark in the audio.
What makes it seem a random occurrence is that the Keyframes are properly split and referenced when the split is directly upon the Keyframed clip. Since I usually use a single, full length audio track, Keyframed for “gain riding”, as the reference track for each of my videos, and use that as the selected track when I open the video up to insert branding and titles, Shotcut would usually handle the Ripple-split correctly. It was only when I split and dragged a different track, such as when i had two audio tracks instead of one, that all of the Keyframed gain-riding would be lost by the Ripple-split.
It seemed random - until today.
This is also my conclusion. I’m working on a fix for this - which I hope will resolve all the variations of this problem.
1 Like
Should this thread be moved to “Bug”?
1 Like
I have made improvements to this for the next release. Would anyone be willing to test this case with the 21.06 release candidate?
I used keyframes in Volume-Gain as a reference.
In my tests with the 21.06 release candidate under Linux Ubuntu Studio, the cuts and keyframes remained in sync.
I split the clip in half
First half
Second half
I included a second video track and curled all the tracks.
I cut at the same place and the results were identical (even separating the clips the keyframes were where they should be).
Curiously, another behavior appeared that I did not expect (and I don’t know if it is correct).
To join the cut clips again I use the function “merge with the next clip”.
This generates a duplication of the filters. While the second part of the clip keeps the full keyframe configuration, the first part was modified.
This is a good test. Thanks for doing this. The “crux” of the problem was when there are multiple filters applied, the keyframes would only stay in sync for the selected filter, but any other filters that are not selected would end up out of sync. So it would also be good if you could test with multiple filters.
Good testing. That is an edge case that I did not consider. I would have to think about the most “expected” behavior for this case. I’m not sure if I care to write complicated logic to try to “merge” filters when the clips are merged.
I carried out two tests, both of which were successful. 
I placed two video tracks (V1 and V2) with SPR filter on each track.
On each video clip (before splitting) I placed several filters:
Clip on track V1 :
-Levels (with keyframe adjustments of the three values)
-Vignette (with keyframe settings of the three values)
-Volume (with keyframe settings)
Clip on track V2
-“Tramado” (with keyframe settings)
I wrote down the setting values in 4 different sections: 10 - 15 - 25 - 40 seconds. I separated the clip in V1 in value 15 seconds with a ripple button for all tracks. I moved the resulting second section a few seconds forward on the timeline.
I compared the results at the reference points and all keyframe settings remained synchronized.
1 Like
In this case it is easy for the user (although perhaps cumbersome) to detect which filters are not correct because they have cut off duration (in the keyframe window).
However, if there is a clip with many filters, it can be easy to leave a duplicate filter.
The merge mode with the next clip I think, (at least in my case) is useful when after separating a clip, you save the project. Then you think of something else and when you open Shotcut, there is no more history to redo that, so merge with the next clip.
This topic was automatically closed after 90 days. New replies are no longer allowed.