Bug 446373 - cut clip + change speed (speed up): first frame of new clip is wrong
Summary: cut clip + change speed (speed up): first frame of new clip is wrong
Status: RESOLVED DUPLICATE of bug 455504
Alias: None
Product: kdenlive
Classification: Applications
Component: Video Effects & Transitions (other bugs)
Version First Reported In: git-master
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-02 13:38 UTC by jean
Modified: 2026-02-09 21:48 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jean 2021-12-02 13:38:13 UTC
When cutting a clip, using the razor tool or shift-R, and then speeding up the new (right most) clip, the first frame of the new clip is "wrong" in the sense that it seems to be a duplicated frame from the left clip.

In my tests, I could see that the more I speed up the clip, the further back into the left clip the first frame is. (this is kinda hard to explain...)
This behavior results a very noticeable one frame "back in time" followed by the rest of the clip sped up.

For example:
- given a 3s clip at 4k 30fps (pretty sure it happened with other clips too, but that's what I have with me here)
- cut at the 00:00:02.00 mark
- speed up the last 1s part 400%
- The first frame of the last part is now the same frame as the one at 00:00:01.27 in the first clip
- ctrl-z
- speed up the last part 800%
- first frame is now the same as the one at 00:00:01.23

Strangely, with my test clip, if I speed up 700%, it seems to work fine, or at least skip forward instead of backwards.


SOFTWARE/OS VERSIONS
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
kdenenlive: built from git 2021-12-02
Comment 1 aristsakas 2026-02-09 21:48:21 UTC

*** This bug has been marked as a duplicate of bug 455504 ***