[FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 20:28, wm4 <nfxjfg at googlemail.com> wrote:
> Do I understand right that only your tests do this? And that there are
> no real world sites which do this? And that you want us to change our
> architecture so that your tests actually run?

I thought I had explained the problem in rather plain words easy to
understand. But obviously not :)

In FFmpeg, the default when you create a decoder is to create for
*that* decoder as many threads as there are core.
So on a quad-core machine, with hyper threading: that makes 8 threads.

So create two decoders: 16 threads. 3 decoders: 24 threads..

I can understand that the most common use of ffmpeg is to display
*one* video at a given time. I so wish it was that easy.

Now, as a web browser, our use is rather nowhere as simple. Their
could be hundreds of videos. You find web site setting a video to play
in the background that does nothing but change colours and give an
ambiance.

And then you have dozens of animated icons: all made using simple
video elements. Those web sites are found in the wild, it's not just
an internal test page. Actually our tests are typically based on
things actually found. Because noone is as good as a web developer to
break things :)

So yes, the current threading architecture of ffmpeg is inadequate for
our use. But it's not just *our* use. And as such, I wish we could
make it better.

The use of global thread pool is a sane (and much better) approach regardless.