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

Michael Niedermayer michaelni
Sat Nov 10 00:21:40 CET 2007


Hi

On Fri, Nov 09, 2007 at 09:35:23PM +0100, Reinhard Nissl wrote:
> Hi,
> 
> Michael Niedermayer schrieb:
> 
> >>>>>> 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)
> 
> You're right, the above condition is much easier that what I have posted
> recently. I've tested it as in the below patch and it works properly.

looks ok

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20071110/fcedf047/attachment.pgp>



More information about the ffmpeg-devel mailing list