Re: conflicts between EBML specs and MKV specs

On Sun, Jul 19, 2015 at 10:26 PM, Dave Rice <[email protected]> wrote:
> Hi all,
> There is some overlap between the EBML specs at http://matroska-org.github.io/libebml/specs.html and the Matroska specs at http://matroska.org/technical/specs/index.html. I propose at some point that the EBML specs are removed from the Matroska specs and referenced rather than introduced redundantly

Agreed

> , but for now here is a list of where these two specifications disagree.
>
> DocType
> Within the EBML spec DocType has no default value while the Matroska spec says that ‘mastroska’ is the default value. Thus a Matroska parser would consider an EBML doc with no DocType element to be a matroska file while an EBML parser would read that as undefined or invalid.

That should be "matroska" for backward compatibility (also serves as a
reference for an existing format that make use of all current
possibilities).

> “Global Elements”
> In the EBML spec CRC-32 and Void Elements may appear at level 1 and higher. In the Matroska spec CRC-32 and Void are global elements "can be found at any level”. MKV specs allow Void/CRC at Level 0, but this is invalid for EBML. Is there anything out there that writes Void or CRC at level 0?

For Void I don't see why it wouldn't be found at level 0. I doubt
there are Matroska tools that write some because they only write one
Segment and that's it. But still, Void is fine at level 0. It's a good
placeholder for future editing.

CRC-32 makes less sense as it applies to all the previous elements
read at the same level. Although it's theoretically possible to handle
it, in libebml it would probably not be handled. IIRC it's only read
and processed when reading an EbmlMaster as a whole. Which doesn't
exist at level 0. And noone reads a Segment as a whole, but it might
may sense for smaller file formats.

> CRC
> The MKV spec adds this phrase to the CRC Element defintiion: "The CRC in use is the IEEE CRC32 Little Endian”. Is this complete?
>
> Signature
> There are a lot of level disagreements between the greyed out part of the Matroska spec and the EBML spec.

The odd part is that if you look at the HTML source code, the CSS
style name tells you what it means... It's either something that may
be used in the future or that should never be used. The signature may
work, but IMO it should be reviewed by specialists. I'd say we remove
it from the "final" EBML specs. And keep a copy somewhere. It could be
an additional RFC to augment EBML with signatures.

You have done that will
https://github.com/Matroska-Org/ebml-specification/pull/19

> For these conflicts is it safe to presume that the EBML spec is correct (‘matroska’ is not default for DocType, Void/CRC are level 1+)?

No, the Matroska specs were better maintained and updated.

> Best Regards,
> Dave Rice
> _______________________________________________
> Matroska-devel mailing list
> [email protected]
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel