[FFmpeg-devel] [PATCH] ffmpeg: fix setting field_order during muxing

Dave Rice dave at dericed.com
Fri Aug 11 00:37:23 EEST 2017


> On Aug 10, 2017, at 5:18 PM, Jerome Martinez <Jerome at 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:

https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html (Table 4-2)

https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION (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


More information about the ffmpeg-devel mailing list