[Matroska-devel] RFC 1134 - New EBML Block design

Paul Bryson paul at msn.com
Tue Jan 20 22:35:49 CET 2004

The idea of this post is to display a new Block design that is more flexible and
addresses issues with the current Block design.  From this point the new Block
design will be labeled Block2.

Block2 consists of three header sections.  TrackNumber, Time, and Bitflags.
Each header section is required and is coded for size using EBML coding methods.
The order of the headers are

1. TrackNumber
2. Time
3. Bitflags

The TrackNumber is an EBML UINT.  This number indicates the Track that the data
blocks contained within the Block2 belong to.

The Time is an EBML SINT that is used to calculate the timecode of the Block2.
Exact method depends on the bitflags used below.

The Bitflags are a set of bits used as flags to indicate Block2 structure.
Default value of all Flags are 0.  If an unknown flag is set to 1, the Block2
should be discarded by the parsers.

Bitflags are as follows.
0-1    Lacing flags
2       Time flag
3-6    Unused
7       Gap flag

Definitions of the Bitflags are as follows:

Lacing flags layout is identical to the original Block layout.
a.. 00 : no lacing
a.. 01 : Xiph lacing
a.. 11 : EBML lacing
a.. 10 : fixed-size lacing

The Time flag indicates what method is used for calculating the timecode.
0    Timecode calculation is identical to the original Block design.  It is
calculated by adding the Time to the Cluster's Timecode and then multiplying the
result by the TimecodeScale.
1    Timecode calculation is based on a new element in the Cluster.  The Cluster
Sample*.  The Time is added to the Cluster's Sample to obtain the first sample
number in the Block2.  That number is then multiplied by the samplerate to
obtain a timecode.

The Gap flag is set when the Track is empty after this Block ends (data should
not be rendered from this timecode, cache can be flushed). This is identical in
use to the original Block design.  The reason that this is at bit 7 is that it
should rarely be used, and will only take one extra byte when it is.  Four more
flags may be added that would be more commonly used, without needing to expand
the size of the Bit flags header.


1. By introducing a completely new Block structure with a new ID, we can be sure
that current parsers won't b0rk on the data.  It is better for the parser to
simply skip the data than to break while trying to read data.

2. Any size Cluster can be made with the variable length timecodes. So,
efficiency can be determined by this.

3. Seeking can be done by samples instead of timecodes.

4. Any number of bit flags can be added, changing the structure of the Block2 to
accommodate new features.

Other possibilities:

1. Two of the bit flags could be used to indicate forward or backward
references(as originally planned).  This would remove accuracy in the case of a
damaged file, but would decrease overhead by no longer needing to use the
ReferenceBlock element in most cases.  3 bytes for P frames and 6 bytes for B
frames would be saved if using this.

Please correct any poor spec grammar while commenting on this.


* The Cluster's Sample element would contain a number of samples to use as an
offset for the Block2 with the Time bit flag set.

More information about the Matroska-devel mailing list