Subject: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions

From: Dave Rice <[email-masked]>
Date: Sun, 14 Feb 2016 12:33:56 -0500

> On Jan 26, 2016, at 5:42 AM, Steve Lhomme <[email-masked]> wrote:
> 
> 2016-01-24 21:54 GMT+01:00 Dave Rice <[email-masked]>:
>> Hi all,
>> 
>> The current definition of SeekHead is "Contains the position of other level 1 elements.”
>> 
>> Is it valid to use the SeekHead to reference Elements that are not Level 1?
> 
> There's a very good chances no player will use such values. Also
> they'd be harder to interpret, since you don't know in which parent
> element they belong to.
> 
>> Is there any existing official text about the use of chained SeekHeads (SeekHeads that link to other SeekHeads)?
>> 
>> In the related section on “Position References” it says: "The position in some elements refers to the position, in octets, from the beginning of an element. The reference is the beginning of the first Segment element (= its position + the size of its ID and size fields).” Since the Segment Element can occur more than one time in an EBML Document I wanted to verify how SeekHead works in Matroska EBML Documents with multiple Segments. For instance in a file structure like:
>> 
>> <EBML>
>> <Segment>
>>        <SeekHead/>
>>        <Info/>
>>        <SeekHead/>
>> </Segment>
>> <Segment>
>>        <SeekHead/>
>> </Segment>
>> 
>> So if I understand the definition correctly, the SeekPosition values in all three example <SeekHead> Elements reference the offset from the beginning of the FIRST Segment, correct?
> 
> No, multiple concatenated either come different sources or an original
> file that was split. In all cases the SeekHead references the Segment
> it belongs to. It works even if you don't have the other segments.
> 
>> Related to the last question, is there a reason for the Segment element to be multiple. I know an EBML Stream may be <EBML/><Segment/><EBML/><Segment/>, but is <EBML/><Segment/><Segment/><EBML/><Segment/> allowed? If we clarify that the ‘multiple/maxOccurs’ value of Level 0 Elements refers to the occurrence within an EBML Document rather than a file, could the Segment Element be set to non-multiple?
> 
> IMO <EBML/><Segment/><Segment/> is not allowed. And such files
> probably don't exist. But we may allow it. It's not that different to
> parse than when the EBML header is always preceding the Segment.

I propose disallowing multiple level 0 within an EBML Document after the EBML Header. I think this is consistent with the analogy between EBML and XML, where XML may have an XML Declaration (equivalent of EBML Header) and then followed by exactly one top level node.

Within the EBML Schema section I suggest adding:

"An EBML Schema MUST declare exactly one Element at Level 0 (referred to as the Root Element) that MUST occur exactly once within an EBML Document. The Root Element MUST be mandatory and MUST be defined to occur exactly once. Note that the EBML and Void Elements may also occur at Level 0 but are not considered to be Root Elements."

With this, I also suggest changing both EBML (Header) and Segment in the Matroska spec to non-multiple.

This would mean:

invalid (multiple Root Elements)

<EBML/>
<Segment/>
<Segment/>

invalid (only header and no Root Element)

<EBML/>

valid (the usual MKV file)

<EBML/>
<Segment/>

valid (two concatenated EBML Documents)

<EBML/>
<Segment/>
<EBML/>
<Segment/>

Thoughts?

Best Regards,
Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Sun, 14 Feb 2016 18:43:46 +0100

On 14/02/2016 18:33, Dave Rice wrote:
> [...]

I think it would break some files.

> invalid (only header and no Root Element)

Useless but why invalid?

> valid (two concatenated EBML Documents)

I don't see the value added of repeating the EBML. Should be a valid 
file, but not something mandatory.

> Thoughts?

we should authorize EBML header repetition, but not doing it mandatory.

Jérôme

---

From: Dave Rice <[email-masked]>
Date: Sun, 14 Feb 2016 12:58:50 -0500

> On Feb 14, 2016, at 12:43 PM, Jerome Martinez <[email-masked]> wrote:
> 

Example?
Even the pgmx files include an EBML Header before every Segment. http://download1.pegasys-inc.com/download_files/TPXC_materials/elephants_dream_rose.pgmx

>> invalid (only header and no Root Element)

I suppose if someone defines docType='useless' with no other elements besides the header. But a file with only an EBML-Header would be invalid as webm and invalid as Matroska (since Segment is mandatory). So yes it is possible that this could be valid but a docType's EBML Schema would have to be written to allow it.

> I don't see the value added of repeating the EBML. Should be a valid file, but not something mandatory.

The EBML may in some cases be a repeat by coincidence, but two Segments may use different MaxIDLengths or different docTypeReadVersions that need to be documented in their own EBML Header.

To clarify, the EBML Schema rules document an EBML Document and not an EBML Stream (such as the last example):

<EBML/>			\	EBML Dcoument #1	\
<Segment/>		/						 \  EBML Stream (comprised of two EBML Documents)
<EBML/>			\	EBML Document #2	 /
<Segment/>		/						/

I'm suggesting that the EBML Schema (which defines EBML Document and not EBML Stream) restrict to one EBML Header and one Root Element (Segment in Matroska's case)

> we should authorize EBML header repetition, but not doing it mandatory.

I disagree and propose that within an EBML Document that EBML Header should be mandatory (as read) and not repeat.

This structure includes multiple EBML Headers in one EBML Document. I don't think it makes sense and should be invalid.
<EBML docType="matroska" EBMLMaxSizeLength="4" EBMLMaxIDLength="4"/>
<EBML docType="webm" EBMLMaxSizeLength="6" EBMLMaxIDLength="6"/>
<Segment/>

This is an example of an EBML Stream comprised of two EBML Documents. Each EBML Document is constrained to one EBML Header and one Root Element.
<EBML docType="matroska" EBMLMaxSizeLength="4" EBMLMaxIDLength="4"/>
<Segment/>
<EBML docType="webm" EBMLMaxSizeLength="6" EBMLMaxIDLength="6"/>
<Segment/>
and I think this stream is odd, but should be considered valid.

Dave Rice

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 14 Feb 2016 19:08:35 +0100

> I propose disallowing multiple level 0 within an EBML Document after the EBML Header. I think this is consistent with the analogy between EBML and XML, where XML may have an XML Declaration (equiva…

As mentioned on the DVD discussion, concatenation is a good way to
have different parts that don't have the same Track Info (for
instance) but are still tied together in one bigger entitity. There's
Segment linking but this makes it easier to pass the file.

The various segment (files) could be tar'ed but then you don't know
it's a Matroska file until you open the tar and parse what's inside.

> valid (two concatenated EBML Documents)

If that's valid, then it's fine with me. Although it should be noted
that in that case the second EBML header is not taken in consideration
and only the first one is used. That's to ensure the whole block of
concatenanted data can be handled just by knowing the first header.
Also that you don't mix different DocType in the same file (or do we
want to allow that ?). Meaning <EBML/><Segment/><Segment/> could also
be valid.

-- 
Steve Lhomme
Matroska association Chairman

---

From: Jerome Martinez <[email-masked]>
Date: Sun, 14 Feb 2016 20:09:10 +0100

> concatenanted data can be handled just by knowing the first header.

but if the second EBML header is different, analysis is wrong.
So if we say that only the first one EBML header should be read:
- we must state that we can concatenate files only if they have the same 
EBML header (so same Matroska version? I don't the reason we should 
mandate that Matroska versions are same)
- we must state that EBML header must be identical.

 From my point of view that does not make sense (why do we need to 
duplicate the EBML header in that case).

I am ok for having EBML header before each segment, but in that case the 
EBML header just before the segment should be considered as having the 
right info (e.g. Matroska version).

I am afraid about such file:
EBML header with Matroska v4 (from file 1)
Segment conforming to Matroska v4 (from file 1)
EBML header with Matroska v5 (from file 2)
Segment conforming to Matroska v5 (from file 2)

In the case we have first EBML header as the reference header, we parse 
second segment as Matroska v4 but it is actually v5.

> want to allow that ?). Meaning <EBML/><Segment/><Segment/> could also

Is there any reason we don't want different DocType? (and 
DocTypeReadVersion?)

Jérôme

---

From: Dave Rice <[email-masked]>
Date: Sun, 14 Feb 2016 14:14:38 -0500

> On Feb 14, 2016, at 2:09 PM, Jerome Martinez <[email-masked]> wrote:
> 
> - we must state that we can concatenate files only if they have the same EBML header (so same Matroska version? I don't the reason we should mandate that Matroska versions are same)
> From my point of view that does not make sense (why do we need to duplicate the EBML header in that case).
> 
> I am ok for having EBML header before each segment, but in that case the EBML header just before the segment should be considered as having the right info (e.g. Matroska version).
> 
> In the case we have first EBML header as the reference header, we parse second segment as Matroska v4 but it is actually v5.

Just a reminder that our current definition for EBML Stream (a concatenation of EBML Documents) is: "An EBML Stream is a file that consists of one or many EBML Documents that are concatenated together. An occurrence of a Level 0 EBML Header marks the beginning of an EBML Document."

The current definition doesn't include the presumptions that we're currently discussing. The documentation doesn't prevent a variety of EBML docTypes could be concatenated and streamed.

> Is there any reason we don't want different DocType? (and DocTypeReadVersion?)
> 
> Jérôme
> 
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Dave Rice <[email-masked]>
Date: Sat, 27 Feb 2016 16:09:48 -0500

Hi all,

> On Feb 14, 2016, at 2:14 PM, Dave Rice <[email-masked]> wrote:
> 

The issues within this thread are still open. To re-state the conversation I think these questions are unresolved:

- Can an EBML Document contain more than one Root Element? ie is this structure valid or invalid as an EBML Document?
<EBML/>
<Segment/>
<Segment/>

Related to the above question, the “Segment” element is currently allowed to repeat within an EBML Document. Should it be set to non-repeat?

When multiple EBML Documents are concatenated together it is considered an EBML Stream, like this:
<EBML/>        \ EBML Document #1	\
<Segment/>    /					\ EBML Stream #1
<EBML/>		\EBML Dcoument #2	/
<Segment/>    /					/

When there is more than one EBML Document within an EBML Stream, MUST all the EBML Headers be identical? ie is it valid to stream webm and matroska together or stream matroska v2 and matroska v4 together?

Best Regards,
Dave Rice

---

From: Moritz Bunkus <[email-masked]>
Date: Sun, 28 Feb 2016 12:08:27 +0100

Hey,

I haven't replied to this yet as I'm unsure myself. I also don't think
we've ever really talked about those points. We wanted to (maybe) allow
files created by binary concatenation to be valid – however, we never
wanted to require players to support such files.

Meaning this might be OK (though I'm not in favor of it anymore, see
below):

<EBML/>
<Segment/>
<EBML/>
<Segment/>

We've never talked about using EBML Documents of differeing DocTypes in
the same file, though.

I'm also unsure whether or not we've ever talked about having multiple
segments in the same file. We've only ever talked about linking segments
that are located in different files via mechanisms like
NextUID/PrevUID/SegmentUID for thinks like menu systems etc.

> The issues within this thread are still open. To re-state the
> conversation I think these questions are unresolved:
>
> - Can an EBML Document contain more than one Root Element? ie is this
>   structure valid or invalid as an EBML Document?
> <EBML/>
> <Segment/>
> <Segment/>

I'd prefer this to be invalid, mostly in order to keep required
complexity in readers/players low.

> Related to the above question, the “Segment” element is currently
> allowed to repeat within an EBML Document. Should it be set to
> non-repeat?

Following my wish above: ues, it should be set to non-repeat.

> <EBML/>		\EBML Dcoument #2	/

A tougher decision. I also consider such files (and binary concatenation
of files in general) to be a travesty that only increases the complexity
of requirements for players a lot. There's also no real advantage to
using both EBML Documents in the same file instead of two separate
files.

Therefore I'd vote for not allowing this either.

> When there is more than one EBML Document within an EBML Stream, MUST
> all the EBML Headers be identical? ie is it valid to stream webm and
> matroska together or stream matroska v2 and matroska v4 together?

Yeah, exactly… One of the reasons why I don't like this. It creates all
kinds of ambiguity, complexity, which in turn leads to more code paths
that must be tested, and as such files are super rare those won't be
tested a lot if at all. Drawbacks on top of drawbacks.

Kind regards,
mosu

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 28 Feb 2016 15:22:11 +0100

2016-02-14 20:09 GMT+01:00 Jerome Martinez <[email-masked]>:
>>> "An EBML Schema MUST declare exactly one Element at Level 0 (referred to
>>> as the Root Element) that MUST occur exactly once within an EBML Document.
>>> The Root Element MUST be mandatory and MUST be defined to occur exactly
>>> once. Note that the EBML and Void Elements may also occur at Level 0 but are
>>> not considered to be Root Elements."
>>>
> EBML header (so same Matroska version? I don't the reason we should mandate
> that Matroska versions are same)
> EBML header just before the segment should be considered as having the right
> info (e.g. Matroska version).
>

I think we need more precision on the way compatible Doctypes can be
handled. It may be per format and not a rule set for all EBML
documents. For example mixing Matroska v1, v2 and v3 is fine as long
as you know beforehand you need v3 compatibility (so maybe it's ok
only if it appears first). You could also mix WebM and Matroska
Doctypes in the real world and still be okay.

IMO at the EBML level (not knowing semantics) there's no reason to
restrict mismatching Doctypes. The thing we should restrict is whether
there's always an EBML header before an EBML content. IMO that should
be mandatory.

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 28 Feb 2016 15:27:53 +0100

> using both EBML Documents in the same file instead of two separate

I can see advantages when transmitting some complex presentation
(linked segments, menus, etc). It's easier to send one file over
dropbox or on/to your phone rather than download and manage a bunch of
files that you always have to make sure to keep together. Dealing with
folders or RARs/TARs on phone is not exactly easy and very prone to
errors.

Another advantage, as seen above is that we can enforce some rules of
what segments are allowed to be tied together. There's also no naming
or ordering issues. They appear in the concatenation in the most
logical order.