Bug 388729 - Speed change has no effect on *.mlt files
Summary: Speed change has no effect on *.mlt files
Status: RESOLVED WORKSFORME
Alias: None
Product: kdenlive
Classification: Applications
Component: Effects & Transitions (show other bugs)
Version: 18.12.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-09 13:41 UTC by Evert Vorster
Modified: 2021-04-23 04:33 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
fritzibaby: Brainstorm+


Attachments
MLT_speed_lower-than-100% (26.80 KB, image/png)
2019-03-03 13:48 UTC, emohr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Evert Vorster 2018-01-09 13:41:57 UTC
Hi there! 

It seems that the clip effect, "Duplicate with speed change" does not do slowmo.

It is quite easy to trigger. Load a clip of known length. Select clip job "Duplicate clip with speed change" and select 50%

The new clip produced is still the same length as the original, and plays at the same speed. 

Funnily enough, speeding up the clip works fine, as does reversing it.

I normally use SlowmoVideo to do my slow motions, I never ran into this one, it was reported on another bug of mine which deals with the speed effect on the timeline.
Comment 1 Evert Vorster 2018-01-09 13:49:38 UTC
It may be related, but it seems the speed effect on the timeline has similar issues as well. 

It speeds up video fine, and even does reverse video, but it does not actually slow video down. 

When applying 50% slowdown on the video, the length of the clip does not increase. It's possible to drag the clip longer, but the clip still plays at it's normal speed and the last frame is just duplicated to fill the rest of the clip length. 

Kind regards,
-Evert-
Comment 2 Evert Vorster 2019-02-24 06:34:53 UTC
This bug is still open & active

When applying a slow motion effect, the clip now becomes longer, but plays at normal speed, with the extra frames just copies of the last frame.
Comment 3 emohr 2019-02-25 16:53:06 UTC
I tried with AppImage 18.12.1b and Kdenlive Windows 18.12.1. In both versions it works well. The 50% MLT speed clip has double length and play halve the speed.
Comment 4 Evert Vorster 2019-02-27 07:14:12 UTC
Hi there. 

I tested again with the timeline refactoring branch, and there it is back to it's old behavior. This means clips play at 100% speed when percentages lower than 100 is applied, with the extra frames just padded with the last frame. 

When applying percentages larger than 100%, the clip job works properly. 

I have changed the version of kdenlive for this bug, as it is obviously fixed in the stable branches. Hopefully it rings a bell with our developers as to how it was fixed last time.
Comment 5 emohr 2019-03-03 13:48:00 UTC
Created attachment 118511 [details]
MLT_speed_lower-than-100%

I tried with refactoring AppImage#100. It works like expected. The 50% MLT speed clip has double length and play halve the speed.
Comment 6 Evert Vorster 2019-03-04 05:51:13 UTC
I built the timeline refactoring branch from git today (2019-03-04)

The issue is still present for me.
Comment 7 Evert Vorster 2019-03-04 05:55:35 UTC
I built mlt from git now as well, and now kdenlive does slomo properly. 

It seems that there was an issue in mlt.
Comment 8 Karl 2019-04-24 14:33:55 UTC
On half of my clips the speed-slomo effect works, on the other half it doesn't (Kdenlive 19.04 on linux with MLT 6.13).

- It works on clips or parts of clips that I moved directly from the project bin to the timeline. These clips have the same name as the actual movie-file (e.g. Cambodia.mp4)

- It doesn't work on clips that I moved from the Library to the project bin and from there to the timeline. These clips are named *.mlt in the timeline.
Comment 9 emohr 2019-04-24 15:39:04 UTC
If you run the installation try to update to MLT 6.14/15. If you run the AppImage wait until the update to MLT 6.15 is done. Then try again.
Comment 10 emohr 2019-04-24 15:53:48 UTC
Please try with the current Kdenlive AppImage version 19.04.0: https://files.kde.org/kdenlive/release/

It contains MLT 6.15
Comment 11 Karl 2019-04-24 17:01:40 UTC
Alright, did it now with 19.04.0 and MLT 6.15.0 (at least that's what the about-splash screen says). 

Same results:
- clips can not be sped up or slowed down when they have been added to the library before. When slowing down a *.mlt-Clip to 50%, the time doubles, but the last half of the clip is just frozen. 
- clips that have not been to the library can be sped up or slowed down.
Comment 12 Karl 2019-04-24 17:08:08 UTC
"If you run the AppImage wait until the update to MLT 6.15 is done. " 

What do you mean with that? How do I know when it's done? It shows 6.15.0 in the 'about' window of Kdenlive 19.04.0-x86_64.Appimage
Comment 13 Karl 2019-04-24 17:24:48 UTC
I have unfortunatelly the same results in Windows, with the latest kdenlive-19.04.0-2.exe and mlt 6.15
Comment 14 emohr 2019-04-24 18:22:55 UTC
Ignore my comment #9.
Thank you for the detailed feedback.
Comment 15 emohr 2019-04-25 15:25:05 UTC
Issue opened: Speed effect doesn't work with Library clips: https://invent.kde.org/kde/kdenlive/issues/166
Comment 16 Evert Vorster 2019-07-29 16:40:12 UTC
Looks like it is only .mlt files that can't be slowed down. 

I have made a new project, loaded a .mlt file, and tried to apply the slowdown with speed change clip job to it. The file that was created was exactly the same length as the source material. 

Workaround here would be to render (transcode) the .mlt file, and slow down the resultant render.
Comment 17 Evert Vorster 2019-09-12 04:44:27 UTC
Another workaround appears to first apply the speed changes, then stabilize the output video. 

:D

Funny that stabilize works on .mlt files, but speed change not. I even tried applying the effect on the timeline, but no dice.
Comment 18 Evert Vorster 2019-12-02 06:34:57 UTC
This behaviour is still present in the 19.12 release candidate, built from git on 2019-12-02

*.mlt files can not be sped up or slowed down.
Comment 19 farid 2019-12-02 16:40:55 UTC
Hi Evert, hopefully we can get this in 19.12.1 or .2 versions.
Comment 20 Julius Künzel 2021-03-24 17:52:50 UTC
Can you please check master again or update to the latest version  (20.12.3 at the moment, https://kdenlive.org/en/download/) and report here whether this is still happening (and set Status accordingly again)?
Comment 21 Bug Janitor Service 2021-04-08 04:33:25 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 22 Bug Janitor Service 2021-04-23 04:33:15 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now 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

Thank you for helping us make KDE software even better for everyone!