Subject: [Cellar] Matroska Info section questions

From: Dave Rice <[email-masked]>
Date: Thu, 30 Jun 2016 01:56:03 -0400

Hi all,

I’m prepping to revise/extend some of the Elements in the Info section and have a few questions.

There are three filename elements here: SegmentFilename, PrevFilename, and NextFilename. The latter two should be escaped but the first doesn’t reference escaping. I think this is a mistake and that all three are intended to be escaped, right?

In these filename definitions, there is language like "An escaped filename corresponding to the previous Segment.” which seems to infer that file has one segment and a segment has one file. However, the previous segment could be within the same file. Is it valid to have a Matroska file with 2 segments, where they have distinct UIDs but share values for SegmentFilename and Prev/Next Filename?

Is it valid for SegmentUID to equal PrevUID or SegmentUID to equal NextUID? Maybe to loop the content?

Any good reference to define filename escaping?

Similar to the 3 filename elements, there are also three UIDs, SegmentUID, PrevUID and NextUID, to chain Segments. There’s some opportunity for conflict here (between UIDs and Filenames). Should we say that the UIDs are more authoritative at chaining than filenames?

Also can the Next/PrevUID refer to other Segments within the same file?

Is it safe to presume that NextUID and PrevUID are ignorable if SegmentFamily is not used?

SegmentUID is not generally mandated, but is it a mandate if the Segment is chained?

IIUC, chained Segments represent content that should be presented sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there other kinds of relationships between chained Segments? Such as a video-only mkv and an audio-only mka chained together to play simultaneously?

Must chained Segments share a continuous segmented timecode? For instance if seeking in a segment before the earlier timecode, should the player switch to the prior chained segment?

If there an authoritative way to tell is a Segment is part of a chain or not? The presence of SegmentFamily alone?

Duration is measured in nanoseconds, right? Or is the duration measured in 1/TimecodeScale?

The definition of DateUTC is unclear to me. It states: "Date of the origin of timestamp (value 0), i.e. production date.” Origin of the content, the matroska file? If I have a newly made Matroska file of a rip of a 2005 DVD of The Wizard of Oz, should I put 1939 (the production date of The Wizard of Oz), or 2005 (the production date of the DVD) or 2016 (the production date of the Matroska file)?

TimecodeScale. I seem to remember some issues here, where some prominent players do not support non-1000000 scales? What recommendations should we make here. Should non-1000000 values be avoided in some circumstances but not others?

The DateUTC has nanosecond accuracy, but what should be done if the timestamp available is less precise than needed. Just presume 0’s?

Muxing and Writing Apps. I can add in some recommendations to say the name of the application/library followed by the version. Any other particular practice to recommend here?

I don’t really understand the ChapterTranslate elemental structure well.
Martin Below, could you review these.

Title. Any particular recommendations or practices here?

Best Regards,
Dave Rice

---

From: hubblec4 <[email-masked]>
Date: Thu, 30 Jun 2016 14:28:11 +0200

> In these filename definitions, there is language like "An escaped filename corresponding to the previous Segment.” which seems to infer that file has one segment and a segment has one file. However…
That is indeed a good question. My first thought is that one segment 
means one file and vice versa.

> Is it valid for SegmentUID to equal PrevUID or SegmentUID to equal NextUID? Maybe to loop the content?
That will be a question of the ability of a splitter. The loop will be 
infinity, how and when break the player/splitter this loop?

> Similar to the 3 filename elements, there are also three UIDs, SegmentUID, PrevUID and NextUID, to chain Segments. There’s some opportunity for conflict here (between UIDs and Filenames). Should we…
Yes of course, an UID should have a higer valence. A filename is easy to 
change by the user, and then are all linkings break. The UID's are not 
so easy to manipulate.

> Also can the Next/PrevUID refer to other Segments within the same file?
If are allowed more then one segement per file then I think it should be 
possible.
> Is it safe to presume that NextUID and PrevUID are ignorable if SegmentFamily is not used?
The usage of SegementFamily is not really clear for me. For what is this 
used? The element can be present multiple times, but for which Segments 
then applies the respective SegementFamily?

> SegmentUID is not generally mandated, but is it a mandate if the Segment is chained?
I think yes.

> IIUC, chained Segments represent content that should be presented sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there other kinds of relationships between chained Segments? Such as a…
Is that really possible to combine a video-only and an audio-only mkv to 
play simultaneously? Sounds for me not really as a "chaining", more like 
a "combining".
Again a question of the splitter/player.

> Must chained Segments share a continuous segmented timecode? For instance if seeking in a segment before the earlier timecode, should the player switch to the prior chained segment?
I thought that's is a normal behaviour.

> If there an authoritative way to tell is a Segment is part of a chain or not? The presence of SegmentFamily alone?
  If SegementFamily tell us the Segment is part of a chain, then is this 
good enough.

> Duration is measured in nanoseconds, right? Or is the duration measured in 1/TimecodeScale?
I think it is 1/TimecodeScale. I hope we can have nanoseconds 
precessions in future. I asked Mosu a lot of doing this,
but the answer was/is that is not possible at the monent.

> Martin Below, could you review these.
I must confess that I did not understand 100%.
The ChapterTranslate element structure looks like the ChapterProcess 
element structure.
And then it all depends on whether you use, Matroska script 
(ChapterProcessCodecID = 0 (default)) or DVDcommand set 
<http://www.matroska.org/technical/specs/chapters/index.html#dvd>(ChapterProcessCodecID 
= 1).
If you use DVD command set for a chapter, you can specify the DVD-level 
equivalent.
Example:
<ChapterProcessPrivate format="hex">30 80 00 01</ChapterProcessPrivate> 
means Video Title Set (VTS) on Level 1
<ChapterProcessPrivate format="hex">28 00 01 01</ChapterProcessPrivate> 
means Title TTU 1 on Level 2
<ChapterProcessPrivate format="hex">20 00 01 00 00 40 00 
00</ChapterProcessPrivate> means
PGC PGC_1 type 0x00 = Basic PGC on Level 3
and so on.

But to specify an edition you must use ChapterTranslate.
ChapterTranslateEditionUID defines corresponding to the edition. (I 
think thats clear)
ChapterTranslateCodec is the same like ChapterProcessCodecID. Only at 
the moment a value of 1 makes sense.
ChapterTranslateID is the same like ChapterProcessPrivate
Example:
<ChapterTranslateID format="hex">00 00</ChapterTranslateID> means Video 
Manager (VMG)

This is a topic of Matroska menu, there are no ways to test it and the 
documentations are very rare.
If you use DVD-Menu you need a lot of knowledge about the structure and 
then the interpretation for Matroska.
  I have try to figure out how this works and I think I understand 
ca.60% . On the other hand we could use Matroska script to build 
better/simpler menu structures (clearly defined).
At the moment exists only one command "|GotoAndPlay( ChapterUID );|".
We could create new commands, simple and good documented.

Segement-Linking:
The linking via the info-elements (Prev/Next) is more than complicate 
and unflexible.
If you use Filename-linking and the user changed the file names, linking 
breaks.
The linking works in/as "a row" only. That means: a.mkv then b.mkv then 
c.mkv (or b-a-c) and so on.
Ever the whole segment/mkv is played in the chain.

The Segement-Linking via Chapters is easier and more flexible.
You must not enter Prev/Next UID's. Only the segmentID is used.
Linking parts of a segment is possible! (a_part1.mkv > b_part1.mkv > 
a_part2.mkv > b_part2.mkv)

Best Regards
Martin Below

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Thu, 30 Jun 2016 19:28:58 +0200

30.06.2016, 14:28 hubblec4:
> 
>> Similar to the 3 filename elements, there are also three UIDs,
>> SegmentUID, PrevUID and NextUID, to chain Segments. There’s some
>> opportunity for conflict here (between UIDs and Filenames). Should we
>> say that the UIDs are more authoritative at chaining than filenames?

+1 The chance of having UIDs collide is very low; having the user tamper
with the file name bears a much higher risk.

>> SegmentUID is not generally mandated, but is it a mandate if the

+1 If you want to use it as reference it has to be included. When there
is linking/chaining than it should be mandatory.

>> IIUC, chained Segments represent content that should be presented
>> sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there
>> other kinds of relationships between chained Segments? Such as a
>> video-only mkv and an audio-only mka chained together to play
>> simultaneously?

Wouldn't anyone mux a audio-only and a video only file to get a mkv that
contains both, the video stream and the audio stream. Players are
supposed to handle such files as they are ordinary files. Otherwise it
might be hugely complex. (Don't get me wrong there are video players
that allow to load a different audio file to play it along with the video.)

I'm not sure if the intro/ending case is still valid for current seasons
of any series, but the potential use was to encode the intro and the
ending once. So that one has:

a.mkv (intro) then b.mkv (episode1) then c.mkv (ending)
a.mkv (intro) then d.mkv (episode2) then c.mkv (ending)
a.mkv (intro) then e.mkv (episode3) then c.mkv (ending)

>> Must chained Segments share a continuous segmented timecode? For
>> instance if seeking in a segment before the earlier timecode, should
>> the player switch to the prior chained segment?

I also assumed that this would be the standard behavior. If a
player/splitter finds all parts (a.mkv b.mkv c.mkv) and I am seeking
backwards from b.mkv up to a point where b.mkv would not contain any
data I'd expect it to load the a.mkv to continue seeking.

In other words if there are segments that are linked I expect the player
to treat all segments as one file. If I tell the player to jump to 1m20s
and that is located in a.mkv i expect it to go there. (On the other hand
if only b.mkv is present and I want to jump to 1m20s it should use only
b.mkv as reference and jump to 1m20s of that file.)

>> If there an authoritative way to tell is a Segment is part of a chain
>> or not? The presence of SegmentFamily alone?

IIRC it is not possible to say in which position a part is, just by
looking at the part (beside the start and the end, which lack either a
previous segment or a following segment). I'm unaware of any
authoritative way to tell if a segment is a part of a chain.

Best Regards,
Sebastian

---

From: hubblec4 <[email-masked]>
Date: Thu, 30 Jun 2016 20:13:29 +0200

Hi Sebastian

> that allow to load a different audio file to play it along with the video.)

You are right. MPC-HC and other good players allows to load externel 
audio and subtitle files
and play them simultaneously.

> a.mkv (intro) then e.mkv (episode3) then c.mkv (ending)
And this is the next disadvantage of File-Segement-Linking.
Intro und ending are separted files.
With Chapter-Segment-Linking(CSL) looks your example like this:

a.mkv (intro + episode1 + ending)
b.mkv (CSL to a.mkv(intro) + episode2 + CSL to a.mkv(ending))
c.mkv (CSL to a.mkv(intro) + episode3 + CSL to a.mkv(ending))
b and c mkv consist of the episode only.

Best Regards
Martin Below

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Thu, 30 Jun 2016 21:13:04 +0200

> Hi Sebastian

Hi Martin

> b and c mkv consist of the episode only.

This is indeed more sophisticated (I'm expressing this as positive).
>From an outside perspective the relation between those files is unclear.
E.g. a user that removes a.mkv  after watching b.mkv might be surprised
that c.mkv does not display correctly. Nevertheless CSL is something good.

Best Regards,
Sebastian