[Matroska-devel] EBML data type constraints

Jerome Martinez jerome at mediaarea.net
Thu Jul 2 15:15:41 CEST 2015

Le 02/07/2015 14:43, wm4 a écrit :
> I agree. Though I'd lobby that strings with zero bytes are also 
> discouraged this way.

There is a difference between a non-existent string and an empty string 
(e.g. non-existent string means "take default" and empty string means 
"empty string is the actual value").
Such difference does not exist with integers (there is no "empty integer").
So if it is forbidden somewhere, it should be forbidden for integers only.

BTW, I am not convinced that we should say that 0-byte integers should 
be forbidden, we accept 0 as a value for integers having a size from 1 
to 8 bytes (and the "missing" bytes are considered as 0, we don't force 
the value 1 to be in an integer of 1 byte), so why not accepting a 
0-byte integer with a size of 0 and we handle it with the same algorithm?
The only issue I see is the legacy problem with demuxers in the wild 
which reject the 0-byte integer beause the spec on the Matroska site 
says "1-8". Is it enough for having 0-byte integers forbidden in the 
standard instead of filling a bug report for each demuxer? I don't know.

> Maybe calling them "deprecated" is the right wording?

"deprecated" is usually used for standardized formats which used to 
accept some content.
Here, there is no previous standard (there is no standard), so I would 
not use such term.
If it is forbidden in specs, I would just use something like:
Muxers MUST NOT store 0-byte integers
Demuxers SHOULD accept 0-byte integers and interpret them as 0.
which is pretty clear about the goal (=accepting "buggy" files).

More information about the Matroska-devel mailing list