On 8 January 2016 at 23:27, wm4 <nfx...@googlemail.com> wrote: > Then don't create 30 threads.
This was just a silly example... There are time when you do want to use multiple threads, because someone is playing a single high-def video and a single thread wouldn't cut it. The conditions could change dynamically too: Say you had a thread pool of 8 threads ; when you have a single video to play, it can make full use of the processor. Something you can't achieve if you didn't create any threads at all. Now create a new decoder, they are still sharing the same pool, so about 4 each. The point is that as your amount of decoders climb there aren't an negative effect as opposed to not creating new thread, while when the decoder count drops: improvements do kick in. The advantages are so many that I'm even surprised I have to mention it... It's so obvious. Thread pools / task queues aren't messy. It's the modern approach taken by almost all highly parallelised and efficient applications. We certainly use them a lot in gecko (and webkit too) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
