[Matroska-devel] EBML

[Steve Lhomme]

Martin Nilsson wrote:

> http://pike.ida.liu.se/generated/ebml.txt

[Isn't markup better than meta, since it's really markup we are doing?]

Yes.

You might add that EBML is octet/byte aligned (in addition of the 
network byte ordering). That would be a good addition to the VINT 
definition.


"As an example ID 1 from class A, encoded as 0x81, and ID 1 from class 
B, encoded as 0x4001, are considered different IDs."

Interresting point that was never raised before. IMO it should be 
avoided to use this case. And that's what we did with Matroska. It could 
impose some constraints on the parser behaviour which is IMO not 
necessary. I think there is enough IDs to avoid this (and BTW that means 
the number of IDs for class B, C and D are wrong because they should not 
contain elements of the other class).

The overlapping is allowed for the size coding and is actually needed as 
you mention (This allows for the element data to shrink without having 
to shrink the width of the size descriptor).


[Why not 0 bytes for 0?]

Good question. We never thought about that before. That could be a funny 
enhancement (although it would be harder to change a value that has no 
space for it).


"A string MAY be zero padded at the end."

You might add this to you ABNF notion (but I could no write it myself ;)
idem for UTF-8


"DATE = 8BYTE

Signed, 64-bit (8 byte) integer describing the distance to the beginning 
of the millennium"

You might add that it's in nanoseconds.



FYI, one of the EBML enhancement that is planned is to allow some kind 
of embedded DTD inside the EBML header, that would describe the 
hierarchy of the elements, their ID and their type (all in EBML format 
of course). This way it would be easy to spot known/unknown elements and 
interpret the value of some elements (maybe even with a human friendly 
name) even if you don't know the actual meaning.


I'm going to check the second chapter next.