[FFmpeg-devel] [PATCH] h264 parallelized

[Michael Niedermayer]

Hi

On Wed, Sep 05, 2007 at 10:03:09AM +0200, Andreas ?man wrote:
[...]
> > Can someone give me a hint what is still missing for parallel decoding
> > respectively what is blocking it?
> 
> This has been discussed before and there are various ways forward.
> 
> 1) Frame based parallelism (decode entire frames in parallel).
>     pros: Independent of slice partitioning and loopfilter
>     cons: Increased delay (dunno if it's a real issue though)
> 
>    I'm gonna have a look at this once (if) the PAFF-code hits the street.
> 
> 
> 2) Do entropy-decoding in a 2nd thread.
>     pros: Independent of slice partitioning and loopfilter
>     cons: Needs to be carefully tuned to avoid cache ping-pong effects,
>           the effect on calvc-content is probably also low.
>           Might be a bit too intrusive to the current code.
> 
>    Personally, i don't believe very much in this one.
> 
> 
> 3) Option to postpone deblocking till after the frame is fully decoded.
>     pros: Independent of loopfilter, probably easy to implement with
>           current code.
>     cons: Does not improve thruput with single-sliced contents.
> 
>    I can probably play around a bit with this one in near future.

4) just f*ckig ignore what the header says and pretend the deblock type is
   what we need
    pros: easy
    cons: not compliant but i doubt there will be a vissible difference for
          high bitrates, this could some new AVDISCARD_SLICE_BORDER for
          skip_loop_filter or CODEC_FLAG2_FAST


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070905/49a1ec6b/attachment.pgp>