Video caching improvement

[airon]

Problem

Reaper has a hard time getting data to the VLC playback engine or the FFMPEG libraries to keep up with the users actions of relocating the edit cursor a lot.

This behaviour becomes better if the bitrate and to a degree the complexity of the codec is lower. It gets worse when the bitrate of the video goes up. This was verified with H264, ProRes, Huffyuv and MJPEG. Reaper keeping up with the users actions such as click+dragging across a few seconds of material to find a specific frame became more viable when the bitrates went down.

PCM Audio 24 bit, 48kHz comes in at 1152 kBit.
Prores Proxy video at just 540p (the worst looking of the Prores family) comes it at around 15000 kBit. It seems Reaper is treating these equally, and it really should not do that.

The VLC player itself performs dramatically better. It delivers frames much more quickly than Reaper does. Scrubbing around in the video is pretty quick with that. This is easy to test for yourself by assigning keyboard shortcuts to the commands "Very short backwards jump" and "Very short forward jump" in VLC. If you wish, I can run a high-fps screencapture of this and send you the video.

Tests of running the video off normal hard disks and SSDs revealed that responsiveness dramatically improved on SSDs, but a wide gap of the seeking performance in Reaper and the seeking performance in VLC is still dramatic.

A lot of video for editorial in my case are Quicktime videos with a 15-30 MBit Prores Proxy codec without audio. Sometimes even more, usually not a lot lower.

Request

Some possible solutions. Cache a whole lot more data in advance for video items, scaling it up as the bitrate increases. Cache data around the current edit cursor preemptively.

Even better, cache the entire video if possible. The user could assign a maximum RAM usage for video caching.

You could also process video on multiple cores while in transport stop mode. The taskmanager clearly shows that this is what VLC does when seeking very quickly. I used all the seeking commands via keyboard shortcuts and the maximum keyboard repeat rate to verify this. With 15000 kbit Prores Proxy video, the CPU barely used a maximum of 12% on my i7 6700K. For transport-stop mode, I don't care what the CPU cost is. Responsiveness always wins here.

[svijayrathinam]

+1 for this.

[Eliseat]

+1

Yes, video should be a bit more optimized though in my opinion/feeling its more resolution dependent what slows down than bitrate dependent.

[bcslaam]

+1
Or the developers solution of choice to make video scrubbing respond fast

[analogexplosions]

yeah, big +1 from me too.

I've had the best results with both ProRes 444 and and DNxHD so far on a Windows 10 system.

To expand further on this, I think it'd maybe be a good idea for a caching system similar to a .reapeak file for imported videos. Doesn't really matter to me whether its a tiny math-based metadata sort of thing or if its a huge file with literal cached frames, I just want scrubbing video to be smooth.

It'd be worth whatever extra space it needed to make this happen.

AND...

Does VLC use GPU acceleration on Windows? If so, does its implementation in Reaper utilize this?

[_Stevie_]

Hey Airon,

this exactly sums up my findings! Very well done. I really hope for an improvement in that department.
Video responsiveness could be so much more competitive in Reaper.

[_Stevie_]

Solved in v5.963+dev1128 - November 28 2018!