| Summary: | Speed change has no effect on *.mlt files | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | Evert Vorster <evorster> |
| Component: | Video Effects & Transitions | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | e.vakhromtsev, fritzibaby, julius.kuenzel, karlfee, snd.noise |
| Priority: | NOR | Flags: | fritzibaby:
Brainstorm+
|
| Version: | 18.12.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | MLT_speed_lower-than-100% | ||
|
Description
Evert Vorster
2018-01-09 13:41:57 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- 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. 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. 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. 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.
I built the timeline refactoring branch from git today (2019-03-04) The issue is still present for me. I built mlt from git now as well, and now kdenlive does slomo properly. It seems that there was an issue in mlt. 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. 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. Please try with the current Kdenlive AppImage version 19.04.0: https://files.kde.org/kdenlive/release/ It contains MLT 6.15 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. "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 I have unfortunatelly the same results in Windows, with the latest kdenlive-19.04.0-2.exe and mlt 6.15 Ignore my comment #9. Thank you for the detailed feedback. Issue opened: Speed effect doesn't work with Library clips: https://invent.kde.org/kde/kdenlive/issues/166 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. 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. 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. Hi Evert, hopefully we can get this in 19.12.1 or .2 versions. 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)? 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! 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! |