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

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Fri, 4 Mar 2016 20:15:11 +0100

28.02.2016, 15:22 Steve Lhomme:
> 2016-02-14 20:09 GMT+01:00 Jerome Martinez <[email-masked]>:
>> On 14/02/2016 19:08, Steve Lhomme wrote:
>>>
>>> 2016-02-14 18:33 GMT+01:00 Dave Rice <[email-masked]>:
>>> [...]
>>>
>>>> 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/>
>>>
>>> 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.
>>
>>
>> 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)
> 
> 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.

It appears that you don't have reached a consensus on the question
whenever such structures should be valid.

EBML should remain open to that. Then something building upon it can use
it, forbid its use or restrict it. Matroska could make use of it, but
IMO it should be optional for a player to support such a file.

The thing with having it in EBML in general is that you couldn't mix
(with) Doctypes that forbid it.

To me it seems like it would create some overhead in the code. Just
guessing.

You could mix WebM and Matroska Doctypes, but Firefox will not play a
Matroska file.

How would a player or an editor have to handle files where it would
support Matroska v4, but not v5? Skip the v5 segment? Refuse to handle
the file altogether?

WebM and Matroska is the same problem, someone choose to implement only
WebM (maybe because of the restriction in codecs) and has to decide what
to do.

What if some segment is invalid? Does it make the whole file invalid?

> 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.
> 
>> In the case we have first EBML header as the reference header, we parse
>> second segment as Matroska v4 but it is actually v5.
>>
>>
>>> 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.
>>
>>
>> Is there any reason we don't want different DocType? (and
>> DocTypeReadVersion?)
>>
>> Jérôme
>>
>>

Regards,
Sebastian

---

From: Dave Rice <[email-masked]>
Date: Mon, 7 Mar 2016 00:15:30 -0500

> On Mar 4, 2016, at 2:15 PM, Sebastian G. <bastik> wrote:
> 

I agree. I think it appears that there’s consensus for (please correct me if I’m wrong):
- EBML should allow EBML Documents to be concatenated as an EBML Stream
- each EBML Document must contain an EBML Header and one Root Element (Segment for matroska/webm)

I think we also don’t yet have consensus on:
- What extra requirements should Matroska place on EBML Streams of Matroska/webm files (should docTypes and versions be known before the whole stream is read)
- Should players in any cases be expected to support EBML Streams (either of consistent type/versions or not)?

I propose to change Segment to mandatory and non-repeating within an EBML Document.

Back to the original question of this thread. Any objections with a proposal like this statement for the EBML specification:

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

> You could mix WebM and Matroska Doctypes, but Firefox will not play a

That makes sense. A matroska player is more complex than a webm player. Still I would love to see Firefox as a comprehensive Matroska player.
Dave

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 13 Mar 2016 14:42:20 +0100

> I propose to change Segment to mandatory and non-repeating within an EBML Document.

That sounds right to me. In the context of the EBML Document there
should only be one Segment. Having multiple "EBML Document"
concatenated is a higher level definition than what the amount of
elements are allowed at a certain level ((0 in this case). Is it what
you call an EBML Stream ? In that case, that seems correct to me.

> "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 de…

LGTM.

-- 
Steve Lhomme
Matroska association Chairman

---

From: Dave Rice <[email-masked]>
Date: Sun, 13 Mar 2016 11:35:30 -0400

> On Mar 13, 2016, at 9:42 AM, Steve Lhomme <[email-masked]> wrote:
> 

That understanding matches mine. That an EBML Document is comprised of one EBML Element and one Root Element (Segment in mkv/webm) and optionally VOID Elements. Many EBML Documents may be concatenated into an EBML Stream (some constraints on EBML Streams are still in open discussion).

Pull request submitted here: https://github.com/Matroska-Org/foundation-source/pull/11

>> "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 d…

Pull request submitted here: https://github.com/Matroska-Org/ebml-specification/pull/58