Re: [Cellar] matroska and side data vs timecode

[Tobias Rapp <[e-mail]>]

On 24.11.2019 17:43, Steve Lhomme wrote:
> Le jeu. 21 nov. 2019 à 16:03, Dave Rice <[e-mail]> a écrit :
>>
>> [...]
>>
>> 1. a single TC offset
>> I proposed having this as a metadata tag, but you’re suggestion to have the value in Segment Info is interesting. I think the advantage of having it as a metadata tag is that ffmpeg’s current handling of (ffmpeg -i timecode.mov output.mkv) would be retroactively valid, whereas a single offset in SegmentInfo would require implementation work.
> 
> But usually tags are not considered/parse in most playback systems. If
> you need information to playback things correctly (ie display the
> proper TC) it should be either in Segment Info, Track Info or
> Clusters. The Timecode may fall in the metadata category and may not
> be included in there. Also using tags would only work if we adopt
> exactly the solution already in use by ffmpeg. What tag does it write
> exactly ? (name, kind of value, target for the tag)

Adding a tag for storing timecode offset is a simple solution and 
satisfies the most basic requirements. The current list [1] seems to 
already include other technical tags like "FPS" and "REPLAYGAIN_PEAK" so 
it should be fine.

I would not use a framecount for storing sub-seconds, though, but a 
HH:MM:SS.MSS pattern like used for date-time (without the date part). 
This would be valid for audio and video files. An application can render 
the value in HH:MM:SS:FF syntax for user display, if desired.

>>> Setting up a timestamp/timecode mapping via Chapters for non-continuous timecode situations looks like an even better solution than using a dedicated timecode track as this structure should represent the timeline for players.
>>
>> I’m uncertain how this would work, do you mean to use ordered chapters to place the content along a timeline according to the source timecode? This may not work if multiple frames in a track all share the same timecode value, such as when a tape is shuttled during a duplication process or contains resets within the timecode track.
> 
> Not necessarily ordered-chapters. A chapter already has a mandatory
> start time, it could have one Timecode to define what that start time
> corresponds to (or more variants of Timecode for the same start time).
> Technically that means you could have on Chapter per frame to match
> it's time exactly with a timecode, that would be a dirty hack.
> 
> As for reset in tapes, After a reset you should use a different
> Segment. If there are just gaps of time between continuous takes, you
> can use on Chapter start/timecode after each discontinuity.

The latter option seems the most practical. As far as I understand from 
[2] there can be multiple chapters applied to one segment by using 
multiple EditionEntry elements. That might be useful because we can have 
one chapter structure for track labeling "scene one", "scene two", ... 
and another chapter structure for timecodes (if necessary).

I assume timecodes would get an own "ChapterTimecodeOffset" element, 
similar to existing ChapterTimeStart/-End. Or would you define a 
"ChapProcessCodecID" for timecodes explicitly? Also maybe we want to 
store some more information together with the plain time value. Possibly 
frame-rate and drop-frame flag (for rendering the time in HH:MM:SS[:;]FF 
syntax) should be put either as optional elements on EditionEntry level 
or into ChapProcessPrivate.

In theory there could be multiple timecode sources (VITC, LTC, etc) but 
in practice it seems hardware players just output the most precise one 
currently available so storing the source name in Matroska would not be 
considered relevant by me.

Best regards,
Tobias

Links:
[1] https://www.ietf.org/id/draft-ietf-cellar-tags-03.html
[2] 
https://datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-04#section-9.3.7