Re: [Cellar] Ancillary data in Matroska

[Dave Rice <[e-mail]>]

Hi all,

> On Jan 7, 2017, at 11:57 AM, Dave Rice <[e-mail]> wrote:

[…]

>> On Dec 27, 2016, at 3:22 PM, Jerome Martinez <[e-mail]> wrote:

[…]

>> "N_" prefix arbitrary used (2nd letter of "Ancillary" because first letter is already used)
> 
> Please also add a patch for the TrackType Element in ebml_matroska.xml as we’ll need an unsigned integer to represent the ‘ancillary’ type of track.
> 
>> N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME already supported in Matroska, N_ would be used which would be used for e.g. tmcd codec (QuickTime time code). Exactly same principles as video and audio. Note that classic usage is to store only the first frame content and other content is computed from it, so a player would have to read the first frame even if there is a direct seek request to another place; this could be avoided with some "hack" in the track header, could be the next step after this one is accepted.
> 
> Would need a clear caveat in the definition that this implementation would only support storage of the first timecode value and computation of each additional value. A transwrap from a mov file with a timecode track that uses an edit list to handle non-continuous timecode could not be a lossless transwrap in this case, since the edit list would be lost and the new timecode track in the Matroska file would appear continuous.
> 
> Also reference to tmcd atom is not clear enough. Is it tref/tmcd, gmhd/tmcd, stsd/tmcd.
> 
> If this is stsd/tmcd (I presume), then what time scale should be used? The time scale stored in tmcd or the time scale of the Matroska track?
> 
> I like that copying stsd/tmcd copies in the timecode label as well.

I started a draft of a PR for defining QuickTime-style timecode in Matroska based on Jerome’s suggestion, see https://github.com/Matroska-Org/matroska-specification/pull/102 <https://github.com/Matroska-Org/matroska-specification/pull/102>. I left CodecPrivate as containing the entire Sample description table array of the stsd atom, rather than starting after the track type atom (such as the image descriptor, sound descriptor), because in the case of timecode, values of the tmcd are needed to interpret what the successive timecode values will be. The description of the Codec Mapping uses timecode as an example of ancillary data but not exclusively. Perhaps we should constrain what quicktime media types are relevant here, as several of the media types defined at https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1 <https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1> could be considered as ancillary. Comments?

Best Regards,
Dave Rice