Re: [Cellar] matroska and side data vs timecode

[Steve Lhomme <[e-mail]>]

Le jeu. 21 nov. 2019 à 16:03, Dave Rice <[e-mail]> a écrit :
>
> 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.

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)

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

That sounds like something we can discuss a No Time To Wait.

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

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.

> […]
>
> Dave Rice
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman