[FFmpeg-devel] SOC Qualifiction tasks

[Andreas Öman]

Michael Niedermayer wrote:
> On Thu, Mar 13, 2008 at 05:38:39PM -0400, Alexander Strange wrote:
> [...]
>>>> Should we find a mentor first if we want to do something that's not  
>>>> on
>>>> the projects list? I'd like to try frame-based multithreaded decoding
>>>> using x264's method, but haven't worked out the details yet.
> 
> Frame-based multithreaded decoding would be nice for h.264, it also would
> be nice for the other decoders

Yes, the threading framework needs to be boosted so most (all?) video
codecs can take advantage of it.

This is just some random thoughts, it obviously needs to be further
quantified and discussed.

* 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.
   I believe it's good to start decode frames as soon as you get them,
   rather than waiting for all frames (up to the maximum concurrency)
   to arrive.

* Various helper functions for management of frames in this process.

* Helpers for waiting for a particular MB (or line) to be completed
   in a reference fame.

* 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.

* Fix various shared code that's currently not MT-safe (I can only
   think of av_log() right now, but perhaps there is more?)
   A code audit might be good...

I'm not sure how slow it will be without the SFENCE,MWAIT,MONITOR
stuff. But I can imagine that sprinkling MC-code with pthread_-
stuff would be fairly bad.

It might be also be wise to start with a less complex codec than
h264. Perhaps I-frame only initially (but still decode frame
asynchronously, etc)