Re: [Cellar] QuickTime timecode tracks in Matroska, was Ancillary data in Matroska

[Dave Rice <[e-mail]>]

> On Mar 14, 2017, at 3:39 PM, Jerome Martinez <[e-mail]> wrote:
> 
> Le 14/03/2017 à 20:14, Dave Rice a écrit :
>> [...]
>> 
>> After looking at this some more, I decided to create an alternate proposal for a T_QUICKTIME codec mapping, rather than to store QuickTime-style timecode in the more vague concept of an ancillary N_QUICKTIME.
> 
> Trying to find some counter-arguments, I have to agree that this may be better as we don't have any real example for usage of a generic QuickTime ancillary track.
> 
>> 
>> [...]
>> 
>> The attachment contains a SimpleBlock using the T_QUICKTIME with a example value of 0x0001fc8c, which according to the QuickTime Timecode Sample Data is 01:12:23;28 and subsequent timecode values for the track would be calculated according to the incrementation defined in the Private Data.
> 
> Content location is another issue.
> Time code may be stripped (only the first time code is stored and other time code must be computed from it + header metadata), and there is no way to know it in Matroska : QuickTime has the list of blocks in the track header so the player knows if the the time code is stripped (1 block of 4 bytes) or not (more than 1 block), this is not the  case with Matroska.
> How could we indicate to the player that the time code is stripped (=only one value stored, then player should compute value of other time code frames)?

Since the update proposal defines a new media type (timecode) it is possible to define a Timecode Master element (as similar done with Audio and Video) to store needed context.

OTOH I don’t think I’ve ever seen a QuickTime timecode track that was non-stripped. I’ve only seen a single value stored but then sometimes an edit list used to alter the ordering of the timecode (in case when its non-sequential). For Matroska possibly it could simply store a new timecode Block at any case when it is not sequential.
Dave