Subject: [Cellar] fixing Matroska FieldOrder values and definitions

From: Dave Rice <[email-masked]>
Date: Sat, 12 Aug 2017 12:16:16 -0400

Hi all,
Reporting this issue here for discussion as it is a bit complex and involves correcting a definition for an Element which is already well in use.

On January 11, 2016 a FieldOrder Element was added to Matroska in this commit: https://github.com/Matroska-Org/foundation-source/commit/298ebf318f0794479ac753eef87d5bbef0abdaf8 <https://github.com/Matroska-Org/foundation-source/commit/298ebf318f0794479ac753eef87d5bbef0abdaf8>. Prior to this Matroska had a binary value to say if the frame was interlaced or not but no method to describe the type of interlacement. The values for FieldOrder were derived from the Apple QuickTime File Format specification at https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html <https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html> which includes:
> 9 – B is displayed earliest, T is stored first in the file. 14 – T is displayed earliest, B is stored first in the file.

However in a discussion about the conflict between the Quicktime File Format specification and another Apple doc at https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION <https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION>,
an Apple engineer in this comment https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668 <https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668> noted that what Apple does in practice is:
> 9 – T is earlier than B. 14 – B is earlier than T
and noted that
> This is, afaik, what we do; the file format documentation appears to be, um, guilty of, well, wrongness.

As a result I’d like to correct the Matroska field order definitions from 

9 = Interlaced with bottom field displayed first and top field stored first.
14 = Interlaced with top field displayed first and bottom field stored first.

to

9 = Top field displayed first. Fields are interleaved in storage with the top line of the top field stored first.
14 = Bottom field displayed first. Fields are interleaved in storage with the top line of the top field stored first.

This flips the existing drafted definitions, but corrects the existing files created with ffmpeg to match their contents and what is practiced by Apple in QuickTime, although their specification is wrong. I think leaving the Matroska FieldOrder definitions would cause more harm as we’d adopt the same wrongness of the QuickTime specification and would then consider most real world files with FieldOrder as wrong according to the specification.

I have a pull request for this for consideration at https://github.com/Matroska-Org/matroska-specification/pull/162 <https://github.com/Matroska-Org/matroska-specification/pull/162>. Also please consider this thread which started the consideration of this issue, https://github.com/amiaopensource/vrecord/issues/170 <https://github.com/amiaopensource/vrecord/issues/170>.

Best Regards,
Dave Rice

---

From: Moritz Bunkus <[email-masked]>
Date: Sat, 12 Aug 2017 18:26:47 +0200

Hey,

thanks for the writeup. I've read the whole issue vrecord#170 and your
proposal (though I haven't looked through Apple's documentation that you've
linked; I trust you guys to be exact in this). I concur with your proposal
& will approve the corresponding PR.

Kind regards,
mosu

---

From: Kieran O Leary <[email-masked]>
Date: Sat, 12 Aug 2017 17:46:06 +0100

I think this should be implemented as it clears up a lot of confusion about
real world implementations versus the specifications. Thanks for putting
this together.

---

From: Dave Rice <[email-masked]>
Date: Sat, 12 Aug 2017 12:49:44 -0400

> On Aug 12, 2017, at 12:16 PM, Dave Rice <[email-masked]> wrote:
> 
> Hi all,

Relatedly I supplied a patch for ffmpeg on the same issue at http://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214848.html <http://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214848.html>.
Best Regards,
Dave Rice