Re: [Cellar] matroska and side data vs timecode

[Dave Rice <[e-mail]>]

Hi all,

> On Nov 5, 2019, at 2:51 AM, Tobias Rapp <[e-mail]> wrote:
> 
> On 03.11.2019 11:29, Steve Lhomme wrote:
>> [...]
>> If you want something that will survive this scenario you have to tie
>> this value to the first timestamp. When remuxing, if timestamps are
>> altered of portions at the beginning of the file are removed, you need
>> to edit the first timecode. It may be better to store in the TrackInfo
>> with both the first timestamp and timecode values. It may not work
>> when stripping the audio (as Tobias pointed out). So it may even be
>> put in the SegmentInfo instead of the TrackInfo.
> 
> It looks tempting to put timecode information inside the video track as they share the framerate as a common property. But in my opinion it would be cleaner to just copy that framerate info into the timecode value structure. For storing a single TC offset using an element in SegmentInfo sounds good.

From the discussion, there seems to be three approaches for timecode in Matroska:

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.

2. frame side-data
This allow the timecode (and any other side data) to be stored with the frame in the Block structure.

3. a timecode track
I imagine this would be a track of Clusters where each block contains an encoded timecode value where the block structure associates the timecode to a timestamp.

Each of these have advantages and disadvantages in terms of simplicity, implementation, seekability, and resilience; however we do not necessarily have to select only one. All three approaches could be defined if we document how these options supersede one another.

I’m curious if other would consider it important to favor limiting the number of approaches listed above. I would prefer to proceed with refinement to options 1 and 2 concurrently. I’m less interested in option 3 since timecode is typically used to describe the contents of another track rather than serve as an independent piece of data.

>> You may also set the value in Chapters (which are not tied to a
>> track). There's already a start timestamp. You could add the timecode
>> for this timestamp. That works for NLE sources as well, each
>> non-linear part would be a chapter with its timestamp translation. A
>> good NLE system would also tag this chapter with all kinds of data
>> about the source. (Matroska was also designed for this case in mind).
> 
> 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.

[…]

Dave Rice