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

[Jerome Martinez <[e-mail]>]

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?
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.