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

[Reinhard Nissl]

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.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264-top_field_first.patch
Type: text/x-patch
Size: 432 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071031/61f2c8cb/attachment.bin>