Summary: | Kdenlive does not change the speed of image sequences correctly | ||
---|---|---|---|
Product: | [Applications] kdenlive | Reporter: | Paul Brown <paul.brown> |
Component: | Video Effects & Transitions | Assignee: | Vincent PINON <vpinon> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | fritzibaby, julius.kuenzel, kde.lwzr1, leo |
Priority: | NOR | Flags: | fritzibaby:
timeline_corruption+
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Manjaro | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Paul Brown
2020-11-29 10:01:21 UTC
I tested with the 20.08.3 and it works. Please try with the current Kdenlive AppImage version 20.08.3b to see if there are any packaging issues https://download.kde.org/stable/kdenlive/20.08/linux/ If the problem/issue doesn't occur when using the AppImage, then it's your configuration or packaging. (In reply to emohr from comment #1) > I tested with the 20.08.3 and it works. Tested with kdenlive-20.08.3b-x86_64.appimage as you suggested, and, no, no it doesn't. Still broken. Grab a sequence with, say, 100 frames (like this one: https://cloud.quickfix.es/index.php/s/DeFmGriw9B5EofY). Change the speed to 50% and you will see that it just duplicates one sequence at the end of the other, instead of interpolating frames. > If the problem/issue doesn't occur when using the AppImage, then it's your > configuration or packaging. Confirmed that this is not so. MLT speed change does not interpolate frames, for that you need an external tool like: http://slowmovideo.granjow.net/ (In reply to Vincent PINON from comment #3) > MLT speed change does not interpolate frames, for that you need an external > tool like: http://slowmovideo.granjow.net/ Okay, I don't know how Kdenlive (or MLT) does it, but it is also not relevant to the bug. The point is that when I ask Kdenlive to slow down a VIDEO clip to, say, 50%, it DOES NOT CONCATENATE the clip twice (which is what it does with a SEQUENCE OF IMAGES). It slows it down to 50% of its speed. Do you agree that that is the expected behaviour? If so, isn't that the behaviour I should also expect when trying to slow down a sequence of images, instead of the current behaviour which has Kdenlive concatenating the sequence of images twice? In case I am not being clear for some reason: Kdenlive DOES NOT SLOW DOWN (OR SPEED UP) CLIPS MADE UP OF SEQUENCES OF IMAGES. It cuts the sequence short or concatenates one sequence after the other and this is a bug. Please try the sequence I provided and you will see the bug for yourselves. Sorry, thanks for the capital emphasis: I missed the "image sequence" aspect /o\ :D (In reply to Vincent PINON from comment #5) > Sorry, thanks for the capital emphasis: I missed the "image sequence" aspect > /o\ :D That's okay. I was wondering why we were not communicating. So, yeah, to reiterate: speeding up and slowing down works fine with _video_ clips, but does not handle clips made up by _image sequences_ correctly. Thank you for your patience. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Provided the info needed to Vincent. Than you. Is this a duplicate of https://bugs.kde.org/show_bug.cgi?id=392670 ? Of so please mark it as duplicate? (In reply to Julius Künzel from comment #9) > Is this a duplicate of https://bugs.kde.org/show_bug.cgi?id=392670 ? No. *** Bug 428263 has been marked as a duplicate of this bug. *** Git commit 5f65e06b45d802e92c0a26828f82745eb4c9c910 by Julius Künzel. Committed on 02/04/2021 at 17:40. Pushed by jlskuz into branch 'release/21.04'. Fix change speed for slideshow clips Related: bug 428263, bug 392670 M +7 -0 src/bin/projectclip.cpp https://invent.kde.org/multimedia/kdenlive/commit/5f65e06b45d802e92c0a26828f82745eb4c9c910 I think I fixed this now. However there is still a problem with the preview of reversed slideshows. We continue to track this at https://bugs.kde.org/show_bug.cgi?id=392670 It seems like it's not solved yet? Maybe it's triggered if the image sequence gets trimmed in the timeline? See this screenshare: https://streamable.com/6gsw90 As you can see the end of the image sequence on my timeline you see the robot has been build. But if I change the speed by 200%, you can see that at the end that the robot isn't build up yet even. So a lot of the footage is gone after the speed up. Should I make a new bug report or should we reopen this one? Kdenlive 21.08.2 (installed via the normal extra repo of Manjaro) Operating System: Manjaro Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.10-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1080/PCIe/SSE2 BeforeBefore you open a new issue, try with the official AppImage to check if there are packaging issues with the Manjaro repo. |