[FFmpeg-devel] [PATCH] Implement PAFF in H.264

Neil Brown neilb
Fri Sep 28 03:23:29 CEST 2007

On Thursday September 27, heydowns at borg.com wrote:
> On Wed, 19 Sep 2007, Neil Brown wrote:
> > I just tried it on my clips from my Sony HDR-SR1 Camcorder.
> > 
> > [...]
> > 
> > 2/ There are some strange artifacts at the edges when I pan left or
> >    right.  This png shows an example.  It is clipped from the left edge
> >    of a frame showing a parking lot.  Notice there are some pale
> >    patches down the left side.  It looks like the reference mb was
> >    thought not to be available, so grey was used instead.
> I've found the source of this problem and have an ugly fix in my current 
> development tree. I need to read a little more of the existing 
> implementation to find a good (efficient) fix.  My next patch should 
> include a fix.

Cool, thanks.

I've been looking at the other problem I had:

> 3/ Something goes wrong with the re-ordering of frames.  The first few
>    seconds seem OK.  But then I get an effect which seems like
>    adjacent frames are swapped. e.g. a car door should be closing, but
>    it looks like it closes a bit, then opens, then closes some more,
>    then opens a bit etc.  Taking a sample 10 frames, the correct
>    ordering is
>          2 1 4 5 3 6 8 7 10 9
>    which is close to swapping each pair, but not quite.

It turns out that there is an IDR frame that is not being handled
The 'poc' sequence gets up to about 515 then resets to 0 on the IDR
frame and because the fact that it is an IDR flag gets lost, the jump
in sequence numbers confuses the re-ordering code.

Why is the IDR frame missed?  Well with PAFF, it is an IDR field of
course.  The first field of a complementary-field-pair is 'IDR', the
second isn't.  So this line:
            s->current_picture_ptr->key_frame = (hx->nal_unit_type == NAL_IDR_SLICE);

sets key_frame for the first field stored in the frame, then clears it
for the next field.  So where we come to process the whole frame,
key_frame is zero.

My proposed fix (which "works for me") is:

Index: ffmpeg/libavcodec/h264.c
--- ffmpeg.orig/libavcodec/h264.c	2007-09-23 13:37:14.000000000 +1000
+++ ffmpeg/libavcodec/h264.c	2007-09-28 11:16:00.000000000 +1000
@@ -7581,7 +7581,7 @@ static int decode_nal_units(H264Context 
             if((err = decode_slice_header(hx, h)))
-            s->current_picture_ptr->key_frame= (hx->nal_unit_type == NAL_IDR_SLICE);
+            s->current_picture_ptr->key_frame |= (hx->nal_unit_type == NAL_IDR_SLICE);
             if(hx->redundant_pic_count==0 && hx->s.hurry_up < 5
                && (avctx->skip_frame < AVDISCARD_NONREF || hx->nal_ref_idc)
                && (avctx->skip_frame < AVDISCARD_BIDIR  || hx->slice_type!=B_TYPE)


More information about the ffmpeg-devel mailing list