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

Jeff Downs heydowns
Tue Sep 25 05:38:05 CEST 2007


On Mon, 24 Sep 2007, Michael Niedermayer wrote:

> Hi
> 
> On Mon, Sep 24, 2007 at 05:43:05PM -0400, Jeff Downs wrote:
> > Understand and agree.  Are you then proposing that I table the PAFF 
> > implementation pending a (separate) patch to fix this? I want to get the 
> > desired order right here...
> 
> IMHO the AVFrame.reference code should be fixed first unless this turns
> out to be very complex to fix
>

OK.  I took a second look at how Picture.reference is used in mpegvideo.c 
and h264.c.  For current SVN (no PAFF), its not too difficult to fix 
(replace use of reference = 1 with 4 as suggested).


When PAFF is considered, two problems present:

First, a place to store a second field's "is a reference" flag is needed, 
separate from the reference marking of the first field in a pair.

Would using s->dropable for this be an acceptable solution? Or should 
I continue with current_picture.reference?

This way:

s->dropable == current field or frame needs reference marking when 
complete.

current_picture.(_ptr->)reference == PICT_XXX, or 4, as dictated by 
and set in reference picture marking process and delayed picture holding.


Second, MPV_frame_start forces a value of 3 onto reference for ref frames. 
This could be solved by replacing "3" with s->picture_structure. But that 
doesn't really make complete sense for mpeg2.

Another option is to let MPV_frame_start still set 3, but override in 
h264 with picture_structure.

Another option still is to override with zero, and then let the frame end 
processing (ref marking and pic output) take total control of the 
reference variable handling. This is good because it isolates reference 
handling to one area.

If you have a preference, let me know. Otherwise I'll look at it a little 
more and see what makes sense.

	-Jeff




More information about the ffmpeg-devel mailing list