On Thu, Apr 12, 2018 at 12:23 PM, wm4 <nfx...@googlemail.com> wrote: > On Thu, 12 Apr 2018 12:08:50 -0400 > Malcolm Bechard <malcolm.bech...@gmail.com> wrote: > > > Hey, > > > > I'd like to restart the conversation about a Shared Thread Pool in > FFmpeg. > > I found a past conversation about it here: > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186770.html. > > > > As far as I can tell there isn't a thread pool in FFmpeg so far, but I > > apologize if this has been solved already and I missed the solution. > > > > > > One of the contentious issues in that last conversation seems to be that > > there was few real-world examples where FFmpegs current behavior of > > spawning new threads for each decoder would cause issues. I'll provide > > another example: > > > > > > Live music shows often have a VJ (video jockey) that is performing live > > along with the performer/band. This is particularly true for electronic > > music, but is becoming more and more common for other music styles as > well. > > > > The application the VJ uses allows them to choose from banks of > > pre-rendered video, and blend/mix the layers of video in real time. What > > video is going to be played is selected in real-time by the VJ depending > on > > what they currently want to show the audience, based on what the > performer > > is doing. > > > > To make this possible, the app will need to have a large bank of videos > > already open and ready to play. 50+. These videos can not be opened when > > the VJ decides to play them, the 100ms+ of time it takes to open a video > > and allocate resources is far too slow for a real-time performance. So > > although they aren't playing 50+ videos at the same time, all of the > > resources those videos need to be played at an instants notice needs to > be > > allocated already. So, using a thread pool will greatly reduce the number > > of threads that need to be allocated here. > > > > > > The 50 videos they have in one bank is only one bank of many they have. > > They may want to switch banks and load up another set of 50 videos. Not > > having to spawn/kill new threads for every video that is opened will > > improve the performance of opening and closing of videos when switching > > banks. > > > > > > Most importantly though, decode performance. Since H264/H265 is not a > > constant-time decoder, it's impossible to know for sure how many threads > > you need for your video to be able to play it back in real time. Some may > > require 8, some may require 1, depending on the video content. To be safe > > the app should assign enough threads for a worst-case decode at that > > particular resolution. The VJ can mix all kinds of different videos at > the > > same time, multiple 4K videos, a mix of 1080p and 4K videos, some even > > smaller ones. It could be 2-4 heavy files or 12 light ones, or anything > in > > between. Without a thread pool this causes heavy oversubscription to the > > CPU cores, reducing performance. Avoiding oversubscription is exactly why > > most modern parallel applications utilize thread pools. > > > > > > To be clear, this usage case is already happening, and has been happening > > for a long time. Adding thread pool support will push the limits of what > > this use case can do even further. Yes, the need is there for that. > > > > > > Is there any interest in adding thread pool capabilities to FFmpeg? If I > > was to take on this work, would it be accepted into the code base? > Ideally > > the API would be such that the host application could provide it's own > > thread pool to be used (using callbacks), to avoid having two thread > pools > > allocated (and contending with each other for the cores). > > > > I'm perfectly fine with this being entirely optional, and programming it > in > > such a way that the existing threading workflow stays functional, if > there > > is a desire for that. > > I think the most contentious issue (apart from the pointless flame that > was not about how to implement it) was that there should be no global > thread pool. If a shared thread pool is e.g. explicitly set on an > AVCodecContext which should use it, that would be fine by me. > > Whether or not such a shared pool helps with anything is a different > question. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
Sure, making it something that is assigned per-context seems perfectly reasonable. Malcolm _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
