[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
properly.
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)))
                break;
 
-            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)


Thanks,
NeilBrown




More information about the ffmpeg-devel mailing list