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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Fri, Nov 09, 2007 at 06:11:29PM -0000, M?ns Rullg?rd wrote:
>> 
>> 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.
>
> i dont disagree, still IMHO
> top field first is not true if both have the same poc/pts

Well, not top field first implies bottom field first, and that's not
true either for a progressive frame.  I'd say the value
top_field_first is irrelevant and should be ignored for progressive
frames.

Anyhow, I don't mind how this is done.  Pick whatever solution you
prefer.

-- 
M?ns Rullg?rd
mans at mansr.com