[FFmpeg-devel] [PATCH] h264 parallelized

[Andreas Öman]

Hello,

Reinhard Nissl wrote:
> Hi,
> 
> Now, I do get the message about unsupported deblocking type for the
> recording from channel EinsFestival HD, but I do not see the load
> distribution from ffplay when playing an ASTRA HD recording with xine.

In order for the current multithreading-code to kick in the content
must be encoded with multiple slices and loopfilter must be 0 or 2:
This is easily verified with "ffmpeg -debug 1 ..."

[h264 @ 0x84a30f0]slice:1 F mb:0 I pps:0 frame:0 poc:0/0 ref:2/1 qp:21 
loop:2:0:0 weight:0
[h264 @ 0x84a30f0]slice:2 F mb:480 I pps:0 frame:0 poc:0/0 ref:2/1 qp:22 
loop:2:0:0 weight:0
[h264 @ 0x84a30f0]slice:3 F mb:1040 I pps:0 frame:0 poc:0/0 ref:2/1 
qp:21 loop:2:0:0 weight:0

and so on ..

We see multiple slices and loopfilter == 2.

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