Re: EBML data type constraints
Jerome Martinez <[email protected]>
| Newsgroups | gmane.comp.multimedia.matroska.devel |
|---|---|
| Message-ID | <[email protected]> |
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). _______________________________________________ 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