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

[Reinhard Nissl]

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.

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