[Matroska-devel] Several (minor) issues or underspecified areas in the MKV spec

Dave Rice dave at dericed.com
Mon Oct 5 19:15:52 CEST 2015


Hi,

> On Oct 5, 2015, at 12:47 PM, Michael Bradshaw <mjbshaw at google.com> wrote:
> 
> On Mon, Oct 5, 2015 at 8:03 AM, Dave Rice <dave at dericed.com <mailto:dave at dericed.com>> wrote:
> I'm working on the EBML specification (the one being drafted on GitHub) quite a bit. What are the questions to EBML?
> 
> Preface: some of these are weird corner cases that are extremely unlikely to occur for anyone doing anything sane. That said, I think parsers should consistently (or even gracefully) handle the insane, and in order to do that I think these corner cases should be clarified in the spec.

Answers from my pov, feel free to correct me if wrong.
> Shouldn't EBMLMaxIDLength have a range of > 3 (given that the EBML element has an ID length of 4)?
Yes, it should be 4 or more, while EBML Schemas such as Matroska could refine it further (I think Matroska requires 4).
> Shouldn't EBMLMaxSizeLength have a range of > 0?
Yes.
> Can a global element (i.e. Void, CRC-32) occur before an EBML element?
Yes, but note that the EBML Element definition says: "Each EBML document has to start with this.". So the first element must be EBML. But EBML,Segment,VOID,EBML,Segment is valid. At VDD we discussed defining "EBML Document" and "EBML Stream" with in the spec, so we could say that each EBML Document must start with an EBML element but an EBML Stream may contain many EBML Documents.
> If so, are they considered part of the document (as is, it seems like an EBML document is implicitly defined as everything between an EBML header and then next EBML header (or EOF), in which case they are not considered part of the EBML document)?
I think defining EBML Document and EBML Stream can resolve this question too, so that a level 0 VOID could be considered part of an EBML Stream but not part of an EBML Document. .... Ah actually I should correct myself as I think EBML,Void,Segment would be a valid EBML Document and valid Matroska file where the Void element at level 0 appears to be part of the Matroska file.
> How should a EBMLMaxSizeLength > 8 be handled if it occurs after the element that needs it (specific edge case: DocType has a size length of 9, but DocType occurs before EBMLMaxSizeLength in the header; how should that be handled?) (alternate edge case: a Void element occurring in (or before) an EBML element with a size length is > 8 and occurring before EBMLMaxSizeLength). Should the spec explicitly require parsers to parse as if EBMLMaxSizeLength is 8 unless and until explicitly told otherwise?
Maybe the documentation for EBMLMaxSizeLength should be clarified as EBMLMaxSizeLength=8 does not mean that the payload of the EBML elements is limited to 8 bytes, it means that the size value of the EBML Element itself is restricted to 8 bytes. I believe that an 8 byte size statement provides something like 72 petabytes. I hope there are no docTypes greater than 72 petabytes in length ;).
> Do the limitations of EBMLMaxSizeLength apply to the document immediately? That is, if EBMLMaxSizeLength is 1, does that apply to elements in the EBML header immediately after it is encountered, meaning that if DocType followed it it must have a length < 127?
I presumed it applies to all Elements in the EBML Document or all Elements in the EBML Stream that appear before the next EBML Element.
> Typo in the EBML spec in the Length definition for the Binary data type: “A Master-element” should be “A Byte Element”
PR's welcome :)
> The EBML spec says that the Reserved ID (all bits set to 1) is the only ID that may change the Length Descriptor (the count of leading zeroes + 1). What exactly does it mean to "change the Length Descriptor?" Does this mean a Length Descriptor can be > 4 (even if EBMLMaxIDLength = 4) iff the ID is the Reserved ID?
Good question, though I'm not sure the answer, this is an older part of the EBML spec that pre-dates my work on it. Some related discussions on this are here: https://github.com/Matroska-Org/ebml-specification/pull/15 <https://github.com/Matroska-Org/ebml-specification/pull/15>

[...]

Best Regards,
Dave Rice

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20151005/cbab4579/attachment.html>


More information about the Matroska-devel mailing list