[FFmpeg-devel] SOC Qualifiction tasks

Alexander Strange astrange
Fri Mar 14 20:20:29 CET 2008


On Mar 14, 2008, at 2:54 PM, Uoti Urpala wrote:
> On Fri, 2008-03-14 at 18:56 +0100, Andreas ?man wrote:
>> * Asynchronous decoding (I.e. decoding frames even when the caller
>>   is not currently in 'avcodec_decode_video()').
>>   Of course this must be fully hidden from the caller POV.
>
> You can't hide it from the caller. Normally the caller gives the frame
> data and expects full results before the call returns. With that API
> there is nothing to decode when the caller is not currently in
> avcodec_decode_video(). For asynchronous decoding you need a different
> API that allows the caller to queue frames in advance.

We can fit it in the current API by adding more decoder delay - it'll  
be sort of asynchronous (the first frame can start decoding when you  
submit it), but if you run into the maximum threads it'll have to  
block until the first decoding thread finishes.

I'm not sure what it would do to players that need one-frame-in-one- 
out; is that important?

>
>
>> * Add/Benchmark low level synchronization primitives.
>>   I'm thinking of using SFENCE, MWAIT and MONITOR on x86 for
>>   synchronization. In particular I think it would be useful when
>>   waiting for a particular MB to be completed in a reference (not
>>   yet fully decoded) frame. Ought to be much faster than pthread_
>>   -stuff.
>
> Do you really need to make the synchronization so finegrained that
> custom synchronization primitives would help? If you're calling  
> pthread
> routines so often that their overhead is significant you'll probably
> waste a lot of CPU on synchronization using any custom routines too.

I think we can just keep it at macroblock row level, for codecs that  
have macroblock rows. Some architectures might not have SMP cache  
coherency, so we will need synchronization primitives.





More information about the ffmpeg-devel mailing list