[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