[FFmpeg-devel] H.264 + PAFF: BBC HD recording shows extreme interlacing artefacts

[Michael Niedermayer]

Hi

On Wed, Oct 31, 2007 at 10:55:54PM +0100, Reinhard Nissl wrote:
> Hi,
> 
> 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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071101/d122c3ef/attachment.pgp>