[FFmpeg-devel] Inconsistent usage of AVFieldOrder values

[Devin Heitmueller]

Hello,

I suspect this topic has been visited a number of times over the
years, but I figured I should re-raise it.

In the compressed domain, field ordering is represented by the
AVFieldOrder enumeration.  Among the interlaced possibilities, you've
got four combinations:  AV_FIELD_TT, AV_FIELD_BB, AV_FIELD_TB,
AV_FIELD_BT.  The last two characters indicate the coding and display
order respectively.

Only a subset of these possible values are able to be represented in
ffmpeg's AVFrame facility (specifically AV_FIELD_TT and AV_FIELD_TB).
This is because interlaced AVFrames are always represented as
interleaved with top field coded first, and the
AV_FRAME_FLAG_TOP_FIELD_FIRST flag (previously the top_field_first
member) is used to dictate the display order.  I'm not proposing we
make any change to this behavior at this time.

I'm seeing use cases (including within the ffmpeg tree) where I
suspect the developer is misunderstanding the meaning of these values,
and I want to solicit feedback on whether patches would be accepted to
correct such usage, even if it results in breaking applications that
expect the incorrect values.

For example, the decklink input module (libavdevice/decklink_dec.cpp)
sets the values on the v210 packets to either AV_FIELD_TT or
AV_FIELD_BB depending on whether the display order is top field first
or bottom field first.  While the AV_FIELD_TT values is correct, the
use of AV_FIELD_BB is incorrect since all frames delivered by the
driver are always coded as top-field-first (i.e. interlaced frames
with a display order of bottom first should be AV_FIELD_TB).

I'm seeing numerous cases such as the above, in decoders and encoders,
libavformat/libavdevice modules, as well as in third party
applications.

I guess my question is:  if I submit patches which fix such cases
where I find them, will they be rejected because they are a change in
behavior and might very well break existing applications that expect
the incorrect values?  I would like the libraries to report the
correct values in a consistent manner, but I recognize this may cause
some breakage in existing applications.

Thoughts?

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller at ltnglobal.com