[FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
Jean-Yves Avenard
jyavenard at gmail.com
Fri Jan 8 07:55:38 CET 2016
Hi
This is a discussion you guys may already have discussed about this, I
apologise in advance if that is the case (and thank you for pointing
me to it if that's the case).
I work for Mozilla, in the media playback team of gecko.
In Firefox, we've finally moved to use ffvp9 and ffvp8 in place of
libvpx for video decoding. Should be available in Nightly shortly
(ffmpeg was already used if available in 43 and later on Linux). So we
now ship ffvp9 and ffvp8 in our code tree. Likely make us the biggest
user of ffvp9 at once ! :)
One of the issues we've faced was with our reftest tests , with pages
creating hundreds of small video elements (the test change
orientation, sizes, transparency and the like and check that there's
no regression on how things are displayed).
We originally had configured AVCodecContext::thread_count to 0, which
on the machines running the tests would end up creating 8 threads per
decoder.
On windows 32 bits, that would amount in thousand of threads being
created for that particular test which would typically fail with OOM
(Windows XP would fail to create more than 1380 threads).
We've worked around the problem by limiting the number of threads per
decoder (the amount varies according to the video resolution)
However the issue remains, in that the current way threads are used,
it won't scale well.
We've seen more and more web page, replacing all their tiny flash
video elements with HTML5 webm or mp4 ; so the more time goes, the
more it will become a problem.
Rather than setting the number of threads per decoder, independently
of any other decoders created ; what about using a global thread pool
with task queues instead ?
The thread pool could be created with a set amount of working threads,
something global.
When a decoder is created, rather than using N threads, it uses N task
queues (all task queues sharing the same thread pool). When it needs
to perform a particular operation, it would dispatch a task (of course
it can dispatch multiple task at once)
This would solve the problem of scalability, having hundreds of
decoders live wouldn't put the system to its knee like it does now.
Would this be something any of you guys would be interested in tackling ?
If not and I was to work on something bringing this functionality,
would it have a chance to be integrated?
Thanks
Jean-Yves
More information about the ffmpeg-devel
mailing list