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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
