Details about signaling the source of the timecode by JeromeMartinez · Pull Request #1026 · ietf-wg-cellar/matroska-specification

JeromeMartinez · 2025-08-26T19:56:46Z

Add something similar to \Segment\Tracks\TrackEntry\Name.
While trying to change \Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName definition, I remarked that this block is too much defined with a specific value in other parts of Matroska specs (it should also be utf-8 and not non utf-8 string), so I switched to a new block identifier. This would also avoid to have an errata for this update.

robUx4 · 2025-09-14T09:07:45Z

No sure what you mean by "too much defined with a specific value in other parts of Matroska specs". It's an optional value that is used to have a human friendly name. That element was added in #287 with the other BlockAdditionMapping element. I wonder why I used a string rather than a utf-8 type. It was supposed to mimick the CodecName, which is utf-8.

I'm OK with adding the new (better) element. But it should deprecate the other one or mention it has prority over the old one. Like we do we BCP47 language elements:

If this element is used, then any Language elements used in the same TrackEntry MUST be ignored.

JeromeMartinez · 2025-09-14T12:08:54Z

But it should deprecate the other one or mention it has prority over the old one.

As far as I understand, BlockAddIDName is for describing the type (e.g. "this is a timecode track"), not for describing the content (e.g. "this comes from VITC") which is my goal with this new element, it is an addition so no deprecation.

No sure what you mean by "too much defined with a specific value in other parts of Matroska specs"

I was thinking to change the definition of BlockAddIDName because in practice it is not really used, but changing at the type of the element is maybe too much, so using another element id is maybe better.

robUx4 · 2025-09-21T06:33:54Z

As far as I understand, BlockAddIDName is for describing the type (e.g. "this is a timecode track"), not for describing the content (e.g. "this comes from VITC") which is my goal with this new element, it is an addition so no deprecation.

Indeed, the main difference in the definition is "type" versus "name". But we usually only put things in Tracks that are necessary for the proper playback or user identification. What you want seem to go rather in Tags which could have many descriptions in many languages. And this is possible now with the TagBlockAddIDValue in v5 tags.

If you need information that are necessary for the proper processing of the additional data (this is from VTIC so it works this way and not that way) that should either go in a BlockAddIDExtraData element, use a different BlockAddIDType to distinguish each flavor, or add a more typed element to distinguish them. I think the BlockAddIDExtraData is the cleaner option here.

JeromeMartinez · 2025-09-23T19:33:48Z

As discussed during IETF meeting, I'll change this PR to define tags and provide a list of "sources" vocabulary.

JeromeMartinez · 2025-12-08T18:24:31Z

I changed the purpose of this PR, using TITLE tag for the name of the source of the timecode, I like the idea of using "Tittle" as something which could be handled in a generic manner by players, whatever is the bloc addition type, open to other suggestion.
cc @dericed .

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

dericed · 2025-12-08T18:31:13Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+- "VITC" for a Vertical Interval Time Code, frame or firest field of an interlaced content, as defined in SMPTE ST 12-1
+- "VITC2" for a Vertical Interval Time Code, second field of an interlaced content, as defined in SMPTE ST 12-1
+- "ATC-LTC" for a Linear Time Code as defined in SMPTE ST 12-2 (formerly SMPTE RP 188)
+- "ATC-VITC" for a Vertical Interval Time Code, frame or first field of an interlaced content, as defined in SMPTE ST 12-2 (formerly SMPTE RP 188)


IIRC the SMPTE v12-2 value is "ATC VITC" (space not hyphen) but I don't have a copy to confirm.

IIRC the SMPTE v12-2 value is "ATC VITC" (space not hyphen)

ST2-2 indicates an underscore, so I switched to an underscore.
ST2-2 also uses ATC_VITC1 for the first VITC but ST2-1 uses "VITC" alone, whatever is the field, and also references 60 fps content, so I prefer to use ATC_VITC here for coherency and readiness with 60 fps content (and also 30 fps progressive, no "field 1" also for it).

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

dericed · 2025-12-08T18:33:20Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md


+### Signaling the source of the timecode
+
+Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).


I recommend having a hint that there should just be 0 or 1 labels as currently the wording implies that many is ok.

currently the wording implies that many is ok.

It is on purpose, e.g. SDTI or System Scheme 1 may have more than 1 time code.

I meant there should only be one label (TITLE) per timecode. Not:

<Tags> <Tag> <TagTrackUID>102</TagTrackUID> <TagName>TITLE</TagName> <TagString>LTC</TagString> </Tag> <Tag> <TagTrackUID>102</TagTrackUID> <TagName>TITLE</TagName> <TagString>VITC2</TagString> </Tag> </Tags>

Right? Else I think it may complicate display if we have to prep for >1 labels per timecode source.

I meant there should only be one label (TITLE) per timecode. Not:

We must support your example, because it is per video track and you can have more than 1 tc per track
Your example is not good, TagBlockAddIDValue is missing.

<Tags> <Tag> <TagTrackUID>1</TagTrackUID> <TagBlockAddIDValue>101</TagBlockAddIDValue> <TagName>TITLE</TagName> <TagString>LTC</TagString> </Tag> <Tag> <TagTrackUID>1</TagTrackUID> <TagBlockAddIDValue>102</TagBlockAddIDValue> <TagName>TITLE</TagName> <TagString>VITC2</TagString> </Tag> </Tags>

In 1 101 TITLE LTC 1 102 TITLE VITC2 you're saying that 101 is LTC and 102 is VITC2 which makes sense. I'm more worried about saying that 101 is LTC AND VITC2.

Tag can be reused with different TagLanguage, maybe too strong to forbid other languages, what about TagLanguage == und (the default) means that this is the source, and we let TITLE in other languages available for whatever the user wants?

I'd prefer that our vocabulary for identifying the source of the timecode be considered more of an identifier than a English phase. IMHO to say for the same timecode expression that TITLE="LTC" AND TITRE="Code temporel linéaire" adds a lot of complication. We already have just a short list of under a dozen timecode sources, to open it up widely to have any languages version of that expression and any languages expression of what a TITLE is, would make it quite messy.

dericed · 2025-12-08T18:34:06Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+
+Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).
+
+The following vocabulary is RECOMMENDED for known sources:


What's an example of when to use an unrecommended term?

What's an example of when to use an unrecommended term?

When a new kind of source appear, when someone wants something custom.
I would not enforce a vocabulary, it is only a hint and is not mandatory for having the value itself.

dericed · 2025-12-08T18:34:51Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+- "AES3" for a timecode originally embedded in an AES3 digital audio connection
+- "ABSOLUTE" for a timecode originally embedded in the metadata of a content which indicates the time code from the beginning of a tape
+- "PROGRAM" for a timecode originally embedded in the metadata of a content which indicates the time code from the beginning of a program
+- "RUNNING" for a timecode originally embedded in the metadata of a content which indicates the time code from un unspecified start


These last ones seem to be more about the content of the timecode rather than the source. Are they out of scope here?

These last ones seem to be more about the content of the timecode rather than the source.

It is the name for DAT format. How to differentiate the 3 different timecodes without having a name here?
I am not in favor of having multiple tags depending on if it is the exact technical source or if it is the content, players would never implement something so complicated for a small usage, I argue in favor of keeping it simple and generic for flagging a source in an unique manner.

I suppose the name is "Digital Audio Tape (DAT)" but this is a proprietary SONY design that has been publicly described and reverse engineered. The documentation is all unofficial as far as I know. Do you have a good citation? Maybe it makes sense to name-drop DAT as the inspiration for these labels? Minidisc may have them too.

I suppose the name is "Digital Audio Tape (DAT)"

Yes.

Maybe it makes sense to name-drop DAT as the inspiration for these labels

Will do, but not in the title itself as I would like that it does not not depend on a format.

JeromeMartinez

I also removed AES3 because after checking more the spec, what is called a time code is actually a timestamp, so not topic here.

JeromeMartinez · 2025-12-08T21:31:45Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md


+### Signaling the source of the timecode
+
+Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).


currently the wording implies that many is ok.

It is on purpose, e.g. SDTI or System Scheme 1 may have more than 1 time code.

JeromeMartinez · 2025-12-08T21:32:56Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+
+Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).
+
+The following vocabulary is RECOMMENDED for known sources:


What's an example of when to use an unrecommended term?

When a new kind of source appear, when someone wants something custom.
I would not enforce a vocabulary, it is only a hint and is not mandatory for having the value itself.

JeromeMartinez · 2025-12-08T21:47:00Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+- "VITC" for a Vertical Interval Time Code, frame or firest field of an interlaced content, as defined in SMPTE ST 12-1
+- "VITC2" for a Vertical Interval Time Code, second field of an interlaced content, as defined in SMPTE ST 12-1
+- "ATC-LTC" for a Linear Time Code as defined in SMPTE ST 12-2 (formerly SMPTE RP 188)
+- "ATC-VITC" for a Vertical Interval Time Code, frame or first field of an interlaced content, as defined in SMPTE ST 12-2 (formerly SMPTE RP 188)


IIRC the SMPTE v12-2 value is "ATC VITC" (space not hyphen)

ST2-2 indicates an underscore, so I switched to an underscore.
ST2-2 also uses ATC_VITC1 for the first VITC but ST2-1 uses "VITC" alone, whatever is the field, and also references 60 fps content, so I prefer to use ATC_VITC here for coherency and readiness with 60 fps content (and also 30 fps progressive, no "field 1" also for it).

JeromeMartinez · 2025-12-08T21:49:50Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+- "AES3" for a timecode originally embedded in an AES3 digital audio connection
+- "ABSOLUTE" for a timecode originally embedded in the metadata of a content which indicates the time code from the beginning of a tape
+- "PROGRAM" for a timecode originally embedded in the metadata of a content which indicates the time code from the beginning of a program
+- "RUNNING" for a timecode originally embedded in the metadata of a content which indicates the time code from un unspecified start


These last ones seem to be more about the content of the timecode rather than the source.

It is the name for DAT format. How to differentiate the 3 different timecodes without having a name here?
I am not in favor of having multiple tags depending on if it is the exact technical source or if it is the content, players would never implement something so complicated for a small usage, I argue in favor of keeping it simple and generic for flagging a source in an unique manner.

dericed

I did another review.

dericed · 2025-12-17T14:51:51Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md


+### Signaling the source of the timecode
+
+Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).


I meant there should only be one label (TITLE) per timecode. Not:

<Tags> <Tag> <TagTrackUID>102</TagTrackUID> <TagName>TITLE</TagName> <TagString>LTC</TagString> </Tag> <Tag> <TagTrackUID>102</TagTrackUID> <TagName>TITLE</TagName> <TagString>VITC2</TagString> </Tag> </Tags>

Right? Else I think it may complicate display if we have to prep for >1 labels per timecode source.

dericed · 2025-12-17T14:55:10Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+- "AES3" for a timecode originally embedded in an AES3 digital audio connection
+- "ABSOLUTE" for a timecode originally embedded in the metadata of a content which indicates the time code from the beginning of a tape
+- "PROGRAM" for a timecode originally embedded in the metadata of a content which indicates the time code from the beginning of a program
+- "RUNNING" for a timecode originally embedded in the metadata of a content which indicates the time code from un unspecified start


I suppose the name is "Digital Audio Tape (DAT)" but this is a proprietary SONY design that has been publicly described and reverse engineered. The documentation is all unofficial as far as I know. Do you have a good citation? Maybe it makes sense to name-drop DAT as the inspiration for these labels? Minidisc may have them too.

dericed · 2025-12-17T14:56:01Z

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

+- "ATC_LTC" for a Linear Time Code as defined in SMPTE ST 12-2 [@!SMPTE.ST12-2] (formerly SMPTE RP 188)
+- "ATC_VITC" for a Vertical Interval Time Code, progressive frame or first field of an interlaced content, as defined in SMPTE ST 12-2 [@!SMPTE.ST12-2] (formerly SMPTE RP 188)
+- "ATC_VITC2" for a Vertical Interval Time Code, second field of an interlaced content, as defined in SMPTE ST 12-2 [@!SMPTE.ST12-2] (formerly SMPTE RP 188)
+- "CTL" for a timecode originally embedded in the control track of a videotape


Possibly remove? Seems uncapturable.

Possibly remove? Seems uncapturable.

I am in favor of keeping "CTL" even if we don't (currently) catch it, it may be the case in the future and/or better to reserve this name for something which already existed in the past.

no objection

Agreed that there should be a limit of one label (TITLE) per timecode.

Overall, this work looks great and will be very helpful for digital preservation/archiving workflows. Thanks to Dave and Jerome for their efforts

dericed · 2025-12-17T15:00:57Z

Also please add:

"RS-422" for the Sony 9-Pin RS-422 Timecode, which is a transmission of timecode values as control data messages over an RS-422 serial link, typically as part of the Sony 9-pin VTR remote control protocol.

I'm not sure what citation to use here. SMPTE 12-1 has the definition for LTC but not the transmission of 422. There's the Sony 9-Pin Remote Control Protocol (P2 / Protocol-422) but I can't find a linkable citation.

JeromeMartinez · 2025-12-18T19:49:02Z

"RS-422" for the Sony 9-Pin RS-422 Timecode, which is a transmission of timecode values as control data messages over an RS-422 serial link, typically as part of the Sony 9-pin VTR remote control protocol.

I am not confortable with that, RS-422 seems to be only the electrical layer, and then Sony has its protocol.
Also, it seems to have more than 1 timecode

74 00 | Timer-1 Data
74 01 | Timer-2 Data
74 04 | LTC Time Data
74 05 | User Bits (LTC) Data
74 06 | VITC Time Data
74 07 | User Bits (VITC) Data
74 14 | Corrected LTC Time          Data
74 15 | Hold User Bits (LTC)          Data
74 16 | Hold VITC Time Data
74 17 | Hold User Bits (VITC)          Data

Source.

So I would prefer to use the protocol name + source e.g. "9PIN_VITC". Thoughts?

iamdamosuzuki · 2025-12-18T19:52:01Z

What about "9PIN_SERIAL" ?

JeromeMartinez · 2025-12-18T20:11:23Z

What about "9PIN_SERIAL" ?

I am not in favor of a too long name, also with underscore, for the protocol name, I prefer to use the underscore for separating the source protocol from the type inside this protocol.

Check the update, I used "9PIN_" + the item in 9-pin (to be clarified, I don't remember how exactly it was captured, but at least I see in the reverse engineered protocol description that there may be many time codes).

For coherency, I changed also the DAT related timecodes, prefixed with "DAT_".

I also added more references, Wikipedia when nothing better is found.

@ all, please review again.

iamdamosuzuki · 2026-02-12T14:54:33Z

I'm happy with these changes. Dave discussed the addition of a 9PIN that lacks content. With the addition of that I think this is ready.

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md

JeromeMartinez · 2026-02-12T16:17:41Z

I'm happy with these changes. Dave discussed the addition of a 9PIN that lacks content. With the addition of that I think this is ready.

Right, I don't succeed to find the exact context with the DeckLink API, I added "9PIN".

iamdamosuzuki · 2026-02-12T18:16:25Z

Sorry I had a typo in my previous comment. I meant to say "9PIN that lacks content". The addition of "9PIN" addresses this. thanks.

robUx4 added format addition spec_main Main Matroska spec document target matroska-v5 labels Sep 14, 2025

JeromeMartinez changed the title ~~Add a BlockAdditionMapping name~~ Details about signaling the source of the timecode Dec 8, 2025

JeromeMartinez force-pushed the BlockAdditionMapping_Name branch 4 times, most recently from 575ff87 to 3749f00 Compare December 8, 2025 18:28

retokromer reviewed Dec 8, 2025

View reviewed changes

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md Outdated Show resolved Hide resolved

dericed reviewed Dec 8, 2025

View reviewed changes

JeromeMartinez force-pushed the BlockAdditionMapping_Name branch from 3749f00 to 86946a5 Compare December 8, 2025 21:52

JeromeMartinez commented Dec 8, 2025

View reviewed changes

dericed reviewed Dec 17, 2025

View reviewed changes

JeromeMartinez force-pushed the BlockAdditionMapping_Name branch from 86946a5 to 8debd6e Compare December 18, 2025 20:07

JeromeMartinez force-pushed the BlockAdditionMapping_Name branch from 8debd6e to a8ab531 Compare December 18, 2025 20:12

dericed reviewed Feb 12, 2026

View reviewed changes

cellar-codec/block_additional_mappings/smpte-st12-1-timecode.md Show resolved Hide resolved

Add signaling the source of the timecode

c649dad

JeromeMartinez force-pushed the BlockAdditionMapping_Name branch from a8ab531 to c649dad Compare February 12, 2026 16:15


		### Signaling the source of the timecode

		Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).


		Source of the timecode SHOULD be signaled by the `TITLE` tag associated to the Block Additional (using `TagTrackUID` and `TagBlockAddIDValue`).

		The following vocabulary is RECOMMENDED for known sources:

Conversation

JeromeMartinez commented Aug 26, 2025

Uh oh!

robUx4 commented Sep 14, 2025

Uh oh!

JeromeMartinez commented Sep 14, 2025

Uh oh!

robUx4 commented Sep 21, 2025

Uh oh!

JeromeMartinez commented Sep 23, 2025

Uh oh!

JeromeMartinez commented Dec 8, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JeromeMartinez Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JeromeMartinez left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dericed left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dericed commented Dec 17, 2025

Uh oh!

JeromeMartinez commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iamdamosuzuki commented Dec 18, 2025

JeromeMartinez Dec 18, 2025 •

edited

Loading

JeromeMartinez commented Dec 18, 2025 •

edited

Loading