Re: [Cellar] Ancillary data in Matroska

It seems a lot of these formats include timecodes (or are basically
timecodes). There is still debate whether timecodes should have their
own track and ancillary data a different type of tracks. As expressed
in a different thread I think timecodes Blocks should come before the
video/audio block they are meant to match. Is it the same with
ancillary data ? Do ancillary data match a specific video frame
compared to timecodes that are more generally loose ?

I think this consideration will define how we should go forward
handling these data.

I agree with Jerome that we're not going to reinvent yet another
timecode format. We should support the main ones. Same thing for
ancillary data.

2017-02-24 5:18 GMT+01:00 Dave Rice <dave@dericed.com>:
> Hi all,
>
> On Jan 7, 2017, at 11:57 AM, Dave Rice <dave@dericed.com> wrote:
>
>
> […]
>
> On Dec 27, 2016, at 3:22 PM, Jerome Martinez <jerome@mediaarea.net> 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. 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
> could be considered as ancillary. Comments?
>
> Best Regards,
> Dave Rice
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman