[MPlayer-dev-eng] Regarding x264 decoding optimizations

[Guillaume POIRIER]

Hello,

On Jan 25, 2008 8:47 AM, Gautham Anil <gautham_anil at yahoo.com> wrote:

[..]

> The issue of lack of multithreading has been stuck in
> my head for a while and I have come up with a possible
> solution for 2 way multithreading. The idea is to make
> a pipeline similar to what processor designers use to
> increase speed of single thread processing.
>
> We can split the decoder into two stages - a just
> decoding stage and a de-blocking stage. With one extra
> buffer (with any data structures needed for
> de-blocking), we should be able to de-block a frame in
> one core while decoding the next frame in the other
> core. In addition or as an alternative, we can split
> the audio decode into another thread providing what I
> estimate to be adequate parallelism. If this can be
> done, 1080p will be fairly smooth in most dual core
> systems.

The problem with this methodology is that your divide the decoding
into an arbitrary number of threads (one for each stage to take your
analogy), each of these threads accounting for a different % of
decoding time (say CABAC would be 15%, deblocking 20% on a certain
sample, and 20%, 18% on another).
The problem with this aproach is that it doesn't scale with the number
of CPUs (i.e. you inherently have a fixed number of threads to
distribute to your CPUs, so you won't get any speed-up if you have
more CPUs than threads).

The "right" way to do it is frame-level multi threaded decoding (just
like x264 does for encoding), as Loren has said several times on
ffmpeg-dev mailing list (Google is your friend if you want the
details).
Sadly, implementing this is clearly uneasy, that's why it has never
been done up to now. :-

Guillaume
-- 
A soldier will fight long and hard for a bit of colored ribbon.
 -- Napoleon Bonaparte