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

[Tim Nicholson]

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? As rawvideo codecs have a problem embedding such
information in the stream surely the demuxers should get whatever info
they can from the container format and place it somewhere common to help
the decoder out.

My grepping around suggests that the field_order is only ever read in
the case of stream copying and the Meriden coder.


> 
> [...]
>> I notice also that although many codecs seems to access the AVFrame
>> 'interlaced_frame' for making decisions about interlace handling the
> 
> yes
> 
> 
>> Avid Meridien coder (avuienc.c) specifically uses AVCodecContext's
>> field_order, so there does seem to be some inconsistency.
> 
> are there other raw encoders that need interlaced info at init time ?
> if not then its not really inconsistent.
> non raw encoders take the interlaced info from user specified
> parameters normally ...

But surely by taking the interlace material flag from the field_order
which comes directly from the source file you are assuming that there
are no filters or other processes that might alter it before it reaches
the coder, wheras the AVFrame flag can be updated by other processes say
setfield/fieldorder filters)


> 
> 
> [...]


-- 
Tim