Extensible Binary Meta Language
updated by
- rfc-9559 — Matroska Media Container Format Specification
Extracted elements (30)
A VINT may be encoded at an octet length larger than strictly required in order to reserve space for overwriting at a later date — e.g., when the final size of an Element is unknown at write time. All encodings of the same integer value are semantically identical regardless of VINT length.
EBML separates structure from semantics in a manner analogous to XML: the binary structural layer is defined by this RFC, while semantic layers are defined by separate EBML Schemas (analogous to XML Schemas). This allows the same structural framing to be reused by multiple unrelated formats such as Matroska and WebM.
EBML backward compatibility allows a reader that supports a DocType version equal to or higher than the DocTypeReadVersion to read the document. Forward compatibility is not guaranteed: if a reader does not support the exact DocTypeVersion, it may not be able to interpret newer Elements introduced in that version.
A String Element MUST either be empty or contain only printable ASCII characters in the range 0x20 to 0x7E, with the exception of null-byte termination (Section 13). A UTF-8 Element MUST contain only valid Unicode as defined in RFC 3629.
An EBML Document MUST start with an EBML Header and MUST NOT contain any data outside EBML Elements. The EBML Header of an EBMLVersion 1 Document MUST only contain Elements defined in RFC 8794.
An EBML Element with 'unknownsizeallowed' set to true MUST NOT also have 'recursive' set to true, and its Parent Element MUST also have 'unknownsizeallowed' set to true. Non-Master Elements MUST NOT set 'unknownsizeallowed' to true.
An EBML Schema MUST declare exactly one Root Element (occurring exactly once in the EBML Body), MUST document all EBML Body Elements, and MUST NOT reuse Element ID 0x1A45DFA3 (reserved for the EBML Header). The DocType value MUST be unique and registered in the IANA EBML DocTypes registry.
Any data contained within a Master Element that is not part of a recognized Child Element MUST be ignored by the EBML Reader.
Each Variable-Size Integer MUST contain exactly one VINT_MARKER. The VINT_DATA MUST be zero-padded to the left so the entire VINT is octet-aligned, and VINT_DATA MUST be expressed as a big-endian unsigned integer.
EBMLReadVersion MUST be less than or equal to EBMLVersion. DocTypeReadVersion MUST be less than or equal to DocTypeVersion. These constraints ensure backward-compatible versioning.
If an Empty Element (zero-length Element Data) has a declared default value, the EBML Reader MUST interpret its value as that default. If no default is declared, the reader MUST use 0 for numbers and an empty string for strings.
The Element IDs of Root-Level and Top-Level Elements SHOULD be at least 4 octets in length to reduce the risk of false positives during EBML Stream parsing.
The VINT_DATA component of an Element ID MUST be encoded at the shortest valid length. Additionally, VINT_DATA of an Element ID MUST NOT be set to all zeros or all ones.
Unknown-Sized Elements MUST only be used if the Element Data Size is not known before the Element Data is written, such as in some cases of datastreaming. Only Master Elements are permitted to be unknown-sized.
An EBML Document consists of exactly two components: an EBML Header followed by an EBML Body. The EBML Header (Element ID 0x1A45DFA3) declares the DocType, version numbers, and constraints (EBMLMaxIDLength, EBMLMaxSizeLength) that govern the EBML Body.
An EBML Schema is a well-formed XML document using the namespace 'urn:ietf:rfc:8794' that defines every Element of an EBML Document Type via <EBMLSchema>, <element>, <documentation>, <implementation_note>, <restriction>, <enum>, and <extension> nodes.
An EBML Stream is a file of one or more concatenated EBML Documents. Each EBML Document begins with an EBML Header at the Root Level; encountering a new EBML Header signals the start of a new EBML Document and the end of the previous one.
An Unknown-Sized Element has an Element Data Size with all VINT_DATA bits set to one. Only a Master Element may be unknown-sized, and only when the EBML Schema sets 'unknownsizeallowed' to true. Its end is determined by the first occurrence of a valid Parent, sibling, Root, or end-of-document boundary.
EBML defines eight Element types: Signed Integer (0–8 octets, two's complement, big-endian), Unsigned Integer (0–8 octets, big-endian), Float (0, 4, or 8 octets, IEEE 754), String (ASCII 0x20–0x7E), UTF-8, Date (0 or 8 octets, nanoseconds from 2001-01-01T00:00:00 UTC), Master (container), and Binary.
EBML versioning uses two independent version axes: the EBML Header version (EBMLVersion / EBMLReadVersion) and the EBML Document body version (DocTypeVersion / DocTypeReadVersion). A reader can process the document if it supports the EBMLReadVersion or any higher version it also supports.
Identically Recurring Elements MAY appear multiple times within the same Parent Element; each recurrence MUST be identical in storage and semantics. They SHOULD include a CRC-32 Child Element for data resilience. If multiple copies exist with a valid CRC-32, the first valid copy is used.
The CRC-32 Global Element (Element ID 0xBF) may appear as a Child Element of any Master Element and stores a 32-bit CRC covering all Element Data of its Parent except the CRC-32 Element itself. The Void Element (Element ID 0xEC) is used to overwrite data or reserve space.
RFC 8794 creates the 'EBML DocTypes' IANA registry for registering EBML Document Type identifiers (the string value stored in the DocType Element). The DocType value for any EBML Document Type MUST be unique, persistent, and listed in this registry.
RFC 8794 creates the 'EBML Element IDs' IANA registry for registering EBML Element ID values, with policies based on the octet length of the Element ID.
EBML parsers must guard against maliciously crafted documents that exploit recursive or deeply nested Master Elements, extremely large declared Element Data Sizes, or Unknown-Sized Elements to cause excessive memory allocation, CPU consumption, or incorrect boundary detection.
A Date Element MUST be 0 or 8 octets and stores a signed 64-bit integer (same encoding as Signed Integer) expressing nanoseconds relative to 2001-01-01T00:00:00.000000000 UTC, covering dates from approximately 1708 to 2293.
A Float Element MUST be exactly 0, 4, or 8 octets. The 4-octet and 8-octet forms use the IEEE 754 32-bit and 64-bit binary interchange formats respectively, stored big-endian.
A Variable-Size Integer (VINT) encodes its own length using a leading VINT_WIDTH (zero or more '0' bits), a VINT_MARKER (single '1' bit), and VINT_DATA. A 1-octet VINT supplies 7 bits of data; each additional octet adds 7 more bits. VINT_DATA MUST be zero-padded on the left and expressed as a big-endian unsigned integer.
An Element ID is a VINT of 1–4 octets by default (EBMLMaxIDLength may allow more). The VINT_DATA of an Element ID MUST NOT be all '0' bits or all '1' bits, and MUST be encoded at the shortest valid VINT length.
Element Data Size is a VINT of 1–8 octets by default (EBMLMaxSizeLength may extend this). Unlike Element IDs, Element Data Size VINT_DATA is not required to be at the shortest valid length. An all-ones VINT_DATA is reserved to signal unknown size.