[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #9 from Veps --- 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 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 emohr changed: What|Removed |Added Flags|Backport+ |Brainstorm+, ||timeline_corruption+ --- Comment #8 from emohr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #7 from Veps --- @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 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #6 from Veps --- 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 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #5 from emohr --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #4 from Veps --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 emohr changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 Flags|timeline_corruption+|Backport+ --- Comment #3 from emohr --- 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? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #2 from Veps --- (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 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 emohr changed: What|Removed |Added Flags||timeline_corruption+ CC||fritzib...@gmx.net --- Comment #1 from emohr --- I see "a lot of bugs" with OBS clips. Would it be possible to upload a test clip so I could test? -- You are receiving this mail because: You are watching all bug changes.
