[FFmpeg-devel] [Bulk] Re: [RFC] interlace flagging and detecting.

[Tim Nicholson]

On 12/10/12 11:26, Tim Nicholson wrote:
> 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.
> 

Or I will once I have sorted out a regression that means my uyvy->prores
is coming out with the wrong field-dominance and incorrect durations.

Somewhere between 83438a0db3c and 4dcf71aac...

> 
>>
>> [...]
> 


-- 
Tim