Created attachment 159745 [details] Clip monitor 1.5X speed forward plays at 1X speed SUMMARY When I try to play a video at 1.5X accelerated speed I can't get it even though the interface shows me that the video is playing at that speed (1.5X) 1.5X is the only speed that fails. The other speeds (2X, 3X, 5.5X and 10X) work correctly at their respective speeds. STEPS TO REPRODUCE 1. Load a video to play it on clip monitor or project monitor 2. press the play button or space bar key to start playback 3. press the forward button or L key to increase the playback speed to 1.5X 4. press the forward button or L key to increase the playback speed to 2X OBSERVED RESULT 1.5X speed plays video at 1x speed. 2X speed plays video at 2X speed as expected. EXPECTED RESULT 1.5X speed should play video at 1.5x speed. SOFTWARE/OS VERSIONS Windows: 11 ADDITIONAL INFORMATION
Thank you for reporting. Yes, I can confirm this behavior. 1.5x times speed is the same as 1x speed.
*** Bug 455563 has been marked as a duplicate of this bug. ***
I have this trouble to, I'm using: Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 Kernel Version: 6.2.0-39-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i3-4150 CPU @ 3.50GHz Memory: 14.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4400 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: H81M-HD2 Kdenlive: Versión 23.08.4
With this fix I could load your project without crash. Please check with the daily build if it is opening on your end as well without crash: https://invent.kde.org/multimedia/kdenlive/-/jobs/1494939/artifacts/download
This comment is out of context
(In reply to emohr from comment #4) > With this fix I could load your project without crash. Please check with the > daily build if it is opening on your end as well without crash: > https://invent.kde.org/multimedia/kdenlive/-/jobs/1494939/artifacts/download This comment is out of context
Thanks. This comment was ment for bug no 472849.
Playback speed at 1.5x still fail in Kdenlive 24.02.0 Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-21-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i3-4150 CPU @ 3.50GHz Memory: 14.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4400 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: H81M-HD2 Kdenlive: 24.02.0
Playback 1.5x speed still fail in Kdenlive 24.05.0
Playback 1.5x speed still fail in Kdenlive 24.05.0 Operating System: KDE neon 6.0 KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-41-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i3-4150 CPU @ 3.50GHz Memory: 14.6 GiB of RAM Graphics Processor: AMD TURKS Manufacturer: Gigabyte Technology Co., Ltd. Product Name: H81M-HD2
Playback 1.5x speed still fail in Kdenlive 24.05.1
Can confirm, i never had 1.5x working on windows 11. In addition 2x has bad cracking sound no matter what combination of audio backend & driver.
FYI, I did some research, and it looks like this issue is probably caused by MLT (see, https://github.com/mltframework/mlt/issues/541). Kdenlive itself doesn't really implement the logic for playback speed, but rather just calls set_speed on the underlying MLT::Producer (https://github.com/KDE/kdenlive/blob/6ce22d3899a76d0605758939c738c6ca5c7eebec/src/monitor/videowidget.cpp#L1090). MLT producers store the speed as a double, but then they store the current location of the seek head as mlt_position (which defaults to int32_t). In order to compute the next frame, mlt does mlt_producer_seek(self, mlt_producer_position(self) + mlt_producer_get_speed(self)); and (position(int) + 1.5(double))(int) just gets rounded down to position + 1. So even though speed is a double, only integer speeds actually work. Also, even for integer speeds "work" is somewhat of an overstatement. My understanding is that setting the speed to 2.0 essentially causes mlt to play every second **frame**. Not every second audio sample, every second frame (!), so any speeds other than 1.0 in the preview playback ends up essentially chopping up the audio at 30/60 FPS, which sounds horrible. Unfortunately, it seems that this might not be easy to fix. MLT does have a compile option that changes the mlt_position type to be a double, however this option can't really be enabled, because it breaks both the internal and external API / ABI in many places (a lot of internal and external code just expects to receive ints, not mlt_position). In fact, the whole C++ API of MLT seems to use ints for positions and Kdenlive as a consumer of that API also just hardcodes int for position information. So, it looks like fixing this would require either doing a massive refactor of MLT and all of its consumers to use mlt_position instead of ints for positions everywhere. Or Kdenlive could switch to using some other mechanism for adjusting the preview speed instead of just doing set_speed() on the MLT::Producer (this is the preferable option, imho, since to my understanding set_speed on MLT producers wasn't really quite meant to be used for this).
*** Bug 509805 has been marked as a duplicate of this bug. ***