Re: [Cellar] matroska and side data vs timecode

[Dave Rice <[e-mail]>]

> On Nov 24, 2019, at 11:43 AM, Steve Lhomme <[e-mail]> wrote:
> 
> 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.

There aren’t that many players I can think of that display timecode on playback. QuickTime 7 used to but is deprecated. QuickTime X doesn’t show timecode nor VLC. ffplay can do it by some filter work that pulls from the metadata.

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

The name is TIMECODE and it writes the timecode value as a string. Like TIMECODE=01:23:45;12
You can make an example of this via:
ffmpeg -f lavfi -i testsrc -metadata timecode='01:23:45;12' -t 1 ffmpeg_timecode.mkv

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

See you next week :)

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

Please no. :-O

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

I think this is hacky as well. It seems like a lot more to ask a recording tool to reset to a new Segment because the timecode skipped.
Dave

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