[MPlayer-dev-eng] [PATCH]Add support for CoreAVC h264 codec

[Loren Merritt]

On Thu, 5 Oct 2006, Michael Niedermayer wrote:
> On Thu, Oct 05, 2006 at 10:58:58AM +0200, Guillaume Poirier wrote:
>>
>> I had a look at CABAC's code, and the greatest problem I saw with it
>> was in the algorithm itself. CABAC is an inherently serial (which
>> quite easily leads to pipeline bubbles) algorithm that processes
>> _bits_. ! That means that i.e. a 700Mb file requires  700*1024*1024*8
>> runs through cabac.
>> Maybe one sort of optimization that I could see would be to make sure
>> there's no pathological code such as partial register stall, etc...,
>> because every pipeline stall will really hurt performance because
>> nothing else can be processed during this time (as the algorithm is so
>> serial).
>
> one insane idea is to do CABAC decoding of 2 frames at once (patches
> welcome)

I considered that, but I don't see how it could work. The core cabac 
functions can't run in isolation, they need to be interleaved with the 
rest of the decoding process to tell which contexts to decode under, and 
the rest of the decoder needs the results from cabac in order to move on. 
So in order to decabac 2 frames at once, you'd need to run 2 decoder 
threads, and sync them at every cabac read.
Unless... not normal threads, but some purely userspace thread 
implementation without preemption (and which only saves the nonvolatile 
registers). One call to cabac switches to the other thread, a second call 
computes both, saves one result, and returns the other.
You'd still need to separate bitstream parsing from motion compensation 
since one frame will depend on the other. But I think CoreAVC does that 
already, as part of its SMP model.

> and maybe someone wants to try simply decoding 2 simple random CABAC
> streams at once, i mean not h.264 just simple random CABAC encoded streams

--Loren Merritt