Re: conflicts between EBML specs and MKV specs

Dave Rice <[email protected]> Sun, 30 Aug 2015 21:09:37 -0400
Newsgroups	gmane.comp.multimedia.matroska.devel
Message-ID	<[email protected]>
> On Jul 20, 2015, at 2:21 AM, Steve Lhomme <[email protected]> wrote:
> 
> 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).

I created this PR to make 'matroska' DocType default https://github.com/Matroska-Org/ebml-specification/pull/22, but note that this forum seems to contradict it. Personally I think having a 'matorska' default is a bit presumption and because docType is the only mandatory EBML header element without a default value, this change means that mkv values could start with an empty EBML Master-element, which seems a little weird but possibly fine.

If this PR is reject I'll create a new one to remove matroska as default of doctype in the mkv spec.

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

Since EBML is XML-like, I think allowing more than 1 top level element is odd. The most cases there are two top level elements: EBML and Segment. I see the EBML element as analogous to the XML declaration "<?xml blahblah>" which is itself not considered an element, I think this is okay. Since the Void element is similar to what whitespace would be in XML this is fine too.

I made a change in this PR: https://github.com/Matroska-Org/ebml-specification/pull/23 <https://github.com/Matroska-Org/ebml-specification/pull/23>.

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

I don't think CRC should be allowed at zero 0. The EBML spec version of CRC's definition is "is computed on all the data from the last CRC element (or start of the upper level element)" but a level 0 CRC would have no "last CRC" and no "upper level element", so there's no proper context for it. In this case I suggest change the MKV spec to make CRC be level 1+.

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

[...]

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
signature.asc (application/pgp-signature, 801 B)