> On Aug 10, 2017, at 5:18 PM, Jerome Martinez <jer...@mediaarea.net> wrote:
> Le 10/08/2017 à 04:43, James Almer a écrit :
>> AVFrame.top_field_first doxy states
>> "If the content is interlaced, is top field displayed first."
>> And AVFieldOrder doxy defines:
>>     AV_FIELD_TB,          //< Top coded first, bottom displayed first
>>     AV_FIELD_BT,          //< Bottom coded first, top displayed first
>> Fixes ticket #6577
> IMHO the subject is complex, and everyone should be in sync with the purpose 
> of each mux_par->field_order value and understand impact on other players 
> (sometimes the MOV metadata is the only one available as the codec has no 
> info e.g. uncompressed or jp2k) before changing current behavior in a so 
> general manner.
> What I understood is that it is based on QuickTime specs (the mapping is 1 to 
> 1 from fiel atom) and TN2162 and that they are not easy to understand and 
> maybe misleading : the feedback I got in the last years about the meaning of 
> this atom are not really in sync with specs having stored vs displayed, and 
> such change may have an impact on how other players handle fiel atom or other 
> metadata in the way it is currently implemented by FFmpeg.

I filed ticket #6577 but not feel cautious about this patch and consider that 
my initial report may have been based on some misunderstanding. As Jerome notes 
the MKV field order flag is derived from mov's fiel atom and there are two 
definitions for that:

 (Table 4-2)

 (Figure 4)

From testing we have found that ffmpeg's behavior here is matching some Apple 
mov muxers in the assignment of a field order value, so the patch may be 
unneeded or the reason may need more testing.

Dave Rice
ffmpeg-devel mailing list

Reply via email to