Subject: [Cellar] My review of the EBML-specifications

From: Andreas Rheinhardt <[email-masked]>
Date: Wed, 13 Feb 2019 17:11:00 +0000

Hello,

I know that I am late to the party and I am sorry for that, but better
late than never. Those of you who follow the github repositories will
already know of the issues I raised there; here is a summary for those
who don't:

1. The EBML specs currently include a requirement that all VINT in the
EBML Header may not exceed four bytes in length. This is a sensible
requirement, but it unfortunately invalidates every Matroska and Webm
file ever produced by libavformat/ffmpeg: The length of the EBML
element is always coded on eight bytes. This PR is about this:
https://github.com/Matroska-Org/ebml-specification/pull/219

2. Inspired by Matroska PR #278
(https://github.com/Matroska-Org/matroska-specification/pull/278)
which intends to allow readers to infer the existence of mandatory
elements with default values that exist in Matroska, but not in Webm I
asked what happens when a new version of the same DocType has a new
mandatory element with default value that is missing in an older
version of the same EBML Schema that a file conforms to. MAY, SHOULD,
MUST or MUST NOT the reader infer the existence of this element? See
this issue: https://github.com/Matroska-Org/ebml-specification/issues/221

3. The current proposal for the EBML Element ID Registry does IMO not
really include safeguards against allocating an element that is
already in use. I.e. one could register a three byte Element ID that
is already in use in Matroska (or any existing project), so that an
EBML reader for Matroska would know two different elements with the
same ID, one element only being permissible in the EBML Header and the
other only permissible in the EBML Document. Not good. Here is my take
on this: https://github.com/Matroska-Org/ebml-specification/issues/222

4. A few Matroska elements have complex default values. For example,
the default value of BlockDuration is the DefaultDuration of the
track. So evaluating the default value would mean that the EBML reader
knows about the internals of the Block structure although said Block
is supposed to be a binary blob for the EBML reader. See
https://github.com/Matroska-Org/ebml-specification/issues/224 for more.

5. And then there are two little PR:
https://github.com/Matroska-Org/ebml-specification/pull/220 and
https://github.com/Matroska-Org/ebml-specification/pull/223.

Greetings
Andreas Rheinhardt

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Feb 2019 16:15:16 -0500

Thank you for these comments!

    > https://github.com/Matroska-Org/ebml-specification/pull/219

The EBML requirement on VINT size applies to the EBML Header itself,
not to the contents of the Doc.  It is not clear that it applies to users of
EBML such as inside the Matroska component.

    > on this: https://github.com/Matroska-Org/ebml-specification/issues/222

The IANA process is that Matroska gets it's own Element ID space,
different from WebM, but never conflicting with the registry in the
EBML header.

So I am not sure I understand your scenario.
Can you explain further?

    > the default value of BlockDuration is the DefaultDuration of the

I'm not sure that I understand how this is an EBML issue.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andreas Rheinhardt <[email-masked]>
Date: Thu, 14 Feb 2019 00:58:00 +0000

Hello,

> Thank you for these comments!

And thanks for your answer!
> EBML such as inside the Matroska component.

a) You seem to read "every Matroska and Webm file ever produced by
libavformat/ffmpeg" as "this affects only the Matroska component (i.e.
the EBML Body) of said files". This is not so. libavformat encodes the
size of the EBML Element (the element with ID 0x1A45DFA3 that is part
of the EBML Header of the Matroska/Webm files produced by libavformat)
on eight bytes. The current requirement invalidates such files. Given
that the current requirement has been added years after such files
were around, it has to be dropped.

b) In my opinion the requirements on the VINT size are clear as they
are. (It's just that they conflict with past and current practices.)
If you believe that the requirements are unclear, then I would like to
know what is unclear for you and why.
> So I am not sure I understand your scenario.

Let me summarise the current proposal as I understand it:
i) An IANA registry for the EBML elements in the EBML Header is created.
ii) The process for registering numbers. This includes a "First come
first served" policy for certain ranges like Element IDs with a size
of three octets.
iii) An IANA Doctype Registry.

You claim that the Matroska Element ID space will never conflict with
the registry in the EBML Header. I fail to see the safeguards for
this. After all, the IANA registry is only about the EBML Header
elements, it does not contain the Element IDs used by any given EBML
Schema. So how does the IANA know that an application for registration
of an ID already in use by a project should be rejected? In order to
do so, projects would not only need to register themselves on the
Doctype registry, but they would also need to give information (that
needs to be kept up-to-date) about their currently used Element IDs to
the IANA registration authority. And I don't see any requirement for
keeping such lists in the specification and also not a word about a
requirement on part of the registration authority to check the lists
of Element IDs when processing allocations. (I know that RFC 8126
requires compability with current usage, but as stated I fail to see
how the current proposal would enable the IANA to actually check this.)

And even if all these lists were existing and were kept-up-to-date at
all times, there is still another problem: If usage of EBML becomes
widespread with many projects being created, then IDs that are not in
use by any project might become scarce (in particular for shorter IDs
-- certainly for length 1 IDs and possibly for length 2 IDs), even
when all projects only need a fraction of the IDs.

My proposal for this is to reserve some IDs for use for future
extensions to the EBML Header. No EBML Schema may invade these
reserved IDs.

Given how valuable IDs with length one are, no such ID should be
reserved for this purpose. A few IDs with length two should be
reserved as should some length three elements and more length four
elements. Registering a shorter ID should of course be subject to
stricter scrutinity than registering a longer ID.

This proposal adversely affects the possibility of choosing an ID with
a nice extra property (like a nice ASCII representation).

The reserved ID ranges would of course need to be chosen in such a way
as not to conflict with elements already in use by Webm and Matroska.

> I'm not sure that I understand how this is an EBML issue.

The form that the default values can take is currently undefined.
Defining (i.e. restricting) it is an EBML issue. Bringing Matroska's
specification in line with what we define for EBML won't be an EBML
issue, of course, but a Matroska one.

It should be clear that evaluating something like the default value of
Matroska's BlockDuration is impossible to do at the EBML layer
(because then you need to know the internals of the Block structure).
But something like "the default value is the value of another element
(of the same type) that is a child of the same parent element" is
possible (the other element needs to be mandatory for this to work or
one uses a secondary default value in case the other element doesn't
exist). Of course one can also restrict default values to known
constants (constexpr). We need to decide where to draw the line.

- Andreas Rheinhardt

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Feb 2019 20:12:42 -0500

> iii) An IANA Doctype Registry.

iv) the Matroska document will create a new IANA Registry for Element IDs
    in use by Matroska

v) The *Matroska document* will populate the EBML Element ID registry with
   a list of ElementIDs RESERVED.  No *EBML* Element ID may be created
   with the same number.
   This is largely as a COURTESY, because in fact the two name spaces
   are intended to be distinct across header and contents, but it's better if
   there is no reuse.

    > when all projects only need a fraction of the IDs.

It's possible.

    > extensions to the EBML Header. No EBML Schema may invade these

That's a reasonable proposal.

    > stricter scrutinity than registering a longer ID.

We could set the IANA rules all IDs with length two to Specification Required.

    > a nice extra property (like a nice ASCII representation).

Those are likely 4-byte elements, of which there are many.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 17 Feb 2019 16:47:25 +0100

>    are intended to be distinct across header and contents, but it's better if

I agree. They are different name spaces so even if the same element
IDs are used in both it shouldn't matter to a reader. Given an ID
needs a Path to be interpreted, you may even find the same ID in
different places with different Pathes. (This is not described as such
in the EBML IANA registries for IDs but it should probably be for
Matroska)

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 17 Feb 2019 17:58:41 +0100

> https://github.com/Matroska-Org/ebml-specification/pull/223.

My reply on github:

This is a real issue. Right now there is no restrictions on what can
be put in the `default` attribute of each element (nor in `size`,
`label`). That should be fixed.

As for how to interpret the value we could define a syntax but that
would take forever and block this document. I think it's a good thing
that default values may be very complex things depending on the
context (Matroska can't do without). We need to keep this possibility.

For machine readable purposes it's important that the Schema says if
an element has a default value or not even if the value is not
interepreted. For example in `mkvalidator` it allows checking things
are correct or missing, without having to know if the context is
legit.

I think escaping the `default` value when it's not a direct value
could work. Another way would be to add an extra attribute for which
the `default` value cannot be interpreted as such.

In Matroska there is:

    * BlockDuration using `DefaultDuration`

    * DisplayWidth using `PixelWidth - PixelCropLeft - PixelCropRight`

    * DisplayHeight using `PixelHeight - PixelCropTop - PixelCropBottom`

    * OutputSamplingFrequency using `SamplingFrequency`

-- 
Steve Lhomme
Matroska association Chairman

---

From: Andreas Rheinhardt <[email-masked]>
Date: Mon, 18 Feb 2019 09:41:00 +0000

Steve Lhomme:
> `label`). That should be fixed
I agree, but before we talk about how to store the default value we
should clarify where to draw the line: It is clear that an EBML-only
reader (that uses Matroska's EBML Schema) will never ever be able to
evaluate the default value of BlockDuration as this requires parsing
the Block structure (to get the TrackNumber) although a Block is a
binary blob for an EBML reader. So this default element will have to
be handled at a higher level (at the Matroska layer). If you want to
have the information about the existence of a default value in EBML,
then one would need to add a stub EBML value.

But for the other values it would be possible in EBML as these are of
the form "The default value is the value of a function whose return
type is the same as the said element whose parameters are other
elements that are siblings to the current element.". (Said other
element would have to be mandatory for this to work.) As you said,
defining this rigorously would block this document, so that's
unfortunately not possible in version 1 of EBML. But the special case
of "The default value is the value of another element (of the same
type) that is a sibling to the current element" might be easily
definable and quite useful. So where do we draw the line? Do we
include or exclude the latter form of default value?

- Andreas

---

From: Andreas Rheinhardt <[email-masked]>
Date: Mon, 18 Feb 2019 11:32:00 +0000

>    are intended to be distinct across header and contents, but it's better if
I didn't think of this as a courtesy. After all, if these are distinct
namespaces with the potential for overlapping, then resynchronisation
might be affected (in case of errors). In order to prevent this, the
ID of the `EBML` element (`0x1A45DFA3`) should not be allowed to be
reused by any EBML Schema.

And I think it should be explicitly stated that these are different
namespaces. I read the document and thought (ok, I already believed
that before I read the document, but nevertheless) that it is not
allowed to reuse header EBML IDs for the EBML Body. My rationale was
that the EBML's own EBML Schema is part of any other EBML Schema
(either explicitly or implicitly). If this is not so, then we might
need to clarify the following statement:

"An EBML Schema MAY constrain the use of EBML Header Elements (see
EBML Header Elements) by adding or constraining that Element's range
attribute. For example, an EBML Schema MAY constrain the
EBMLMaxSizeLength to a maximum value of 8 or MAY constrain the
EBMLVersion to only support a value of 1. If an EBML Schema adopts the
EBML Header Element as-is, then it is not required to document that
Element within the EBML Schema. If an EBML Schema constrains the range
of an EBML Header Element, then that Element MUST be documented within
an <element> node of the EBML Schema."

So some Header Elements are documented in an EBML Schema. According to
the wording of `Element ID` ("used to uniquely identify a defined EBML
Element within a specific EBML Schema") this means that the documented
EBML Header IDs MUST NOT be reused for the EBML Body. But I don't
think it makes sense to base the decision whether an ID may be reused
or not on whether the Header Element with said ID is constrained or not.

>     > when all projects only need a fraction of the IDs.
Actually not. If the namespaces are distint, then the above scenario
can't happen.
> We could set the IANA rules all IDs with length two to Specification Required.
That won't be required if the namespaces are distinct.

- Andreas

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 20 Feb 2019 18:16:05 -0800

> namespaces. I read the document and thought (ok, I already believed

To be fair, the current document does explicitly state this in 15.1, 
"This IANA Registry only applies to Elements contained at least in the 
EBML Header, thus including Global Elements." (minor nit: "at least" is 
a bit awkward, "that can be contained in the EBML Header" might be clearer).

> an <element> node of the EBML Schema."

Your rationale here is logical and I agree this could use clarification. 
The text I quoted above relies on an implied equivalence between Element 
ID namespaces and IANA registries, but that isn't explicitly stated 
anywhere, and the text you quote seems to contradict this. Having two 
separate IANA registries for the same namespace seems like it would be 
problematic, but I suppose that is the issue you are raising.

> That won't be required if the namespaces are distinct.

But isn't that (that length-two IDs are Specification Required) what the 
document currently says? (this question is for Michael)

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 24 Feb 2019 10:07:05 +0100

> include or exclude the latter form of default value?

It does seem reasonable to add this one case. But on second thought it's 
not that easy either. It may be the value of another field but is it in 
the same parent, in another parent, if so which one and how to target it 
properly ? I think it opens a can of worms that should not be opened for 
now.

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 26 Feb 2019 12:48:08 +0100

> reused by any EBML Schema.

The resynchronization is indeed a good case for avoiding reuse. I'm less 
sure about the sub element IDs of the EBML header. On one hand there's 
not many so it's not a big restriction on the main EBML-based format. On 
the other hand the number might grow in the future and collide with 
EBML-based formats that used the same IDs.

IMO it still goes down to the namespace. The ID makes sense at one level 
and none at any other level. So reusing the ID should not be an issue. 
This is by design. The same ID in different places could be used and 
this is fine.

So IMO we should add a note that the 0x1A45DFA3 cannot be used anywhere 
in the EBML-based format, as well as the EBML global elements.

> need to clarify the following statement:

I think it's OK to say the EBML Header Schema is included in the EBML 
Document. That's also a reason why the EBML 0x1A45DFA3 ID is unique, 
because there cannot be another at the same level with the same ID.

> an <element> node of the EBML Schema."

Sounds good.

> or not on whether the Header Element with said ID is constrained or not.

IMO it's only for elements in the same path, so it can only happen for 
the 0x1A45DFA3 one.

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

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 26 Feb 2019 18:29:50 +0100

On 21/02/2019 03:16, Timothy B. Terriberry wrote:
> EBML Header, thus including Global Elements." (minor nit: "at least" 
> is a bit awkward, "that can be contained in the EBML Header" might be 
> clearer).

I created a Pull Request to fix this oddity 
https://github.com/Matroska-Org/ebml-specification/pull/232

> Your rationale here is logical and I agree this could use 
> clarification. The text I quoted above relies on an implied 
> equivalence between Element ID namespaces and IANA registries, but 
> that isn't explicitly stated anywhere, and the text you quote seems to 
> contradict this. Having two separate IANA registries for the same 
> namespace seems like it would be problematic, but I suppose that is 
> the issue you are raising.
>
> But isn't that (that length-two IDs are Specification Required) what 
> the document currently says? (this question is for Michael)
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Feb 2019 10:45:58 -0500

> The resynchronization is indeed a good case for avoiding reuse. I'm less sure
    > about the sub element IDs of the EBML header. On one hand there's not many so
    > it's not a big restriction on the main EBML-based format. On the other hand
    > the number might grow in the future and collide with EBML-based formats that
    > used the same IDs.

Should the resynchronization goals be stated somewhere?

    > IMO it still goes down to the namespace. The ID makes sense at one level and
    > none at any other level. So reusing the ID should not be an issue. This is by
    > design. The same ID in different places could be used and this is fine.

    > So IMO we should add a note that the 0x1A45DFA3 cannot be used anywhere in
    > the EBML-based format, as well as the EBML global elements.

Exactly.