On 25/04/2024 00:42, Marton Balint wrote:
On Mon, 22 Apr 2024, Devin Heitmueller wrote:
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.
That is how it is documented, but likely it is not how it actually
works. The whole mess is originated from the QuickTime specification
which contradicts with an Apple technical note. See this discussion:
https://sourceforge.net/p/mediainfo/bugs/841/
Recently I also stumbled over this when using the FFmpeg Matroska muxer.
Found some discussion around the interpretation of the QuickTime spec in
https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668
and http://trac.ffmpeg.org/ticket/6577#ticket.
Long story short, AV_FIELD_TB means top field first in practice,
AV_FIELD_BT means bottom field first in practice. I think most of the
code follows this interpretation, and not the actual documentation.
AV_FIELD_BB and AV_FIELD_TT tries to signal field order for separate
field encodings, but quite possibly sometimes (mis)used for ordinary
field order signalling as well...
As I understand it the FFmpeg enum definitions follow the original
(wrong) QuickTime spec wording. The actual usage in code then sometimes
follows the documentation text (coded vs. displayed timing), and in
other cases uses the enum to indicate field storage (interlaced vs.
separate).
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.
Making changes out of the blue likely won't be acceptable. If a
justified plan is presented to untangle this, then maybe *some*
breakage is acceptable, but I don't honestly know.
Some random ideas:
- Consider fixing the documentation (and the textual description of the
field orders) instead of changing behaviour.
- Try to collect commercial samples and see what they contain for TFF/BFF
content, separete fields or interleaved, compressed or
uncompressed.
- Go over the codebase and see which component is using which
interpretation in practice, make a list, see if there is a significant
majority...
I agree that fixing the mess would require some effort to clarify for
each context (codec, muxer) where the AVFieldOrder enum is used what the
interpretation is with different third-party applications, and whether
it matches its own spec or not. Only relying on specs would not be
enough, as the incorrect wording from QuickTime could be copied (see
Matroska) but not used in practice.
It would be nice, though, to get the confusing "bottom coded first
(swapped)" log message fixed into "top first (interlaced)"!
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
