Bug 476659

Summary: Rendering a Reversed Clip is Extremely Slow
Product: [Applications] kdenlive Reporter: BoffinBrain <bugs.kde>
Component: Rendering & ExportAssignee: Jean-Baptiste Mardelle <jb>
Status: REPORTED ---    
Severity: normal CC: berndmj
Priority: NOR    
Version First Reported In: 22.08.2   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description BoffinBrain 2023-11-07 05:24:58 UTC 
SUMMARY

When rendering a video that has a reversed clip, the reversed portion of the video takes an extremely long time. I understand that most codecs are designed under the assumption that videos are played in a forward direction and thus i-frames depend on the preceding frames, thus a lot of seeking is necessary if frames are requested in reverse order. However, in my testing I found that rendering regular video could be around 30fps while the reversed section would be approximately 0.5fps. Surely there are some optimizations we can make to this process, and perhaps they can be applied to within the editor too for faster playback.

STEPS TO REPRODUCE
1. Add a clip to the timeline (recommended at least 5 seconds long) that's an MP4 video or similar.
2. Make a copy of it, place it after the first clip and reverse the clip.
3. Start rendering the project.

OBSERVED RESULT

Rendering the first half of the video is fast, while the second half is *extremely* slow.

EXPECTED RESULT

Speed for rendering the second half should ideally be within the same order of magnitude as the first half.

SOFTWARE/OS VERSIONS
Tested on Kdenlive 22.08.1 and 22.08.2
Windows 10
KDE Frameworks Version 5.110.0
Qt Version 5.15.10 (built against 5.15.10)
Comment 1 Bernd 2023-11-07 17:52:28 UTC 
(In reply to BoffinBrain from comment #0)
> Surely there are some optimizations
> we can make to this process, and perhaps they can be applied to within the
> editor too for faster playback.

Can you code this? Then contact the MLT team because this needs to happen in their engine, AFAIK.
Comment 2 BoffinBrain 2023-11-08 11:28:10 UTC 
> Can you code this? 
I wish I could, but that's way too low-level for me.
I would imagine one possible way would be to use some extra memory to cache all the frames decoded between one I-frame and the next one to eliminate repeated seeking and processing of the same frames.