Bug 429795

Summary: Kdenlive does not change the speed of image sequences correctly
Product: [Applications] kdenlive Reporter: Paul Brown <paul.brown>
Component: Video Effects & TransitionsAssignee: 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
SUMMARY

Kdenlive does not correctly speed up or slow down sequences of images imported into the timeline as a video clip.

STEPS TO REPRODUCE
1. Add an image sequence to the timeline
2. Right click on it and choose "Change speed"
3. Speed up the clip (say, by 200%) or slow it down (say, by 50%)

OBSERVED RESULT

If you choose to speed up the clip, say, by 200%, Kdenlive will just cut the sequence in half.

If you choose to slow it down, say, by 50%, Kdenlive will just repeat the sequence twice.

EXPECTED RESULT

Kdenlive should cut out intermediary frames to speed up the sequence or interpolate new frames between the existing ones to slow it down, instead of cutting it or repeating it.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Comment 1 emohr 2020-12-13 13:07:20 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.
Comment 2 Paul Brown 2020-12-13 19:13:16 UTC
(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.
Comment 3 Vincent PINON 2020-12-13 19:45:27 UTC
MLT speed change does not interpolate frames, for that you need an external tool like: http://slowmovideo.granjow.net/
Comment 4 Paul Brown 2020-12-13 20:58:20 UTC
(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.
Comment 5 Vincent PINON 2020-12-13 21:07:57 UTC
Sorry, thanks for the capital emphasis: I missed the "image sequence" aspect /o\ :D
Comment 6 Paul Brown 2020-12-13 22:14:29 UTC
(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.
Comment 7 Bug Janitor Service 2020-12-28 04:35:02 UTC
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!
Comment 8 Paul Brown 2020-12-28 10:07:46 UTC
Provided the info needed to Vincent. Than you.
Comment 9 Julius Künzel 2021-03-25 16:33:33 UTC
Is this a duplicate of https://bugs.kde.org/show_bug.cgi?id=392670 ? Of so please mark it as duplicate?
Comment 10 Paul Brown 2021-03-25 17:39:29 UTC
(In reply to Julius Künzel from comment #9)
> Is this a duplicate of https://bugs.kde.org/show_bug.cgi?id=392670 ?

No.
Comment 11 Julius Künzel 2021-04-02 17:55:05 UTC
*** Bug 428263 has been marked as a duplicate of this bug. ***
Comment 12 Julius Künzel 2021-04-02 17:55:53 UTC
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
Comment 13 Julius Künzel 2021-04-02 18:01:08 UTC
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
Comment 14 Thibault Molleman 2021-10-25 19:25:42 UTC
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
Comment 15 emohr 2021-10-26 14:32:29 UTC
BeforeBefore you open a new issue, try with the official AppImage to check if there are packaging issues with the Manjaro repo.