[FFmpeg-devel] [PATCH] Provide top_field_first logic for h264.c
Fri Nov 9 21:35:23 CET 2007
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 < cur->field_poc;
> is better than
> cur->top_field_first = cur->poc == cur->field_poc;
> the first condition makes more sense (if it works of course, i havent tested
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.
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 474 bytes
Desc: not available
More information about the ffmpeg-devel