Re: [Cellar] matroska and side data vs timecode

[Steve Lhomme <[e-mail]>]

Le dim. 3 nov. 2019 à 11:59, Jerome Martinez <[e-mail]> a écrit :
>
> 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.

Yes, IMO they are different timecode "codecs" (COder/DECoder). There
could also be string versions, I don't know if that's common.

That's also why I'd rather have a separate document for such "codecs".
It's the same with video/audio/spu codecs and chapter codecs should do
the same.

It all depends on what solution(s) we end up with. If there's
something in the SegmentInfo or TrackInfo then we have to define it in
the main document.