(Bug): Remedying ReadFFmpeg's performance

[YakoYakoYokuYoku]

Make sure to follow our issue report guidelines

• I'm using the latest version of Natron (not required but recommended)
• I've restarted Natron and the issue persists
• I've run Natron via the command line and the issue persists
• I've followed the contributing guidelines to the best of my understanding
• My issue is not on the issue tracker or in a pull request already (go search for it and dig around a little bit!)
• This bug is reproducible

Natron version

Natron 2.6.0

Operating system

Arch Linux

System specs

RAM: 15.6 GB
CPU: AMD Ryzen 7 2700
GPU: AMD Radeon R7 200 Series

Did you install Natron using the official installer?

• Yes, I used the official installer
• No, I installed from a binary archive
• No, I compiled Natron from sources
• No, I installed Natron via another method

Custom installation path

No response

What were you trying to do?

I'm trying to use videos with different Natron projects but both preview and render performances are awful. I've managed to find the cause to say the least.

What did you expect to happen? What happened instead?

Albeit I expect a certain overhead, this is quite larger rather than a small one. What's happening is that Natron renders frames in parallel and ReadFFmpeg goes to each one of them. Given that FFmpeg, and other video libraries in general, don't seek into a timestamp exactly in a $O(1)$ fashion but to its group of pictures and then to the objective frame, having a $O(n)$ time as result. If you do this for every frame then it's not surprising that your FPS drop abruptly.

Step-by-step reproduction instructions

1. Start Natron.
2. Create a node graph as you usually do here.
3. Place a video for it to be part of the composition.
4. Do a preview playback.
5. Or render the project.
6. See that everything is now poorly performant.

Additional details

This is rather trivial to fix, simply by having a cache of a size by the tens or hundreds frames can improve performance. At the cost of memory or storage though, but given the circumstances this is rather an acceptable tradeoff. For reference, even MLT does this. Why did I made an issue here? Because I need tips on which OpenFX suite to use and in case there isn't then for this is to be handled by a Natron host itself.

[devernay]

Actually, ReadFFmpeg is asking Natron to render sequentially by setting an OFX property here.

This property used to be honored by Natron, but I guess this behavior was broken by some changes?
Look for SequentialRender in the Natron code.

[YakoYakoYokuYoku]

I could see the repository blames on why sequential render preferences are ignored by Natron, but that won't make disappear the entirety of issues related to reading videos. A case on topic, if you render a video backwards, which is not an uncommon thing in productions, a sequential render would not help at all. In fact, it'd be detrimental because it'd be like doing a worst case of Bubblesort. Another examples are time manipulation effects, which are also pretty used out there, have the same issue.

What I'm putting forth is that frame caching is essential for video readers in editing and compositing. It's not a workaround or a hack, its use is completely grounded and justified. And I ask again if there's a possibility of doing this in the plugin via an OFX suite, much like MLT and GES do. Else, this would be done by Natron itself.