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

[wm4]

On Fri, 8 Jan 2016 23:15:11 +1100
Jean-Yves Avenard <jyavenard at gmail.com> wrote:

> 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 :)

You did, but obviously I failed to express myself clearly.

> 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.

All libavcodec decoders can be used in single threaded mode. That means
it will run on your own thread, and libavcodec will not create extra
threads.

> 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.

A global thread pool sounds like an extremely messy and unclean
solution. The state of a library is not supposed to affect anything
else in the same process.

Maybe one could expose thread pools as explicit API objects, and pass
them explicitly to each decoder.