Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 9 January 2016 at 01:37, Derek Buitenhuis wrote: > On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote: >> I will come on Monday if that's okay... could setup a time that works >> for you. I'm based in Melbourne Australia > > Most of the channel is usually around during daytime GMT/CET hours. > Happy to discuss this on IRC. My nickname is jya. I also typically hang in the #media mozilla channel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Sat, Jan 09, 2016 at 03:10:48AM +1100, Jean-Yves Avenard wrote: > On 9 January 2016 at 01:22, compn wrote: > > > i think mozilla should share one test page with the hundred elements so > > that we can see first hand the destruction. > > here is a simple one: > http://people.mozilla.org/~cpearce/stress/ > > For our test page: > http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video/object-fit-contain-webm-001.html > it contains 21 tiny videos, but when displayed very quickly with all > the ones found in > http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video, > you easily reach > 100 videos. > > > > > > does this also happen with webp ? e.g. if all images are vp8 webp and if > > you used libavcodec to decode them? > > we don't support webp, but it would be unlikely as we only need the > decoder once to get the image. After that it can be shutdown. > > > > > because 100 images would be a real world test, and it would explain why > > this is needed. > > > > i've seen html pages with 100 videos, thats just a forum with a music > > thread where people post youtube music videos. set forum to display 100 > > posts at a time and thats easily 100 video elements on one page, > > although of course not playing at the same time. > > they are indeed very common. > > Even more so in China. Lots of shiny, moving web sites there with > animated smileys, buttons you name it. at some low size and duration it would likely become more efficient to decode the video and store all decoded frames instead of keeping a decoder instance in memory to repeatly decode & cycle through the frames [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 9 January 2016 at 01:22, compn wrote: > i think mozilla should share one test page with the hundred elements so > that we can see first hand the destruction. here is a simple one: http://people.mozilla.org/~cpearce/stress/ For our test page: http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video/object-fit-contain-webm-001.html it contains 21 tiny videos, but when displayed very quickly with all the ones found in http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video, you easily reach > 100 videos. > > does this also happen with webp ? e.g. if all images are vp8 webp and if > you used libavcodec to decode them? we don't support webp, but it would be unlikely as we only need the decoder once to get the image. After that it can be shutdown. > > because 100 images would be a real world test, and it would explain why > this is needed. > > i've seen html pages with 100 videos, thats just a forum with a music > thread where people post youtube music videos. set forum to display 100 > posts at a time and thats easily 100 video elements on one page, > although of course not playing at the same time. they are indeed very common. Even more so in China. Lots of shiny, moving web sites there with animated smileys, buttons you name it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
Web applications are fast becoming more and more complex, it's no surprise. I do mainly sever side work but a bit client side. The amount of data in a web page's DOM can be huge. Many applications use videos in several places, this isn't a theoretical problem. And with people having 30 tabs open this really adds up. The demand for more complicated applications is getting larger as well, fast. Let web devs fine tune their pages if they're too bloated or inefficient but the browser should be able to make the most out of the HW in a smart way, so threading should be controllable. Threading should be determined by the client code. There should be an API to determine how many threads to use for a decoder or allow a thread pool with tasks for heavy intensive pages. There's no doubt this is needed, it's just a question of how to introduce such an API in a smart way. Sent from Eli's Nexus On Jan 8, 2016 4:23 PM, compn wrote: On Fri, 8 Jan 2016 10:51:39 +0100 wm4 wrote: > On Fri, 8 Jan 2016 09:42:52 + (UTC) > Carl Eugen Hoyos wrote: > > > wm4 googlemail.com> writes: > > > > > On Fri, 8 Jan 2016 17:55:38 +1100 > > > Jean-Yves Avenard gmail.com> wrote: > > > > > > > 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). > > > > > > Do I understand right that only your tests do this? > > > > I may have misunderstood myself but I believe the > > issue actually only happens on Windows XP;-) > > I suppose the larger memory usage would be considered a problem too, > and also can hit 32 bit boundaries even on non-XP. > > Anyway, as another point I would argue: > - discouraging web devs from creating too many video elements, and i think mozilla should share one test page with the hundred elements so that we can see first hand the destruction. does this also happen with webp ? e.g. if all images are vp8 webp and if you used libavcodec to decode them? because 100 images would be a real world test, and it would explain why this is needed. i've seen html pages with 100 videos, thats just a forum with a music thread where people post youtube music videos. set forum to display 100 posts at a time and thats easily 100 video elements on one page, although of course not playing at the same time. free file hosting / porn websites also utilize multiple video ads at the same time. easily using 16 video elements at the same time. i've seen many websites slow the web browser down to nothing with flash video (which is why i do not use firefox on many sites). asking web developers to not show so many video ads is a bit shortsighted imo. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 1/8/2016 11:22 AM, compn wrote: > does this also happen with webp ? e.g. if all images are vp8 webp and if > you used libavcodec to decode them? Firefox doesn't (yet) support webp. There's a very old bugzilla ticket about it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote: > I will come on Monday if that's okay... could setup a time that works > for you. I'm based in Melbourne Australia Most of the channel is usually around during daytime GMT/CET hours. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, 8 Jan 2016 10:51:39 +0100 wm4 wrote: > On Fri, 8 Jan 2016 09:42:52 + (UTC) > Carl Eugen Hoyos wrote: > > > wm4 googlemail.com> writes: > > > > > On Fri, 8 Jan 2016 17:55:38 +1100 > > > Jean-Yves Avenard gmail.com> wrote: > > > > > > > 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). > > > > > > Do I understand right that only your tests do this? > > > > I may have misunderstood myself but I believe the > > issue actually only happens on Windows XP;-) > > I suppose the larger memory usage would be considered a problem too, > and also can hit 32 bit boundaries even on non-XP. > > Anyway, as another point I would argue: > - discouraging web devs from creating too many video elements, and i think mozilla should share one test page with the hundred elements so that we can see first hand the destruction. does this also happen with webp ? e.g. if all images are vp8 webp and if you used libavcodec to decode them? because 100 images would be a real world test, and it would explain why this is needed. i've seen html pages with 100 videos, thats just a forum with a music thread where people post youtube music videos. set forum to display 100 posts at a time and thats easily 100 video elements on one page, although of course not playing at the same time. free file hosting / porn websites also utilize multiple video ads at the same time. easily using 16 video elements at the same time. i've seen many websites slow the web browser down to nothing with flash video (which is why i do not use firefox on many sites). asking web developers to not show so many video ads is a bit shortsighted imo. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 9 January 2016 at 00:39, Derek Buitenhuis wrote: > This seems to be a rather contentious subject. Would you be amenable to > perhaps joining #ffmpeg-devel to discuss in real time? In my experience, > stuff gets cleared up a lot faster, and with few misunderstandings / large > mailing list flames/threads, for subjects like these, in such a setting. > That's just my 2 cents of course. It's already Saturday here, and 1:20AM. So can't argue with much conviction :) As mentioned on #opus, be it a global pool, or a call back , or whatever context that can be shared across decoder, the end result is the same: share of resources across all decoders. I will come on Monday if that's okay... could setup a time that works for you. I'm based in Melbourne Australia ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 1/8/2016 6:55 AM, Jean-Yves Avenard wrote: > 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). FWIW, I have run into this on x64_64 Linux, on transcoding machines, at work, as well. This seems to be a rather contentious subject. Would you be amenable to perhaps joining #ffmpeg-devel to discuss in real time? In my experience, stuff gets cleared up a lot faster, and with few misunderstandings / large mailing list flames/threads, for subjects like these, in such a setting. That's just my 2 cents of course. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 23:43, wm4 wrote: > Sorry, the problem you're trying to solve is just too ridiculous. Welcome to the world wide web ! :) > Threads might be the heaviest resource here, but no matter what you do, > having hundreds of objects active at the same time (bring back geocity > websites from the 90ies?) will cause a memory and CPU resource usage > problem. So what if it fails on Windows XP. You do know that people using a web browser typically have more than one page or tab open at any given time. I have about 75 opened as I'm writing this. Of course not all of them have animated objects being displayed, but it's far from uncommon. So have 30 video elements in one page, or 1 in 30 pages, it's kind of the same issue. Ever used facebook? see how many videos or animated objects you can have in a discussion? Luckily not everyone think it's a ridiculous problem to solve and just gave up. Apple's VideoToolbox or Windows's WMF typically have a pool of surfaces and threads they share internally. I'm only suggesting that FFmpeg should consider doing the same, because it has more potential use than old fashion media player that only needed to worry about playing a single video at a time. > >> clearly haven't done much work on highly parallelised application, and >> who fail to even consider the problem. > > Maybe you're trying to argue from some sort of theoretical point of > view, but I'm thinking about practical issues, such as managing a > global thread pool. Regardless of "parallisation", for the problem at > this is also an overcomplicated and inefficient solution. Plus I didn't > even completely reject the idea of having some sort of thread pool. Have you ever used thread pools or task queue ? how could that ever be over complicated or inefficient? There are plenty of libraries providing them, heck you could use our own XPCOM to do it. As far as thread pools are concerned, it's very lightweight, far easier to use than pthreads and extremely efficient (which I could say the same for the rest of it). You feed it with runnables and it run them as best as it can (either sequentially or multiple at once if there are enough threads to service them) Please think about the problem more carefully, and reconsider. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 12:43, wm4 wrote: > On Fri, 8 Jan 2016 23:28:20 +1100 > Jean-Yves Avenard wrote: > >> On 8 January 2016 at 23:24, wm4 wrote: >> > >> > 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. >> >> The point of my message was to start a discussion, not to receive >> immediate answer ridiculing the idea and I have to say by someone who I think the idea of a threadpool is a good idea - we have usecases where we want to make a videowall of HD material with like 30 HD sources that need to all be deinterlaced then scaled etc. But it shouldn't be a global threadpool - it should be a generic threadpool that could even be used by non-FFmpeg tasks. Presumably you would attach it to a decoder and the decoder would use it (very handwavy I know). Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, 8 Jan 2016 23:28:20 +1100 Jean-Yves Avenard wrote: > On 8 January 2016 at 23:24, wm4 wrote: > > > > 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. > > The point of my message was to start a discussion, not to receive > immediate answer ridiculing the idea and I have to say by someone who Sorry, the problem you're trying to solve is just too ridiculous. Threads might be the heaviest resource here, but no matter what you do, having hundreds of objects active at the same time (bring back geocity websites from the 90ies?) will cause a memory and CPU resource usage problem. So what if it fails on Windows XP. > clearly haven't done much work on highly parallelised application, and > who fail to even consider the problem. Maybe you're trying to argue from some sort of theoretical point of view, but I'm thinking about practical issues, such as managing a global thread pool. Regardless of "parallisation", for the problem at this is also an overcomplicated and inefficient solution. Plus I didn't even completely reject the idea of having some sort of thread pool. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 23:27, wm4 wrote: > Then don't create 30 threads. This was just a silly example... There are time when you do want to use multiple threads, because someone is playing a single high-def video and a single thread wouldn't cut it. The conditions could change dynamically too: Say you had a thread pool of 8 threads ; when you have a single video to play, it can make full use of the processor. Something you can't achieve if you didn't create any threads at all. Now create a new decoder, they are still sharing the same pool, so about 4 each. The point is that as your amount of decoders climb there aren't an negative effect as opposed to not creating new thread, while when the decoder count drops: improvements do kick in. The advantages are so many that I'm even surprised I have to mention it... It's so obvious. Thread pools / task queues aren't messy. It's the modern approach taken by almost all highly parallelised and efficient applications. We certainly use them a lot in gecko (and webkit too) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 23:24, wm4 wrote: > > 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. The point of my message was to start a discussion, not to receive immediate answer ridiculing the idea and I have to say by someone who clearly haven't done much work on highly parallelised application, and who fail to even consider the problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, 8 Jan 2016 23:20:40 +1100 Jean-Yves Avenard wrote: > On 8 January 2016 at 20:51, wm4 wrote: > > Anyway, as another point I would argue: > > - discouraging web devs from creating too many video elements, and > > introducing a static "reasonable" limit (maybe a dozen elements) > > You're kidding right? So what, you just don't display the video > because really it was a silly idea in creating such page? This feels very weird. I'm complaining that you want web pages to create hundreds of video elements, and then I'm asked whether I'm kidding. Would you complain that a car doesn't move if you try to load it with hundreds of tons of stuff? Teach the web devs that some resources are just expensive, and everything will be fine. > The world is moving from Flash to HTML5. Those web sites exist > *today*, they are moving to html5 progressively (and we want to make > them move to html5) > > > > - not using MT for very small video (MT would probably make it slower > > anyway) > > Even with one thread per decoder, it's still not enough. Even by your > example, it would be silly to open 30 threads to play 30 videos when > your processor is unable to handle all those thread concurrently > anyway. Then don't create 30 threads. > A task queue would perform just as well with 4/30th of the RAM > (assuming you created the thread pool with 4 threads). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, 8 Jan 2016 23:15:11 +1100 Jean-Yves Avenard wrote: > On 8 January 2016 at 20:28, wm4 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 21:35, Andrey Turkin wrote: > example. I ended up disabling MT everywhere I can to fix that (which was a > right thing to do anyway since my program was already multithreaded and it > could use all the cores anyway). This thread-pool idea sounds reasonable to > me; more reasonable than 8-16 threads per codec anyway. Thank you ! :) Yeah, Win7 32 bits dies when your process attempt to open about 730 threads. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 20:51, wm4 wrote: > Anyway, as another point I would argue: > - discouraging web devs from creating too many video elements, and > introducing a static "reasonable" limit (maybe a dozen elements) You're kidding right? So what, you just don't display the video because really it was a silly idea in creating such page? The world is moving from Flash to HTML5. Those web sites exist *today*, they are moving to html5 progressively (and we want to make them move to html5) > - not using MT for very small video (MT would probably make it slower > anyway) Even with one thread per decoder, it's still not enough. Even by your example, it would be silly to open 30 threads to play 30 videos when your processor is unable to handle all those thread concurrently anyway. A task queue would perform just as well with 4/30th of the RAM (assuming you created the thread pool with 4 threads). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 20:42, Carl Eugen Hoyos wrote: > I may have misunderstood myself but I believe the > issue actually only happens on Windows XP;-) > > Carl Eugen Well the issue is mostly important on 32 bits system, particularly on windows where a user process can only use up to 2GB of RAM. But regardless of the OS or platform. Potentially having to create thousands of threads because you have lots of videos is a problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On 8 January 2016 at 20:28, wm4 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, Jan 08, 2016 at 01:35:02PM +0300, Andrey Turkin wrote: > 2016-01-08 12:42 GMT+03:00 Carl Eugen Hoyos : > > > > > I may have misunderstood myself but I believe the > > issue actually only happens on Windows XP;-) > > > > > I've encountered this issue a while back when trying to do about 20 > simultaneous transcodings with some video filters. It was on a high-end CPU > with a lot of cores so every codec and MT-enabled video filter would spawn > a lot of threads - can't remember exact number but hundreds of them. The > threads' stacks would eat up all of the process' address space causing OOM. > It was on Windows 7, and it's something you probably can call real-world > example. I ended up disabling MT everywhere I can to fix that (which was a > right thing to do anyway since my program was already multithreaded and it > could use all the cores anyway). This thread-pool idea sounds reasonable to > me; more reasonable than 8-16 threads per codec anyway. I think this problem and the effects of the thread number should at least be documented better. So other users running into this who maybe are not as knowledgable know what to tweak [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
2016-01-08 12:42 GMT+03:00 Carl Eugen Hoyos : > > I may have misunderstood myself but I believe the > issue actually only happens on Windows XP;-) > > I've encountered this issue a while back when trying to do about 20 simultaneous transcodings with some video filters. It was on a high-end CPU with a lot of cores so every codec and MT-enabled video filter would spawn a lot of threads - can't remember exact number but hundreds of them. The threads' stacks would eat up all of the process' address space causing OOM. It was on Windows 7, and it's something you probably can call real-world example. I ended up disabling MT everywhere I can to fix that (which was a right thing to do anyway since my program was already multithreaded and it could use all the cores anyway). This thread-pool idea sounds reasonable to me; more reasonable than 8-16 threads per codec anyway. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, 8 Jan 2016 09:42:52 + (UTC) Carl Eugen Hoyos wrote: > wm4 googlemail.com> writes: > > > On Fri, 8 Jan 2016 17:55:38 +1100 > > Jean-Yves Avenard gmail.com> wrote: > > > > > 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). > > > > Do I understand right that only your tests do this? > > I may have misunderstood myself but I believe the > issue actually only happens on Windows XP;-) I suppose the larger memory usage would be considered a problem too, and also can hit 32 bit boundaries even on non-XP. Anyway, as another point I would argue: - discouraging web devs from creating too many video elements, and introducing a static "reasonable" limit (maybe a dozen elements) - not using MT for very small video (MT would probably make it slower anyway) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
wm4 googlemail.com> writes: > On Fri, 8 Jan 2016 17:55:38 +1100 > Jean-Yves Avenard gmail.com> wrote: > > > 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). > > Do I understand right that only your tests do this? I may have misunderstood myself but I believe the issue actually only happens on Windows XP;-) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
On Fri, 8 Jan 2016 17:55:38 +1100 Jean-Yves Avenard wrote: > 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). 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? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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
