[FFmpeg-devel] SOC Qualifiction tasks
Loren Merritt
lorenm
Fri Mar 14 20:52:17 CET 2008
On Fri, 14 Mar 2008, 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.
Codecs with B-frames have to support a delay anyway. Frame threading
(asynchronus or not) just increases the delay.
OK, so it breaks MPlayer's simple IPB direct rendering model for the
same reason h264 B-pyramid does.
>> * 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.
MWAIT and MONITOR are priveledged instructions. Maybe they're used in
the implementation of pthreads on your system, but they can't be invoked
directly by lavc. Any custom synchronization would have to revolve
around fences.
> 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.
We have to synchronize once per row of macroblocks. (We have to check
every mv, but only an average of once per row will the check fail.)
--Loren Merritt
More information about the ffmpeg-devel
mailing list