Re: [Cellar] matroska and side data vs timecode

[Jerome Martinez <[e-mail]>]

On 03/11/2019 11:29, Steve Lhomme wrote:
> That seems like a big overhead. Is the 64 bits value necessary ? It
> seems 32 bits might be sufficient (saving 4 bytes). Maybe 40 if you
> need extra flags.

Advantage here is that we use a standardized and a lot used (in some 
domains) time code format, which can also be a direct dump from some 
sources, and it includes other data (color flag, binary group flags 
which can contain extra info etc), and could be exported to a SMPTE ST 
12 aware equipment without adaptation.

Other formats of time code, e.g. configuration (start time code, drop 
frame, frame rate...) in track header then a 32-bit number for each 
frame, could be implemented, but IMO it is just another format, 
independent. Both SMPTE ST 12 and a single number could be implemented, 
just different purposes/goals. Also sometimes the conversion from SMPTE 
ST 12 to other time code formats may be not lossless if you use just a 
number ("buggy" input with different drop frame info etc, differences 
would be lost).

In summary, both SMPTE ST 12 and just a number can work for time codes, 
but they have different goals, and one would not totally replace the 
other, just 2 "competing" formats.


> In general I'm not in favor of using tags for data that may be needed
> when remuxing, especially tied to a timestamp (yes, I mean timestamp).
> If the first frame is damaged, does the timecode apply to the second
> frame ? If the first frame timestamp wasn't 0, how do you know the
> difference you have to apply ?

Advantage here is the simplicity of the implementation, and also 
informing bout what is already done in tools e.g. FFmpeg.
Not bullet proof but often good enough.

[...]

Jérôme