- cross-posted to:
- ffmpeg
- [email protected]
- [email protected]
- cross-posted to:
- ffmpeg
- [email protected]
- [email protected]
This should eventually make it’s way into jellyfin. Eager to see the performance improvements.
You must log in or register to comment.
As far as I’m aware this is only for the cli version of ffmpeg and won’t affect the threading of codecs many of which were already multithreaded.
It’s literally for the CLI yeah.
I recently tried figuring out how to build ffmpeg with Nvidia codecs. I’m very new to ffmpeg and codec terminology. How is multithreading for the CLI different than the codecs?
My understanding is some parts have to be done sequentially even though the parts themselves are multithreaded, now the different parts can all be done in parallel.
Change the main loop and every component (demuxers, decoders, filters, encoders, muxers) to use the previously added transcode scheduler.
The components are what they have parallelised.
This is the best summary I could come up with:
The long-in-development work for a fully-functional multi-threaded FFmpeg command line has been merged!
FFmpeg is widely-used throughout many industries for video transcoding and in today’s many-core world this is a terrific improvement for this key open-source project.
The patches include adding the thread-aware transcode scheduling infrastructure, moving encoding to a separate thread, and various other low-level changes.
Change the main loop and every component (demuxers, decoders, filters, encoders, muxers) to use the previously added transcode scheduler.
There’s a recent presentation on this work by developer Anton Khirnov.
It’s terrific seeing this merged and will be interesting to see the performance impact in practice.
The original article contains 226 words, the summary contains 103 words. Saved 54%. I’m a bot and I’m open source!