SUMMARY Bug also already existed in 21.03.x. STEPS TO REPRODUCE 1. Open mkv file (source OBS) a) File has multiple audio tracks -- shouldn't matter but I have the strong impression that there are multiple other bugs related to that fact. So just FYI. 2. Shorten the clip at the end. 3. "Change speed" -- no difference due to execution: opt 1.) Hold Control-key and drag the clip border to slow the clip down. opt 2.) Right click the clip and select `Change Speed`. OBSERVED RESULT 1. Not sure about the correct wording but I would call it the video(-crop) is heavily "moved" inside the clip boundaries. Meaning: the unchangeable beginning of the clip which should be at the same time also 0:00 of the inherent video is suddenly 4:00 of the video without the possibility to extend the clip boundary (to the left) to the 0:00 mark of the video again. The clip is "convinced" that it is already at the very possible beginning of the video inside the clip even though it is *not*. 2. Clip previews stay the same. (There is/was a similar bug which claims to fixed that -- it's not.) 3. The time areas of the clip which "lost" video footage due to the heavy move of the video (to the "left") are rendered white. Example for clarification: * Video-1 = length 7:00 (m:s) * Clip-1 = cropped to 6:00 (with portion 0:00-6:00 of Video-1 inside) * After `Change Speed` applied to Clip-1 of now lets say 6:20 of length (because its slowed down = longer) starts the video suddenly at 5:00 and after 2.xx minutes runs out of footage since the original Video-1 only held 7 minutes of footage. So Clip-1 renders at mark 2:xx only white. 4. Movement of the video footage inside a clip appears random to me so far. EXPECTED RESULT obvious SOFTWARE/OS VERSIONS Windows: 7 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION * Sound does *not* seem to be effected. * Appears to me the same issue as this 5 years old bug: https://bugs.kde.org/show_bug.cgi?id=348148 * ..and this 6 years old "retired" bug: https://bugs.kde.org/show_bug.cgi?id=355003
I see "a lot of bugs" with OBS clips. Would it be possible to upload a test clip so I could test?
(In reply to emohr from comment #1) > I see "a lot of bugs" with OBS clips. Would it be possible to upload a test > clip so I could test? Okay, I found a file that is reasonable small and I could reproduce it pretty easily with that file. I stretched the file to about 96% speed et voilà: https://anonfiles.com/96ybQcw5u4/2021-05-16_040444.mkv_zip
Thank you for the file. With the nightly build CTRL+drag for change speed is working. Right click "change speed" changes the speed only for the particular track which is not correct. Can you check with the nightly build if you have the same behavior?
(In reply to emohr from comment #3) > Can you check with the nightly build if you have the same behavior? I've tested with Nightly 21.07.70 (kdenlive-master-769-windows-mingw_64-gcc) and the answer is: yes and no. Yes, for the particular file I've uploaded this seems to fix the issue but for the file I'm actually working with I would call it a clear regression. Not only it does not fix the issue (for my real file) but also just loading the file onto the timeline brings exactly the same issue I've described initially: the clip starts at about 30 s into the Video -- with out further do! Before that I could observe that the little loading bar below the file after you drag the file into the project window loads multiple times to 100% -- which I didn't observe on 20.04.xx. I would say it only should load one time to 100% as it did in the old version. But to be fair I'm not even sure if this is the version which is supposed to fix the issue. kde/kdenlive is all over the place: issue system here on bugs.kde.org, then a gitlab isntance on invent.kde.org with another issue tracker and finally even (a clone?) on github.com. Than I can/could find "Daily builds" somewhere (miss the link atm) as well as "Nightly builds" from a Jenkins instance. Please point me to the correct file and preferable please link the corresponding chnage/diff on github/gitlab if possible. I will try to reproduce the the same error in a smaller file.
The source code is here: https://invent.kde.org/multimedia/kdenlive/-/tree/master. Here you see all nightly builds in "Jenkins CI". ATM we implement a "task manager" to make "jobs" like "put a lot of clips into the project bin" more stable. The branch was merged here: https://invent.kde.org/multimedia/kdenlive/-/network/work%2Fjobmanager. I think this is a regression of implementing the task manager. We track issues for the developer here https://invent.kde.org/multimedia/kdenlive/-/issues. The bugtracker is for the "normal" user and for triage. All other sources are not official copies.
That's the first minute of the file that produces the shift in the video of an clip after speed change: 1. Drag file onto project window. 2. Accept project setting change. 2.1. Already noticed that ending thumbnail is white. 3. Drag file onto timeline. 4. Change speed of the file to 98% via Ctrl+pulledge (right edge). Though the impact seems to be smaller -- probably due to the shorter video/clip but it is still noticeable due to the de-sync in audio or actually in the video since the audio stays correct. (You can here the 5 peeps before the game starts and the "woosh" of the menues that fly out of screen even though the frames are "cut out".) File about 60 mb: https://anonfiles.com/J3BcL9xbud/change-speed-issue-first-minute_7z
@emohr: Why did you mark this backport? What am I supposed to understand under backport here anyway? You can only port this back (or be back ported) if you would maintain multiple versions which I guess kdenlive does not. I've test release 21.04.1 with my supplied (last) test file[1] and in contrast to the nightly/daily build instead of the video the audio graph is off-sync without further do. (Don't confuse with the audio itself which *is* in sync.) This is probably related to the fact that it seems there are about 5 seconds missing in the timeline of the 60 s of video. Okay I just for clarification: * The video is registered as exactly 60 s long in the project folder. (That's also how I cut it for the upload with ffmpeg. * If I drop it onto the timeline the clip is about 58 s long. * When I play/preview it the last frame get stuck at about 54.xx seconds then there is only "empty clip" with the stuck frame left. (This is without speed change.) Still you can simply break the video/clip further on the timeline by cutting of the clip at the end and change the speed by ctrl+drag to for example 98%. So the clip starts about 30 seconds into the expected video. The rest of the clip which misses video footage is rendered white as "usual". If you wanna flag it for somehting, flag it "timeline_curruption" because that's what it is clearly, isn't it? -- a clip with broken footage on the timeline. [1] https://anonfiles.com/J3BcL9xbud/change-speed-issue-first-minute_7z
Thanks for the hint about the flag; I just clicked the wrong flag. This is a good example of getting out of sync (audio/video) with change speed with more than 2 audio channels.
Not sure where I could upload the example file more permanently. Most (free) services delete after 30 days. Guess the easiest solution would be if some maintainer/dev grabs it and just fixes the issue. *hint* ;-) Re-upload 2021-11-06: https://1fichier.com/?aygs1zmchwsmkfv4uc8k https://ufile.io/imsjjbbm https://anonfiles.com/p85cbcT7ub/change-speed-issue-first-minute_7z