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

[Dave Rice <[e-mail]>]

> On Mar 14, 2017, at 3:57 PM, Jerome Martinez <[e-mail]> wrote:
> 
> Le 14/03/2017 à 20:45, Dave Rice a écrit :
>> [...]
>> 
>>> 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.
> 
> OK, I need to check my files but I am pretty sure I have some.
> 
>> 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.
> 
> What about seeking?

Isn't the seeking similar to QuickTime. In QuickTime you'd need the offset table of the timecode track to understand the number and location of all timecode samples. In Matroska you would use the associated CuePoints of the timecode track for the same reference. By parsing Cues the reader should be able to determine if the timecode is stripped or not and if not then have the CueTimes for each associated timecode Cluster.

> If you have a timecode block at the first frame and also at the middle of the file, how a player can know that there is a timecode block breaking the sequential order without parsing the whole file when there is a seek request to the last minute of content? In that case, time code real value would be set to "waiting for new block" (and this block never comes). I don't think that forcing full parsing of the file with time code for seeking is a good solution.

Same. But in the case of video if you seek to a P-frame then you have to go backwards and decode from the I-frame. Similarly if seeking to a timepoint without a timecode Cluster (analogous to a P-frame), then the reader would have to use the Cues to decode the prior timecode Cluster (analogous to I-frame) in order to determine the timecode value of the seek point.

Dave Rice