[FFmpeg-devel] [PATCH] Runtime detection for the number of processors/cores

Alexander Strange astrange
Thu May 22 00:22:52 CEST 2008


On May 21, 2008, at 6:05 PM, Roman Shaposhnik wrote:

> On Wed, 2008-05-21 at 17:45 -0400, Alexander Strange wrote:
>>> On a related note: I still don't quite understand why MPEG based
>>> codecs don't allow for higher degree of parallelism. Unlike DV codec
>>> which I've just tested on a nice Maramba box (2 CPUs, 16 cores,
>>> 128 execution units) and it scaled pretty much linearly to the
>>> # of cores, the MPEG based ones just refused to go higher than 4.
>>
>> They only scale to the number of slices in a frame, and then only to
>> the first 8 of those, I think. Adding slices is the only way to
>> guarantee parallelism in a codec like this, but it always hurts
>> compressibility, which is much more important.
>
> I see. That makes sense. Thanks for the explanation.
>
>> I'm working on it - for intra codecs frame-threading works perfectly
>> so far, but for all the other codecs with backreferences I ran into
>> some trouble with the buffer API. That shouldn't take too long to get
>> around, though, and then I can get on with reading mpegvideo.
>
> Is there any way of exploiting GOP properties of the stream as well?
> Or would it break the current model too much?

It can be done with a full GOP of decoding delay, but I'm guessing  
that would mess up most clients somehow. It'd be easier to just start  
two threads, open two decoders, and feed them separate GOPs, but then  
you still have to keep the later one around decompressed while you're  
waiting to play it. Could be useful for recompressing to some constant- 
quality codec, though.




More information about the ffmpeg-devel mailing list