Subject: Re: [Cellar] [Matroska-users] Max value for VINT

From: Dave Rice <[email-masked]>
Date: Mon, 5 Sep 2016 16:05:25 -0400

Hi Iovu,

I’m cc’ing the CELLAR mailing list since the topic is relevant to current work there.

> On Sep 5, 2016, at 3:46 PM, Ion Iovu <[email-masked]> wrote:
> 
> Hi guys. 
> 
> I'd like to know what the maximum value for the VINT is. The RFC draft <https://matroska.org/contact/index.html> page mention examples of VINT values with up to a tail of 3 bytes, however no mention of any upper limit for VINT is mentioned.

The 2004 RFC draft <https://matroska.org/technical/specs/rfc/index.html> on matroska.org is superseded by the current work of the IETF CELLAR <https://datatracker.ietf.org/wg/cellar/> working group. The current RFC for EBML is a work in progress at https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown.

> It can be inferred from the following text:
> 
> “Since the highest value is used for unknown size the effective maximum data size is 2^56-2, using variable size integer width 8.”
> 
> that particularly for element sizes you can only go to at most 8 bytes (a tail of 7 bytes), 
> 2^56-1 is a reserved one, and valid values are in the range 0..2^56-2

That’s right. The spec we’re working on includes a clarification on this:

"An Element Data Size with an octet length of 8 is able to express a size of 2^56-2 or 72,057,594,037,927,934 octets (or about 72 petabytes). The maximum possible value that can be stored as Element Data Size is referred to as VINTMAX."

> However, that does not mean the VINT as a data type is limited by that value.

Within the EBML Body the max length of the Element Data Size is declared in the EBML Header in EBMLMaxSizeLength. For Matroska that is limited to 8, which provides a VINTMAX of 72,057,594,037,927,934; however another EBML format could permit the EBMLMaxSizeLength to be values higher than 8, if you find the 72,057,594,037,927,934 bytes too constraining.

> Is it possible to go with a VINT_ALIGNMENT of more than 8 bits?

Hmm, the term VINT_ALIGNMENT is in the superseded 2004 RFC Draft <https://matroska.org/technical/specs/rfc/index.html> but in the new RFC work it is just referred to as zero-padding.
VINT_ALIGNMENT of greater than 8 bits is not allowed in Element IDs since they are required to use the shortest valid encoding, but an Element Data Size may use more than 8 bits of zero-padding (aka VINT_ALIGNMENT).

For instance, both 0b10000001 and 0b0000000100000000000000000000000000000000000000000000000000000001 (a VINT_ALIGNMENT of 55 bits) are valid methods to express a VINT of Element Data Size of 1.

[…]

Best Regards,
Dave Rice