https://bugs.kde.org/show_bug.cgi?id=471156
--- Comment #13 from RuRo <[email protected]> --- 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). -- You are receiving this mail because: You are watching all bug changes.
