[FFmpeg-devel] [RFC] interlace flagging and detecting.

[Tim Nicholson]

On 10/10/12 17:35, Michael Niedermayer wrote:
> On Wed, Oct 10, 2012 at 05:21:10PM +0100, Tim Nicholson wrote:
>> On 09/10/12 22:26, Michael Niedermayer wrote:
>>> On Tue, Oct 09, 2012 at 03:52:50PM +0100, Tim Nicholson wrote:
>>>> I am trying to tie up some loose ends in the interlace flagging within
>>>> ffmpeg brought to light by attempting to sort out the missing, but
>>>> mandatory 'fiel' atom in uncompressed quicktimes.
>>>>
>>>> I could do with some confirmation from those more familiar that I am on
>>>> the right track.
>>>>
>>>> From what I have gleaned by poring over the code, ffmpeg and libraries
>>>> principally use the AVFrame struct 'interlaced_frame' and
>>>> 'top_field_first' flags, although there is also AVCodecContext's
>>>> field_order enum which seems to exist in order to cover the flag
>>>> permutations required by the qt fiel atom. AFAIK currently these two are
>>>> completely independent. I can find no code to link them or use one if
>>>> the other is blank.
>>>>
>>>
>>>> For example, a sample uncompressed 2vuy .mov when inspected by 'ffprobe
>>>> -show_frames' has interlaced_frame and top_field_first = 0 whilst the
>>>> 'fiel' atom indicates interlaced/bottom field first.
>>>
>>> thats a bug, the decoder should read the field_order from the context
>>> and fill it in the AVFrames it returns
>>>
>>
>> As this field_order is mov specific, shouldn't the mov demuxer inject
>> this into the usual place so the decoders only need to check one place
>> irrespective of format?
> 
> The demuxer places it in AVCodecContext.field_order the decoder moves
> it into the AVFrames. The demuxer has no access to one, none or
> multiple decoders in seperate threads generating AVFrames.
> 

Great, thanks for clarifying.

Now working a patch to ensure this happens, as currently it doesn't.


> 
> [...]

-- 
Tim