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

[Michael Niedermayer]

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
that is, i think

cur->top_field_first = cur->field_poc[0] < cur->field_poc[1];

is better than

cur->top_field_first = cur->poc == cur->field_poc[0];

the first condition makes more sense (if it works of course, i havent tested
it)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071109/dfbc0bbe/attachment.pgp>