[FFmpeg-devel] [PATCH] Provide top_field_first logic for h264.c

Måns Rullgård mans
Fri Nov 9 19:11:29 CET 2007

Michael Niedermayer wrote:
> On Fri, Nov 09, 2007 at 09:02:34AM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> > Hi
>> >
>> > On Thu, Nov 08, 2007 at 09:22:16PM +0100, Reinhard Nissl wrote:
>> >> Hi,
>> >>
>> >> the patch was last posted in the thread "H.264 + PAFF: BBC HD recording
>> >> shows extreme interlacing artefacts".
>> >>
>> >> It provides top_field_first by comparing frame poc (picture order count)
>> >> against top field poc. When both match, the frame shall be displayed
>> >> with top field first.
>> >
>> > looks ok, except maybe that top_field_first would be 1 for non interlaced
>> > content which is a little odd to me
>> > i think (though havnt checked) that top_field_first is 0 for non interlaced
>> > content in other codecs
>> If the content is non-interlaced the fields should be displayed
>> simultaneously, so there is no field order.  If the hardware isn't
>> capable of this, the order chosen doesn't matter.  Hence there is no
>> problem with setting it to top_field_first in this case.
> mpeg 2 uses top field first for specifying field repeation together
> with repeat first field (for progressive sequences)
> we export this cleanly as repeat_pict but
> i just thought it might be less confusing for applications if tff is set
> consistently relative to the mpeg2 spec and repeat_pict

I don't see a problem with us reporting values not consistent with the
MPEG2 spec for non-MPEG2 material as long as there is a clear meaning.
If this causes trouble for an app, the fault is IMHO in the app, not lavc.

The way those flags are used in MPEG2 seems to me like something of a
hack to cram as much information as possible into two bits per picture.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list