[FFmpeg-devel] [RFC] interlace flagging and detecting.
nichot20 at yahoo.com
Fri Oct 12 12:26:45 CEST 2012
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.
More information about the ffmpeg-devel