@remotion/compositor: Faster <OffthreadVideo> concurrency model

[JonnyBurger]

This re-architects the Rust binary that is being used for <OffthreadVideo> to properly multithread when using multiple streams are included.

This should by default improve the rendering speed of videos with picture-in-picture layouts or similar, and even makes it a bit faster when using 1 stream.

By default, 2 threads are allowed, but it can be increased or decreased using the new --offthreadvideo-video-threads option.

As always, it is not a good idea to set the concurrency too high, because FFmpeg already uses multiple cores for extracting frames already. Slowly ramp up the value and observe.

This option is designed for users with beefy machines such as high-core VPS-es. We encourage those to play around with the new offthreadVideoThreads option and find an ideal value.

Advanced, experimental option: Frames that are close to each other will still only cause 1 stream to be opened. That still makes sense, as otherwise using multiple threads is wasteful, because most frames in a video depend on other frames before and after.

However, one idea is that we can change the render so it does not render from start to end, but instead one tab renders the first half of the video and the second tab renders the second half of the video. Same idea with n > 2 tabs. This will force more streams to be opened concurrently.

To try out this idea, you can set the REMOTION_PARTITIONED_RENDERING=true environment variable.
We may remove this option in the future if it does turn out to make renders faster.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
bugs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 13, 2025 4:30pm
remotion	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 13, 2025 4:30pm

[tzvc]

Amazing work, I'll try that right away!