[FFmpeg-devel] H.264 + PAFF: BBC HD recording shows extreme interlacing artefacts
Thu Nov 1 00:05:13 CET 2007
On Wed, Oct 31, 2007 at 10:55:54PM +0100, Reinhard Nissl wrote:
> Loren Merritt schrieb:
> >> Hmm, I've read the relevant part of the MPEG2 spec again and come to
> >> this conclusion:
> >> a) there can be field pictures
> >> b) there can be progressive frame pictures
> >> c) there can be interlaced frame pictures
> >> a) requires to do the colorspace conversion per field while for b) and
> >> c) the colorspace conversion needs to be done per frame. Is this correct?
> >> Is it correct that ffmpeg combines two field pictures into a frame
> >> picture?
> > Yes.
> >> In the case this is correct, how can I see, when to use the colorspace
> >> conversion for a) or c) as interlaced_frame seems to be set in both
> >> cases?
> >> In H.264 it seems that only a) and b) is possible. Is this correct?
> > H.264 has all 3 modes within the codec. Like MPEG2, (a) and (c) are
> > indistinguishable to the application after decoding.
> > I don't know how (c) is supposed to be displayed. The H.264 standard
> > describes chroma subsampling for frames and fields, but doesn't say
> > which one to use for MBAFF.
> > It can be specified in an SEI message, but that's independent of coding
> > type and not present in all streams. A picture could be coded as a
> > progressive frame but with an SEI that says to display it as 2 (or 3 or
> > 4) fields, or vice versa. And I'm not sure whether that SEI is supposed
> > to affect subsampling.
> After some tests and thinking about it, I see that I was wrong, that
> picture coding (field picture/frame picture) has anything to do with
> colorspace conversion in interlace mode. It's simply like Michael wrote
> in his first reply to my question, that when interlaced_frame is set,
> colorspace conversion needs to be done per field.
> Another question that arises after colorspace conversion is displaying
> or deinterlacing the fields in correct order. I was relying on
> top_field_first but it seems that it is always zero as I cannot find any
> reference of this frame member in h264.c. As mpeg12.c references this
> member in mpeg_decode_picture_coding_extension() I assume that filling
> this member is still missing in h264.c.
> The attached patch tries to address this issue. I hope it is correct.
i dont think this patch is sufficient to set top_field_first correctly
i think it will be still wrong (=0) for all MBAFF
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel