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

2016-01-13 Thread Jean-Yves Avenard
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

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

2016-01-08 Thread Michael Niedermayer
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/~cpear

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

2016-01-08 Thread Jean-Yves Avenard
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

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

2016-01-08 Thread Eli Kara
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

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

2016-01-08 Thread James Almer
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

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

2016-01-08 Thread Derek Buitenhuis
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-deve

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

2016-01-08 Thread compn
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

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

2016-01-08 Thread Jean-Yves Avenard
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 flame

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

2016-01-08 Thread Derek Buitenhuis
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

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

2016-01-08 Thread Jean-Yves Avenard
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 > websi

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

2016-01-08 Thread Kieran Kunhya
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 >>

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

2016-01-08 Thread wm4
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

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

2016-01-08 Thread Jean-Yves Avenard
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: Sa

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

2016-01-08 Thread Jean-Yves Avenard
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 ridiculin

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

2016-01-08 Thread wm4
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: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

2016-01-08 Thread wm4
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 ru

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

2016-01-08 Thread Jean-Yves Avenard
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 reason

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

2016-01-08 Thread Jean-Yves Avenard
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

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

2016-01-08 Thread Jean-Yves Avenard
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.

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

2016-01-08 Thread Jean-Yves Avenard
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

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

2016-01-08 Thread Michael Niedermayer
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

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

2016-01-08 Thread Andrey Turkin
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 wit

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

2016-01-08 Thread wm4
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 vide

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

2016-01-08 Thread Carl Eugen Hoyos
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 lik

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

2016-01-08 Thread wm4
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

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

2016-01-07 Thread Jean-Yves Avenard
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