FFmpeg Lands CLI Multi-Threading As Its "Most Complex Refactoring" In Decades
The long-in-development work for a fully-functional multi-threaded FFmpeg command line has been merged! The FFmpeg CLI with multi-threaded transcoding pipelines is now merged to FFmpeg Git ahead of FFmpeg 7.0 releasing early next year. 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.
In recently sharing a technical presentation on the FFmpeg multi-threading effort, FFmpeg developers called this work "one of the most complex refactoring of the FFmpeg CLI in decades." And in calling for testing today added, "Please test and report issues to [FFmpeg Trac] - this is one of the most complex changes in FFmpeg ever!"
The code is now in FFmpeg Git. The patches include adding the thread-aware transcode scheduling infrastructure, moving encoding to a separate thread, and various other low-level changes. In culminating with converting FFmpeg to a threaded architecture is summed up as:
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.
In recently sharing a technical presentation on the FFmpeg multi-threading effort, FFmpeg developers called this work "one of the most complex refactoring of the FFmpeg CLI in decades." And in calling for testing today added, "Please test and report issues to [FFmpeg Trac] - this is one of the most complex changes in FFmpeg ever!"
The code is now in FFmpeg Git. The patches include adding the thread-aware transcode scheduling infrastructure, moving encoding to a separate thread, and various other low-level changes. In culminating with converting FFmpeg to a threaded architecture is summed up as:
fftools/ffmpeg: convert to a threaded architecture
Change the main loop and every component (demuxers, decoders, filters, encoders, muxers) to use the previously added transcode scheduler. Every instance of every such component was already running in a separate thread, but now they can actually run in parallel.
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.
21 Comments