Re:FFmpeg Lands CLI Multi-Threading as Its "Most Complex Ref...
by MightyBuzzard on Tuesday December 12, 2023 @03:45PM
(#38618223)
It's not the codecs that were multithreaded in this release. Pretty much all modern codecs are already multithreaded. What they decided to parallelize is ffmpeg itself. You know, the filter graphs and such. They didn't do anything to the codecs themselves.
Re:FFmpeg Lands CLI Multi-Threading as Its "Most Complex Ref...
by chrismsimpson on Tuesday December 12, 2023 @09:40PM
(#38621975)
I assume 1 process with 2 threads takes up less space on the die than 2 processes, both single threaded. If this is true, a threaded solution will always have the edge on performance, even as everything scales ad infinitum.
Re:FFmpeg Lands CLI Multi-Threading as Its "Most Complex Ref...
by LtdJorge on Wednesday December 13, 2023 @09:10AM
(#38627580)
Hardware threads are not the same as software threads.
Re:FFmpeg Lands CLI Multi-Threading as Its "Most Complex Ref...
by chrismsimpson on Thursday December 21, 2023 @01:48AM
(#38717772)
Thanks Capt Obvious
Re:FFmpeg Lands CLI Multi-Threading as Its "Most Complex Ref...
by LtdJorge on Friday December 29, 2023 @04:01PM
(#38810140)
I don't understand your comment then. I'm not trying to be sarcastic or anything.
Using either processes or threads should bear no difference in terms of die space. In a die there are cores, each core with dual streams of computation, that are interleaved to compensate for memory latency, so while one waits the other computes and vice versa. It doesn't have anything to do with processes or (virtual) threads, which are software constructs.
It wasn't that long ago that reading, processing, and rendering the contents of a single image took a noticeable amount of time. But both hardware and software techniques have gotten significantly faster. What may have made sense many years ago (lots of workers on a frame) may not matter today when a single worker can process a frame or a group of frames more efficiently than the overhead of spinning up a bunch of workers to do the same task.
But where to move that split now? Ultra-low-end CPUs now ship with multiple cores and you can get over 100 easily on high-end systems, system RAM is faster than ever, interconnect moves almost a TB/sec on consumer hardware, GPUs are in everything, and SSDs are now faster than the RAM I grew up with (at least on continuous transfer). Basically the systems of today are entirely different beasts to the ones commonly on the market when FFmpeg was created.
This is tremendous work that requires lots of rethinking about how the workload needs to be defined, scheduled, distributed, tracked, and merged back into a final output. Kudos to the team for being willing to take it on. FFmpeg is one of those "pinnacle of open source" infrastructure components that civilizations are built from.