Re: EBML specification component for review - Element Data Size

On Thu, 30 Apr 2015 15:03:48 -0400
Erik Piil <[email protected]> wrote:

> This discussion relates to the “Element Data Size” portion of the earlier
> EBML RFC Draft for revision/incorporation into the final EBML
> specification.
> 
> From the RFC Draft:
> 
> Element Data Size
> 
> The EBML element data size is encoded as a variable size integer with, by
> default, widths up to 8. Another maximum width value can be set by setting
> another value to EBMLMaxSizeWidth in the EBML header. See section 5.1.

What's the point of such a header?

> There is a range overlap between all different widths, so that 1 encoded
> with width 1 is semantically equal to 1 encoded with width 8. This allows
> for the element data to shrink without having to shrink the width of the
> size descriptor.
> 
> Values with all data bits set to 1 means size unknown, which allows for
> dynamically generated EBML streams where the final size isn't known
> beforehand. The element with unknown size MUST be an element with an
> element list as data payload. The end of the element list is determined by
> the ID of the element. When an element that isn't a sub-element of the
> element with unknown size arrives, the element list is ended.

In the context of Matroska, I'd disallow unknown lengths in almost all
contexts (i.e. disallow them by default, allow them only when
explicitly specifified). Because they make demuxing a pain, and most
Matroska demuxers probably support unknown length at a few places at
best.

> Since the highest value is used for unknown size the effective maximum data
> size is 2^56-2, using variable size integer width 8.
> 
> 
> Any thoughts are most appreciated.
> 
> 
> Best,

_______________________________________________
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