Moritz Bunkus
Moritz Bunkus
libebml's code follows the old interpretation, too. [Here](https://github.com/Matroska-Org/libebml/issues/73) is the corresponding bug I've filed yesterday. Like I said, this is the RFC changing established interpretation of the specifications as they...
Sure, we could go that route. I'm also concerned about existing knowledge out there. For as long as EBML+Matroska has existed, developers were used to treat elements with default values...
> But if there's a second value to use we can't really tell if the default value is also assumed to be present or not. I disagree. I find the...
If we really need such a field[1], I propose the following: * Starts with the regular EBML ID & element size fields; let's call this size field `element_data_size` (in bytes)...
We always have the size field for the full element. There's really no need for _three_ size fields as we can always calculate the third size from the other two....
Great!
In my original proposal the denominator is a signed integer already. Not sure what you're missing there. Taking @hubblec4's suggestion into account, I revise my original proposal to: * Starts...
I actually explain my reasoning in the first bullet point of "Rationale".
The rationals in media containers are somewhat unusual in that for most use cases their denominator remains constant. I don't know whether having one more bit to play with in...
I'm strongly against storing CC data in this way. Repeating what I wrote in #375: > Personally I'd vote for "keep it subtitle, let CodecID speak for itself". We already...