Inconsistent handling of keyframes when splitting a clip

Sometimes the splitting works as expected, with all of the keyframes of the second clip retimed so that they still happen at the same place in the video after being split.
But sometimes the keyframes get duplicated onto both clip without being retimed. Since the start of the second clip is after the split and keyframes are timed relative to the start of the clip, getting an exact copy of the first clip’s keyframes is often undesirable.

I would like to know why I’m getting two different behaviours when splitting clips that have keyframes.

1 Like

This is the same inconsistent and seemingly unpredictable behavior that I have experienced.

It has been so inconsistent and unpredictable that I have hesitated to report it as a bug; when asked “Is it reproducible?” I would have to say “No”, because I have not been able to determine which exact series of steps leads to the desirable result, and which series of steps leads to the undesirable result.

Let’s use this thread to try to find some steps that reproduce the problem. It is best to start with the bare minimum example if possible. But sometimes that is not possible - for example, maybe it only happens under certain complicated circumstances.

Can either of you suggest the frequency of the failure? Is it 1 out of 2 times or 1 out of 20?

1 Like


For me it has seemed like 1 out of 2; however, I rarely split clips after adding Keyframes, because of early bad experiences.

When I can find time, I will try to go back and find a project where I had problems and attempt to reproduce.

Also, as i go forward, whenever I use Keyframes, I will do a “Test” branch on my project, and try splitting the Keyframed clip.

My editing habits are fairly consistent, so the likelihood is high that eventually I will “do the same thing” that caused problems for me in the past.

1 Like

As I wrack my brain trying to remember, I think the worst case was when I was using SPR and Opacity on a PNG image to float the ghost of Nebuchadnezzar around the screen.

It may behave differently on an image than on a video clip.

I did some simple tests with brightness and position filters on an image. I added a bunch of keyframes to the clip and then randomly split it.

So far all of the splits have worked flawlessly.

1 Like

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


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.

Nice work, @RickyRister :grinning: :grinning: :grinning:

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:

  1. 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.

  2. 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