Internet-Draft | Matroska Format | October 2020 |
Lhomme, et al. | Expires 22 April 2021 | [Page] |
This document defines the Matroska audiovisual container, including definitions of its structural elements, as well as its terminology, vocabulary, and application.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Matroska aims to become THE standard of multimedia container formats. It was derived from a project called [MCF], but differentiates from it significantly because it is based on EBML (Extensible Binary Meta Language) [RFC8794], a binary derivative of XML. EBML enables significant advantages in terms of future format extensibility, without breaking file support in old parsers.¶
First, it is essential to clarify exactly "What an Audio/Video container is", to avoid any misunderstandings:¶
Matroska is designed with the future in mind. It incorporates features like:¶
Matroska is an open standards project. This means for personal use it is absolutely free to use and that the technical specifications describing the bitstream are open to everybody, even to companies that would like to support it in their products.¶
This document is a work-in-progress specification defining the Matroska file format as part of the IETF Cellar working group. But since it's quite complete it is used as a reference for the development of libmatroska. A legacy version of the specification can be found here (PDF doc by Alexander Noé -- outdated).¶
For a simplified diagram of the layout of a Matroska file, see the Diagram page.¶
The table found below is now generated from the "source" of the Matroska specification. This XML file is also used to generate the semantic data used in libmatroska and libmatroska2. We encourage anyone to use and monitor its changes so your code is spec-proof and always up to date.¶
Note that versions 1, 2, and 3 have been finalized. Version 4 is currently work in progress. There MAY be further additions to v4.¶
Matroska inherits security considerations from EBML.¶
Attacks on a Matroska Reader
could include:¶
To be determined.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines specific terms in order to define the format and application of Matroska
.
Specific terms are defined below:¶
Matroska
:Matroska Reader
:Matroska
.¶
Matroska Player
:Matroska Reader
with a primary purpose of playing audiovisual files, including Matroska
documents.¶
Matroska is a Document Type of EBML (Extensible Binary Meta Language). This specification is dependent on the EBML Specification [RFC8794]. For an understanding of Matroska's EBML Schema, see in particular the sections of the EBML Specification covering EBML Element Types (Section 7), EBML Schema (Section 11.1), and EBML Structure (Section 3).¶
As an EBML Document Type, Matroska adds the following constraints to the EBML specification.¶
All top-levels elements (Segment and direct sub-elements) are coded on 4 octets -- i.e. class D elements.¶
Matroska from version 1 through 3 uses language codes that can be either the 3 letters
bibliographic ISO-639-2 form (like "fre" for french),
or such a language code followed by a dash and a country code for specialities in languages (like "fre-ca" for Canadian French).
The ISO 639-2 Language Elements
are "Language Element", "TagLanguage Element", and "ChapLanguage Element".¶
Starting in Matroska version 4, either ISO 639-2
or BCP 47 MAY be used,
although BCP 47
is RECOMMENDED. The BCP 47 Language Elements
are "LanguageIETF Element",
"TagLanguageIETF Element", and "ChapLanguageIETF Element". If a BCP 47 Language Element
and an ISO 639-2 Language Element
are used within the same Parent Element
, then the ISO 639-2 Language Element
MUST be ignored and precedence given to the BCP 47 Language Element
.¶
Country codes are the same as used for internet domains.¶
Each level can have different meanings for audio and video. The ORIGINAL_MEDIUM tag can be used to specify a string for ChapterPhysicalEquiv = 60. Here is the list of possible levels for both audio and video:¶
ChapterPhysicalEquiv | Audio | Video | Comment |
---|---|---|---|
70 | SET / PACKAGE | SET / PACKAGE | the collection of different media |
60 | CD / 12" / 10" / 7" / TAPE / MINIDISC / DAT | DVD / VHS / LASERDISC | the physical medium like a CD or a DVD |
50 | SIDE | SIDE | when the original medium (LP/DVD) has different sides |
40 | - | LAYER | another physical level on DVDs |
30 | SESSION | SESSION | as found on CDs and DVDs |
20 | TRACK | - | as found on audio CDs |
10 | INDEX | - | the first logical level of the side/medium |
Bit 0 is the most significant bit.¶
Frames using references SHOULD be stored in "coding order". That means the references first, and then the frames referencing them. A consequence is that timestamps might not be consecutive. But a frame with a past timestamp MUST reference a frame already known, otherwise it's considered bad/void.¶
Offset | Player | Description |
---|---|---|
0x00+ | MUST | Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc) (most significant bits set to increase the range). |
0x01+ | MUST | Timestamp (relative to Cluster timestamp, signed int16) |
Offset | Bit | Player | Description |
---|---|---|---|
0x03+ | 0-3 | - | Reserved, set to 0 |
0x03+ | 4 | - | Invisible, the codec SHOULD decode this frame but not display it |
0x03+ | 5-6 | MUST | Lacing |
* 00 : no lacing | |||
* 01 : Xiph lacing | |||
* 11 : EBML lacing | |||
* 10 : fixed-size lacing | |||
0x03+ | 7 | - | not used |
Lacing is a mechanism to save space when storing data. It is typically used for small blocks of data (referred to as frames in Matroska). There are 3 types of lacing:¶
For example, a user wants to store 3 frames of the same track. The first frame is 800 octets long, the second is 500 octets long and the third is 1000 octets long. As these data are small, they can be stored in a lace to save space. They will then be stored in the same block as follows:¶
A frame with a size multiple of 255 is coded with a 0 at the end of the size -- for example, 765 is coded 255;255;255;0.¶
In this case, the size is not coded as blocks of 255 bytes, but as a difference with the previous size and this size is coded as in EBML. The first size in the lace is unsigned as in EBML. The others use a range shifting to get a sign on each value:¶
Bit Representation | Value |
---|---|
1xxx xxxx | value -(26-1) to 26-1 (ie 0 to 27-2 minus 26-1, half of the range) |
01xx xxxx xxxx xxxx | value -(213-1) to 213-1 |
001x xxxx xxxx xxxx xxxx xxxx | value -(220-1) to 220-1 |
0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx | value -(227-1) to 227-1 |
0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | value -(234-1) to 234-1 |
0000 01xx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | value -(241-1) to 241-1 |
0000 001x xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | value -(248-1) to 248-1 |
In this case, only the number of frames in the lace is saved, the size of each frame is deduced from the total size of the Block. For example, for 3 frames of 800 octets each:¶
The SimpleBlock
is inspired by the Block structure; see Section 6.2.3.
The main differences are the added Keyframe flag and Discardable flag. Otherwise everything is the same.¶
Bit 0 is the most significant bit.¶
Frames using references SHOULD be stored in "coding order". That means the references first, and then the frames referencing them. A consequence is that timestamps might not be consecutive. But a frame with a past timestamp MUST reference a frame already known, otherwise it's considered bad/void.¶
Offset | Player | Description |
---|---|---|
0x00+ | MUST | Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc) (most significant bits set to increase the range). |
0x01+ | MUST | Timestamp (relative to Cluster timestamp, signed int16) |
Offset | Bit | Player | Description |
---|---|---|---|
0x03+ | 0 | - | Keyframe, set when the Block contains only keyframes |
0x03+ | 1-3 | - | Reserved, set to 0 |
0x03+ | 4 | - | Invisible, the codec SHOULD decode this frame but not display it |
0x03+ | 5-6 | MUST | Lacing |
* 00 : no lacing | |||
* 01 : Xiph lacing | |||
* 11 : EBML lacing | |||
* 10 : fixed-size lacing | |||
0x03+ | 7 | - | Discardable, the frames of the Block can be discarded during playing if needed |
When lacing bit is set.¶
Offset | Player | Description |
---|---|---|
0x00 | MUST | Number of frames in the lace-1 (uint8) |
0x01 / 0xXX | MUST* | Lace-coded size of each frame of the lace, except for the last one (multiple uint8). *This is not used with Fixed-size lacing as it is calculated automatically from (total size of lace) / (number of frames in lace). |
For (possibly) Laced Data¶
Offset | Player | Description |
---|---|---|
0x00 | MUST | Consecutive laced frames |
A Matroska file MUST be composed of at least one EBML Document
using the Matroska Document Type
.
Each EBML Document
MUST start with an EBML Header
and MUST be followed by the EBML Root Element
,
defined as Segment
in Matroska. Matroska defines several Top Level Elements
which MAY occur within the Segment
.¶
As an example, a simple Matroska file consisting of a single EBML Document
could be represented like this:¶
A more complex Matroska file consisting of an EBML Stream
(consisting of two EBML Documents
) could be represented like this:¶
The following diagram represents a simple Matroska file, comprised of an EBML Document
with an EBML Header
, a Segment Element
(the Root Element
), and all eight Matroska
Top Level Elements
. In the following diagrams of this section, horizontal spacing expresses
a parent-child relationship between Matroska Elements (e.g., the Info Element
is contained within
the Segment Element
) whereas vertical alignment represents the storage order within the file.¶
+-------------+ | EBML Header | +---------------------------+ | Segment | SeekHead | | |-------------| | | Info | | |-------------| | | Tracks | | |-------------| | | Chapters | | |-------------| | | Cluster | | |-------------| | | Cues | | |-------------| | | Attachments | | |-------------| | | Tags | +---------------------------+¶
The Matroska EBML Schema
defines eight Top Level Elements
: SeekHead
, Info
, Tracks
,
Chapters
, Cluster
, Cues
, Attachments
, and Tags
.¶
The SeekHead Element
(also known as MetaSeek
) contains an index of Top Level Elements
locations within the Segment
. Use of the SeekHead Element
is RECOMMENDED. Without a SeekHead Element
,
a Matroska parser would have to search the entire file to find all of the other Top Level Elements
.
This is due to Matroska's flexible ordering requirements; for instance, it is acceptable for
the Chapters Element
to be stored after the Cluster Elements
.¶
The Info Element
contains vital information for identifying the whole Segment
.
This includes the title for the Segment
, a randomly generated unique identifier,
and the unique identifier(s) of any linked Segment Elements
.¶
The Tracks Element
defines the technical details for each track and can store the name,
number, unique identifier, language, and type (audio, video, subtitles, etc.) of each track.
For example, the Tracks Element
MAY store information about the resolution of a video track
or sample rate of an audio track.¶
The Tracks Element
MUST identify all the data needed by the codec to decode the data of the
specified track. However, the data required is contingent on the codec used for the track.
For example, a Track Element
for uncompressed audio only requires the audio bit rate to be present.
A codec such as AC-3 would require that the CodecID Element
be present for all tracks,
as it is the primary way to identify which codec to use to decode the track.¶
The Chapters Element
lists all of the chapters. Chapters are a way to set predefined
points to jump to in video or audio.¶
Cluster Elements
contain the content for each track, e.g., video frames. A Matroska file
SHOULD contain at least one Cluster Element
. The Cluster Element
helps to break up
SimpleBlock
or BlockGroup Elements
and helps with seeking and error protection.
It is RECOMMENDED that the size of each individual Cluster Element
be limited to store
no more than 5 seconds or 5 megabytes. Every Cluster Element
MUST contain a Timestamp Element
.
This SHOULD be the Timestamp Element
used to play the first Block
in the Cluster Element
.
There SHOULD be one or more BlockGroup
or SimpleBlock Element
in each Cluster Element
.
A BlockGroup Element
MAY contain a Block
of data and any information relating directly to that Block
.¶
Each Cluster
MUST contain exactly one Timestamp Element
. The Timestamp Element
value MUST
be stored once per Cluster
. The Timestamp Element
in the Cluster
is relative to the entire Segment
.
The Timestamp Element
SHOULD be the first Element
in the Cluster
.¶
Additionally, the Block
contains an offset that, when added to the Cluster
's Timestamp Element
value,
yields the Block
's effective timestamp. Therefore, timestamp in the Block
itself is relative to
the Timestamp Element
in the Cluster
. For example, if the Timestamp Element
in the Cluster
is set to 10 seconds and a Block
in that Cluster
is supposed to be played 12 seconds into the clip,
the timestamp in the Block
would be set to 2 seconds.¶
The ReferenceBlock
in the BlockGroup
is used instead of the basic "P-frame"/"B-frame" description.
Instead of simply saying that this Block
depends on the Block
directly before, or directly afterwards,
the Timestamp
of the necessary Block
is used. Because there can be as many ReferenceBlock Elements
as necessary for a Block
, it allows for some extremely complex referencing.¶
The Cues Element
is used to seek when playing back a file by providing a temporal index
for some of the Tracks
. It is similar to the SeekHead Element
, but used for seeking to
a specific time when playing back the file. It is possible to seek without this element,
but it is much more difficult because a Matroska Reader
would have to 'hunt and peck'
through the file looking for the correct timestamp.¶
The Cues Element
SHOULD contain at least one CuePoint Element
. Each CuePoint Element
stores the position of the Cluster
that contains the BlockGroup
or SimpleBlock Element
.
The timestamp is stored in the CueTime Element
and location is stored in the CueTrackPositions Element
.¶
The Cues Element
is flexible. For instance, Cues Element
can be used to index every
single timestamp of every Block
or they can be indexed selectively. For video files,
it is RECOMMENDED to index at least the keyframes of the video track.¶
The Attachments Element
is for attaching files to a Matroska file such as pictures,
webpages, programs, or even the codec needed to play back the file.¶
The Tags Element
contains metadata that describes the Segment
and potentially
its Tracks
, Chapters
, and Attachments
. Each Track
or Chapter
that those tags
applies to has its UID listed in the Tags
. The Tags
contain all extra information about
the file: scriptwriter, singer, actors, directors, titles, edition, price, dates, genre, comments,
etc. Tags can contain their values in multiple languages. For example, a movie's "title" Tag
might contain both the original English title as well as the title it was released as in Germany.¶
In addition to the EBML Schema definition provided by the EBML Specification, Matroska adds the following additional attributes:¶
attribute name | required | definition |
---|---|---|
webm | No | A boolean to express if the Matroska Element is also supported within version 2 of the webm specification. Please consider the webm specification as the authoritative on webm . |
This specification includes an EBML Schema
, which defines the Elements and structure
of Matroska as an EBML Document Type. The EBML Schema defines every valid
Matroska element in a manner defined by the EBML specification.¶
Here the definition of each Matroska Element is provided.¶
\Segment
¶
\Segment\SeekHead
¶
\Segment\Info
¶
\Segment\Info\PrevUID
¶
\Segment\Info\PrevFilename
¶
\Segment\Info\NextUID
¶
\Segment\Info\NextFilename
¶
\Segment\Info\SegmentFamily
¶
\Segment\Info\ChapterTranslate
¶
\Segment\Info\ChapterTranslate\ChapterTranslateCodec
¶
restrictions:¶
value | label |
---|---|
0
|
Matroska Script |
1
|
DVD-menu |
\Segment\Info\ChapterTranslate\ChapterTranslateID
¶
\Segment\Cluster
¶
\Segment\Cluster\SimpleBlock
¶
\Segment\Cluster\BlockGroup
¶
\Segment\Cluster\BlockGroup\BlockAdditions
¶
\Segment\Cluster\BlockGroup\BlockAdditions\BlockMore
¶
\Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID
¶
minOccurs: see implementation notes¶
default: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
minOccurs | BlockDuration MUST be set (minOccurs=1) if the associated TrackEntry stores a DefaultDuration value. |
default | When not written and with no DefaultDuration, the value is assumed to be the difference between the timestamp |
of this Block and the timestamp of the next Block in "display" order (not coding order). |
\Segment\Cluster\BlockGroup\ReferencePriority
¶
\Segment\Cluster\BlockGroup\DiscardPadding
¶
\Segment\Cluster\BlockGroup\Slices
¶
\Segment\Cluster\BlockGroup\Slices\TimeSlice
¶
\Segment\Cluster\BlockGroup\Slices\TimeSlice\LaceNumber
¶
\Segment\Tracks
¶
\Segment\Tracks\TrackEntry
¶
\Segment\Tracks\TrackEntry\TrackType
¶
restrictions:¶
value | label |
---|---|
1
|
video |
2
|
audio |
3
|
complex |
16
|
logo |
17
|
subtitle |
18
|
buttons |
32
|
control |
33
|
metadata |
\Segment\Tracks\TrackEntry\FlagForced
¶
\Segment\Tracks\TrackEntry\DefaultDecodedFieldDuration
¶
\Segment\Tracks\TrackEntry\TrackTimestampScale
¶
\Segment\Tracks\TrackEntry\MaxBlockAdditionID
¶
\Segment\Tracks\TrackEntry\BlockAdditionMapping
¶
\Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue
¶
\Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType
¶
\Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDExtraData
¶
\Segment\Tracks\TrackEntry\Language
¶
\Segment\Tracks\TrackEntry\LanguageIETF
¶
\Segment\Tracks\TrackEntry\TrackOverlay
¶
\Segment\Tracks\TrackEntry\CodecDelay
¶
\Segment\Tracks\TrackEntry\TrackTranslate
¶
\Segment\Tracks\TrackEntry\TrackTranslate\TrackTranslateCodec
¶
restrictions:¶
value | label |
---|---|
0
|
Matroska Script |
1
|
DVD-menu |
\Segment\Tracks\TrackEntry\TrackTranslate\TrackTranslateTrackID
¶
\Segment\Tracks\TrackEntry\Video
¶
\Segment\Tracks\TrackEntry\Video\FlagInterlaced
¶
restrictions:¶
value | label |
---|---|
0
|
undetermined |
1
|
interlaced |
2
|
progressive |
\Segment\Tracks\TrackEntry\Video\FieldOrder
¶
restrictions:¶
value | label | documentation |
---|---|---|
0
|
progressive | |
1
|
tff | Top field displayed first. Top field stored first. |
2
|
undetermined | |
6
|
bff | Bottom field displayed first. Bottom field stored first. |
9
|
bff(swapped) | Top field displayed first. Fields are interleaved in storage |
with the top line of the top field stored first. | ||
14
|
tff(swapped) | Bottom field displayed first. Fields are interleaved in storage |
with the top line of the top field stored first. |
\Segment\Tracks\TrackEntry\Video\StereoMode
¶
restrictions:¶
value | label |
---|---|
0
|
mono |
1
|
side by side (left eye first) |
2
|
top - bottom (right eye is first) |
3
|
top - bottom (left eye is first) |
4
|
checkboard (right eye is first) |
5
|
checkboard (left eye is first) |
6
|
row interleaved (right eye is first) |
7
|
row interleaved (left eye is first) |
8
|
column interleaved (right eye is first) |
9
|
column interleaved (left eye is first) |
10
|
anaglyph (cyan/red) |
11
|
side by side (right eye first) |
12
|
anaglyph (green/magenta) |
13
|
both eyes laced in one Block (left eye is first) |
14
|
both eyes laced in one Block (right eye is first) |
\Segment\Tracks\TrackEntry\Video\OldStereoMode
¶
restrictions:¶
value | label |
---|---|
0
|
mono |
1
|
right eye |
2
|
left eye |
3
|
both eyes |
\Segment\Tracks\TrackEntry\Video\DisplayWidth
¶
default: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
default | If the DisplayUnit of the same TrackEntry is 0, then the default value for DisplayWidth is equal to |
PixelWidth - PixelCropLeft - PixelCropRight, else there is no default value. |
\Segment\Tracks\TrackEntry\Video\DisplayHeight
¶
default: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
default | If the DisplayUnit of the same TrackEntry is 0, then the default value for DisplayHeight is equal to |
PixelHeight - PixelCropTop - PixelCropBottom, else there is no default value. |
\Segment\Tracks\TrackEntry\Video\DisplayUnit
¶
restrictions:¶
value | label |
---|---|
0
|
pixels |
1
|
centimeters |
2
|
inches |
3
|
display aspect ratio |
4
|
unknown |
\Segment\Tracks\TrackEntry\Video\AspectRatioType
¶
restrictions:¶
value | label |
---|---|
0
|
free resizing |
1
|
keep aspect ratio |
2
|
fixed |
minOccurs: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
minOccurs | ColourSpace MUST be set (minOccurs=1) in TrackEntry, when the CodecID Element of the TrackEntry is set to "V_UNCOMPRESSED". |
\Segment\Tracks\TrackEntry\Video\Colour
¶
\Segment\Tracks\TrackEntry\Video\Colour\MatrixCoefficients
¶
restrictions:¶
value | label |
---|---|
0
|
Identity |
1
|
ITU-R BT.709 |
2
|
unspecified |
3
|
reserved |
4
|
US FCC 73.682 |
5
|
ITU-R BT.470BG |
6
|
SMPTE 170M |
7
|
SMPTE 240M |
8
|
YCoCg |
9
|
BT2020 Non-constant Luminance |
10
|
BT2020 Constant Luminance |
11
|
SMPTE ST 2085 |
12
|
Chroma-derived Non-constant Luminance |
13
|
Chroma-derived Constant Luminance |
14
|
ITU-R BT.2100-0 |
\Segment\Tracks\TrackEntry\Video\Colour\ChromaSubsamplingHorz
¶
\Segment\Tracks\TrackEntry\Video\Colour\ChromaSubsamplingVert
¶
\Segment\Tracks\TrackEntry\Video\Colour\CbSubsamplingHorz
¶
\Segment\Tracks\TrackEntry\Video\Colour\ChromaSitingHorz
¶
restrictions:¶
value | label |
---|---|
0
|
unspecified |
1
|
left collocated |
2
|
half |
\Segment\Tracks\TrackEntry\Video\Colour\ChromaSitingVert
¶
restrictions:¶
value | label |
---|---|
0
|
unspecified |
1
|
top collocated |
2
|
half |
\Segment\Tracks\TrackEntry\Video\Colour\Range
¶
restrictions:¶
value | label |
---|---|
0
|
unspecified |
1
|
broadcast range |
2
|
full range (no clipping) |
3
|
defined by MatrixCoefficients / TransferCharacteristics |
\Segment\Tracks\TrackEntry\Video\Colour\TransferCharacteristics
¶
restrictions:¶
value | label |
---|---|
0
|
reserved |
1
|
ITU-R BT.709 |
2
|
unspecified |
3
|
reserved |
4
|
Gamma 2.2 curve - BT.470M |
5
|
Gamma 2.8 curve - BT.470BG |
6
|
SMPTE 170M |
7
|
SMPTE 240M |
8
|
Linear |
9
|
Log |
10
|
Log Sqrt |
11
|
IEC 61966-2-4 |
12
|
ITU-R BT.1361 Extended Colour Gamut |
13
|
IEC 61966-2-1 |
14
|
ITU-R BT.2020 10 bit |
15
|
ITU-R BT.2020 12 bit |
16
|
ITU-R BT.2100 Perceptual Quantization |
17
|
SMPTE ST 428-1 |
18
|
ARIB STD-B67 (HLG) |
\Segment\Tracks\TrackEntry\Video\Colour\Primaries
¶
restrictions:¶
value | label |
---|---|
0
|
reserved |
1
|
ITU-R BT.709 |
2
|
unspecified |
3
|
reserved |
4
|
ITU-R BT.470M |
5
|
ITU-R BT.470BG - BT.601 625 |
6
|
ITU-R BT.601 525 - SMPTE 170M |
7
|
SMPTE 240M |
8
|
FILM |
9
|
ITU-R BT.2020 |
10
|
SMPTE ST 428-1 |
11
|
SMPTE RP 432-2 |
12
|
SMPTE EG 432-2 |
22
|
EBU Tech. 3213-E - JEDEC P22 phosphors |
\Segment\Tracks\TrackEntry\Video\Projection
¶
\Segment\Tracks\TrackEntry\Video\Projection\ProjectionType
¶
restrictions:¶
value | label |
---|---|
0
|
rectangular |
1
|
equirectangular |
2
|
cubemap |
3
|
mesh |
\Segment\Tracks\TrackEntry\Video\Projection\ProjectionPrivate
¶
ProjectionType
equals 0 (Rectangular),
then this element must not be present.¶
ProjectionType
equals 1 (Equirectangular), then this element must be present and contain the same binary data that would be stored inside
an ISOBMFF Equirectangular Projection Box ('equi').¶
ProjectionType
equals 2 (Cubemap), then this element must be present and contain the same binary data that would be stored
inside an ISOBMFF Cubemap Projection Box ('cbmp').¶
ProjectionType
equals 3 (Mesh), then this element must be present and contain the same binary data that would be stored inside
an ISOBMFF Mesh Projection Box ('mshp').¶
\Segment\Tracks\TrackEntry\Video\Projection\ProjectionPoseYaw
¶
Value represents a clockwise rotation, in degrees, around the up vector. This rotation must be applied
before any ProjectionPosePitch
or ProjectionPoseRoll
rotations.
The value of this field should be in the -180 to 180 degree range.¶
\Segment\Tracks\TrackEntry\Video\Projection\ProjectionPosePitch
¶
Value represents a counter-clockwise rotation, in degrees, around the right vector. This rotation must be applied
after the ProjectionPoseYaw
rotation and before the ProjectionPoseRoll
rotation.
The value of this field should be in the -90 to 90 degree range.¶
\Segment\Tracks\TrackEntry\Video\Projection\ProjectionPoseRoll
¶
Value represents a counter-clockwise rotation, in degrees, around the forward vector. This rotation must be applied
after the ProjectionPoseYaw
and ProjectionPosePitch
rotations.
The value of this field should be in the -180 to 180 degree range.¶
\Segment\Tracks\TrackEntry\Audio
¶
\Segment\Tracks\TrackEntry\Audio\OutputSamplingFrequency
¶
default: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
default | The default value for OutputSamplingFrequency of the same TrackEntry is equal to the SamplingFrequency. |
\Segment\Tracks\TrackEntry\TrackOperation
¶
\Segment\Tracks\TrackEntry\TrackOperation\TrackCombinePlanes
¶
\Segment\Tracks\TrackEntry\TrackOperation\TrackCombinePlanes\TrackPlane\TrackPlaneType
¶
restrictions:¶
value | label |
---|---|
0
|
left eye |
1
|
right eye |
2
|
background |
\Segment\Tracks\TrackEntry\ContentEncodings
¶
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding
¶
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncodingOrder
¶
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncodingScope
¶
restrictions:¶
value | label |
---|---|
1
|
All frame contents, excluding lacing data |
2
|
The track's private data |
4
|
The next ContentEncoding (next ContentEncodingOrder . Either the data inside ContentCompression and/or ContentEncryption ) |
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncodingType
¶
restrictions:¶
value | label |
---|---|
0
|
Compression |
1
|
Encryption |
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentCompression
¶
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentCompression\ContentCompAlgo
¶
restrictions:¶
value | label |
---|---|
0
|
zlib |
1
|
bzlib |
2
|
lzo1x |
3
|
Header Stripping |
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentCompression\ContentCompSettings
¶
ContentCompAlgo
=3),
the bytes that were removed from the beginning of each frames of the track.¶
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncryption
¶
ContentEncodingType
is 1 (encryption) and MUST be ignored otherwise.¶
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncryption\ContentEncAlgo
¶
restrictions:¶
value | label |
---|---|
0
|
Not encrypted |
1
|
DES - FIPS 46-3 |
2
|
Triple DES - RFC 1851 |
3
|
Twofish |
4
|
Blowfish |
5
|
AES - FIPS 187 |
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncryption\ContentEncAESSettings\AESSettingsCipherMode
¶
restrictions:¶
value | label |
---|---|
1
|
AES-CTR / Counter, NIST SP 800-38A |
2
|
AES-CBC / Cipher Block Chaining, NIST SP 800-38A |
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncryption\ContentSigAlgo
¶
restrictions:¶
value | label |
---|---|
0
|
Not signed |
1
|
RSA |
\Segment\Tracks\TrackEntry\ContentEncodings\ContentEncoding\ContentEncryption\ContentSigHashAlgo
¶
restrictions:¶
value | label |
---|---|
0
|
Not signed |
1
|
SHA1-160 |
2
|
MD5 |
minOccurs: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
minOccurs | This Element SHOULD be set when the Segment is not transmitted as a live stream (see #livestreaming). |
\Segment\Cues\CuePoint
¶
\Segment\Cues\CuePoint\CueTrackPositions
¶
\Segment\Cues\CuePoint\CueTrackPositions\CueRelativePosition
¶
\Segment\Cues\CuePoint\CueTrackPositions\CueDuration
¶
\Segment\Cues\CuePoint\CueTrackPositions\CueReference
¶
\Segment\Cues\CuePoint\CueTrackPositions\CueReference\CueRefCodecState
¶
\Segment\Attachments
¶
\Segment\Chapters
¶
\Segment\Chapters\EditionEntry
¶
\Segment\Chapters\EditionEntry\+ChapterAtom
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterFlagEnabled
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterSegmentUID
¶
minOccurs: see implementation notes¶
implementation notes:¶
attribute | note |
---|---|
minOccurs | ChapterSegmentUID MUST be set (minOccurs=1) if ChapterSegmentEditionUID is used. |
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterSegmentEditionUID
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterTrack
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterTrack\ChapterTrackUID
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterDisplay
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterDisplay\ChapLanguage
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterDisplay\ChapLanguageIETF
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapterDisplay\ChapCountry
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapProcess
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapProcess\ChapProcessCodecID
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapProcess\ChapProcessPrivate
¶
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapProcess\ChapProcessCommand\ChapProcessTime
¶
restrictions:¶
value | label |
---|---|
0
|
during the whole chapter |
1
|
before starting playback |
2
|
after playback of the chapter |
\Segment\Chapters\EditionEntry\+ChapterAtom\ChapProcess\ChapProcessCommand\ChapProcessData
¶
Except for the EBML Header
and the CRC-32 Element
, the EBML specification does not
require any particular storage order for Elements
. The Matroska specification however
defines mandates and recommendations for ordering certain Elements
in order to facilitate
better playback, seeking, and editing efficiency. This section describes and offers
rationale for ordering requirements and recommendations for Matroska.¶
The Info Element
is the only REQUIRED Top-Level Element
in a Matroska file.
To be playable, Matroska MUST also contain at least one Tracks Element
and Cluster Element
.
The first Info Element
and the first Tracks Element
MUST either be stored before the first
Cluster Element
or both SHALL be referenced by a SeekHead Element
occurring before the first Cluster Element
.¶
It is possible to edit a Matroska file after it has been created. For example, chapters,
tags, or attachments can be added. When new Top-Level Elements
are added to a Matroska file,
the SeekHead
Element(s) MUST be updated so that the SeekHead
Element(s) itemize
the identity and position of all Top-Level Elements
. Editing, removing, or adding
Elements
to a Matroska file often requires that some existing Elements
be voided
or extended; therefore, it is RECOMMENDED to use Void Elements
as padding in
between Top-Level Elements
.¶
As noted by the EBML specification, if a CRC-32 Element
is used, then the CRC-32 Element
MUST be the first ordered Element
within its Parent Element
. The Matroska specification
recommends that CRC-32 Elements
SHOULD NOT be used as an immediate Child Element
of the Segment Element
; however all Top-Level Elements
of an EBML Document
SHOULD include a CRC-32 Element
as a Child Element
.¶
If used, the first SeekHead Element
SHOULD be the first non-CRC-32 Child Element
of the Segment Element
. If a second SeekHead Element
is used, then the first
SeekHead Element
MUST reference the identity and position of the second SeekHead
.
Additionally, the second SeekHead Element
MUST only reference Cluster
Elements
and not any other Top-Level Element
already contained within the first SeekHead Element
.
The second SeekHead Element
MAY be stored in any order relative to the other Top-Level Elements
.
Whether one or two SeekHead Element(s)
are used, the SeekHead Element(s)
MUST
collectively reference the identity and position of all Top-Level Elements
except
for the first SeekHead Element
.¶
It is RECOMMENDED that the first SeekHead Element
be followed by a Void Element
to
allow for the SeekHead Element
to be expanded to cover new Top-Level Elements
that could be added to the Matroska file, such as Tags
, Chapters
, and Attachments Elements
.¶
The Cues Element
is RECOMMENDED to optimize seeking access in Matroska. It is
programmatically simpler to add the Cues Element
after all Cluster Elements
have been written because this does not require a prediction of how much space to
reserve before writing the Cluster Elements
. However, storing the Cues Element
before the Cluster Elements
can provide some seeking advantages. If the Cues Element
is present, then it SHOULD either be stored before the first Cluster Element
or be referenced by a SeekHead Element
.¶
The first Info Element
SHOULD occur before the first Tracks Element
and first
Cluster Element
except when referenced by a SeekHead Element
.¶
The Chapters Element
SHOULD be placed before the Cluster Element(s)
. The
Chapters Element
can be used during playback even if the user does not need to seek.
It immediately gives the user information about what section is being read and what
other sections are available. In the case of Ordered Chapters it is RECOMMENDED to evaluate
the logical linking even before playing. The Chapters Element
SHOULD be placed before
the first Tracks Element
and after the first Info Element
.¶
The Attachments Element
is not intended to be used by default when playing the file,
but could contain information relevant to the content, such as cover art or fonts.
Cover art is useful even before the file is played and fonts could be needed before playback
starts for initialization of subtitles. The Attachments Element
MAY be placed before
the first Cluster Element
; however if the Attachments Element
is likely to be edited,
then it SHOULD be placed after the last Cluster Element
.¶
The Timestamp Element
MUST occur as in storage order before any SimpleBlock
,
BlockGroup
, or EncryptedBlock
, within the Cluster Element
.¶
Two Chapter Flags
are defined to describe the behavior of the ChapterAtom Element
:
ChapterFlagHidden
and ChapterFlagEnabled
.¶
If a ChapterAtom Element
is the Child Element
of another ChapterAtom Element
with a Chapter Flag
set to true
, then the Child ChapterAtom Element
MUST be
interpreted as having its same Chapter Flag
set to true
. If a ChapterAtom Element
is the Child Element
of another ChapterAtom Element
with a Chapter Flag
set to false
,
or if the ChapterAtom Element
does not have a ChapterAtom Element
as its Parent Element
,
then it MUST be interpreted according to its own Chapter Flag
.¶
As an example, consider a Parent ChapterAtom Element
that has its ChapterFlagHidden
set to true
and also contains two child ChapterAtoms
, the first with ChapterFlagHidden
set to true
and the second with ChapterFlagHidden
either set to false
or not present
at all (in which case the default value of the Element applies, which is false
).
Since the parent ChapterAtom
has its ChapterFlagHidden
set to true
, all of its
children ChapterAtoms
MUST also be interpreted as if their ChapterFlagHidden
is also
set to true
. However, if a Control Track
toggles the parent's ChapterFlagHidden
flag to false
, then only the parent ChapterAtom
and its second child ChapterAtom
MUST be interpreted as if ChapterFlagHidden
is set to false
. The first child
ChapterAtom
, which has the ChapterFlagHidden
flag set to true
, retains its value
until its value is toggled to false
by a Control Track
.¶
Three Edition Flags
are defined to describe the behavior of the EditionEntry Element
:
EditionFlagHidden
, EditionFlagDefault
, and EditionFlagOrdered
.¶
It is RECOMMENDED that no more than one Edition
have an EditionFlagDefault Flag
set to true
. The first Edition
with both the EditionFlagDefault Flag
set to true
and the EditionFlagHidden Flag
set to false
is the Default Edition. When all
EditionFlagDefault Flags
are set to false
, then the first Edition
with the
EditionFlagHidden Flag
set to false
is the Default Edition. The Default Edition
is the edition that should be used for playback by default.¶
The EditionFlagOrdered Flag
is a significant feature as it enables an Edition
of Ordered Chapters
which defines and arranges a virtual timeline rather than simply
labeling points within the timeline. For example, with Editions
of Ordered Chapters
a single Matroska file
can present multiple edits of a film without duplicating content.
Alternatively, if a videotape is digitized in full, one Ordered Edition
could present
the full content (including colorbars, countdown, slate, a feature presentation, and
black frames), while another Edition
of Ordered Chapters
can use Chapters
that only
mark the intended presentation with the colorbars and other ancillary visual information
excluded. If an Edition
of Ordered Chapters
is enabled, then the Matroska Player
MUST
play those Chapters in their stored order from the timestamp marked in the
ChapterTimeStart Element
to the timestamp marked in to ChapterTimeEnd Element
.¶
If the EditionFlagOrdered Flag
is set to false
, Simple Chapters
are used and
only the ChapterTimeStart
of a Chapter
is used as chapter mark to jump to the
predefined point in the timeline. With Simple Chapters
, a Matroska Player
MUST
ignore certain Chapter Elements
. All these elements are now informational only.¶
The following list shows the different usage of Chapter Elements
between an ordered
and non-ordered Edition
.¶
Chapter elements / ordered Edition | False | True |
---|---|---|
ChapterUID | X | X |
ChapterStringUID | X | X |
ChapterTimeStart | X | X |
ChapterTimeEnd | - | X |
ChapterFlagHidden | X | X |
ChapterFlagEnabled | X | X |
ChapterSegmentUID | - | X |
ChapterSegmentEditionUID | - | X |
ChapterPhysicalEquiv | X | X |
ChapterTrack | - | X |
ChapterDisplay | X | X |
ChapProcess | - | X |
Furthermore there are other EBML Elements
which could be used if the
EditionFlagOrdered Flag
is set to true
.¶
Other elements / ordered Edition | False | True |
---|---|---|
Info/SegmentFamily | - | X |
Info/ChapterTranslate | - | X |
Track/TrackTranslate | - | X |
These other Elements
belong to the Matroska DVD menu system and are only used
when the ChapProcessCodecID Element
is set to 1.¶
Ordered-Chapters
supersedes the Hard Linking
.¶
Ordered Chapters
are REQUIRED and a
Chapter CODEC
MUST interpret the ChapProcess
of all chapters.¶
Ordered Chapters
are used in a normal way and can be combined
with the ChapterSegmentUID
element which establishes a link to another Segment.¶
See Section 25 on the Linked Segments for more information
about Hard Linking
, Soft Linking
, and Medium Linking
.¶
The ChapterSegmentUID
is a binary value and the base element to set up a
Linked Chapter
in 2 variations: the Linked-Duration linking and the Linked-Edition
linking. For both variations, the following 3 conditions MUST be met:¶
EditionFlagOrdered Flag
MUST be true.¶
ChapterSegmentUID
MUST NOT be the SegmentUID
of its own Segment
.¶
Two more conditions MUST be met:¶
ChapterTimeStart
and ChapterTimeEnd
timestamps MUST be in the range of the
linked Segment duration.¶
ChapterSegmentEditionUID
MUST be not set.¶
A Matroska Player
MUST play the content of the linked Segment from the
ChapterTimeStart
until ChapterTimeEnd
timestamp.¶
When the ChapterSegmentEditionUID
is set to a valid EditionUID
from the linked
Segment. A Matroska Player
MUST play these linked Edition
.¶
In this example a movie is split in different chapters. It could also just be an audio file (album) on which each track corresponds to a chapter.¶
This would translate in the following matroska form :¶
<Chapters> <EditionEntry> <EditionUID>16603393396715046047</EditionUID> <ChapterAtom> <ChapterUID>1193046</ChapterUID> <ChapterTimeStart>0</ChapterTimeStart> <ChapterTimeEnd>5000000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Intro</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>2311527</ChapterUID> <ChapterTimeStart>5000000000</ChapterTimeStart> <ChapterTimeEnd>25000000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Before the crime</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterDisplay> <ChapString>Avant le crime</ChapString> <ChapLanguage>fra</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>3430008</ChapterUID> <ChapterTimeStart>25000000000</ChapterTimeStart> <ChapterTimeEnd>27500000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>The crime</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterDisplay> <ChapString>Le crime</ChapString> <ChapLanguage>fra</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>4548489</ChapterUID> <ChapterTimeStart>27500000000</ChapterTimeStart> <ChapterTimeEnd>38000000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>After the crime</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterDisplay> <ChapString>Après le crime</ChapString> <ChapLanguage>fra</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>5666960</ChapterUID> <ChapterTimeStart>38000000000</ChapterTimeStart> <ChapterTimeEnd>43000000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Credits</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterDisplay> <ChapString>Générique</ChapString> <ChapLanguage>fra</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <EditionFlagDefault>0</EditionFlagDefault> <EditionFlagHidden>0</EditionFlagHidden> </EditionEntry> </Chapters>¶
In this example an (existing) album is split into different chapters, and one of them contain another splitting.¶
00:00 - 12:28 : Baby Wants To Bleep/Rock¶
<Chapters> <EditionEntry> <EditionUID>1281690858003401414</EditionUID> <ChapterAtom> <ChapterUID>1</ChapterUID> <ChapterTimeStart>0</ChapterTimeStart> <ChapterTimeEnd>748000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to Bleep/Rock</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterAtom> <ChapterUID>2</ChapterUID> <ChapterTimeStart>0</ChapterTimeStart> <ChapterTimeEnd>278000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to bleep (pt.1)</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>3</ChapterUID> <ChapterTimeStart>278000000</ChapterTimeStart> <ChapterTimeEnd>432000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to rock</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>4</ChapterUID> <ChapterTimeStart>432000000</ChapterTimeStart> <ChapterTimeEnd>633000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to bleep (pt.2)</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>5</ChapterUID> <ChapterTimeStart>633000000</ChapterTimeStart> <ChapterTimeEnd>748000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to bleep (pt.3)</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>6</ChapterUID> <ChapterTimeStart>750000000</ChapterTimeStart> <ChapterTimeEnd>1178500000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Bleeper_O+2</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>7</ChapterUID> <ChapterTimeStart>1180500000</ChapterTimeStart> <ChapterTimeEnd>1340000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to bleep (pt.4)</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>8</ChapterUID> <ChapterTimeStart>1342000000</ChapterTimeStart> <ChapterTimeEnd>1518000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Bleep to bleep</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>9</ChapterUID> <ChapterTimeStart>1520000000</ChapterTimeStart> <ChapterTimeEnd>2015000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Baby wants to bleep (k)</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <ChapterAtom> <ChapterUID>10</ChapterUID> <ChapterTimeStart>2017000000</ChapterTimeStart> <ChapterTimeEnd>2668000000</ChapterTimeEnd> <ChapterDisplay> <ChapString>Bleeper</ChapString> <ChapLanguage>eng</ChapLanguage> </ChapterDisplay> <ChapterFlagHidden>0</ChapterFlagHidden> <ChapterFlagEnabled>1</ChapterFlagEnabled> </ChapterAtom> <EditionFlagDefault>0</EditionFlagDefault> <EditionFlagHidden>0</EditionFlagHidden> </EditionEntry> </Chapters>¶
Matroska supports storage of related files and data in the Attachments Element
(a Top-Level Element
). Attachment Elements
can be used to store related cover art,
font files, transcripts, reports, error recovery files, picture, or text-based annotations,
copies of specifications, or other ancillary files related to the Segment
.¶
Matroska Readers
MUST NOT execute files stored as Attachment Elements
.¶
This section defines a set of guidelines for the storage of cover art in Matroska files.
A Matroska Reader
MAY use embedded cover art to display a representational
still-image depiction of the multimedia contents of the Matroska file.¶
Only JPEG and PNG image formats SHOULD be used for cover art pictures.¶
There can be two different covers for a movie/album: a portrait style (e.g., a DVD case) and a landscape style (e.g., a wide banner ad).¶
There can be two versions of the same cover, the normal cover
and the small cover
.
The dimension of the normal cover
SHOULD be 600 pixels on the smallest side -- for example,
960x600 for landscape, 600x800 for portrait, or 600x600 for square. The dimension of
the small cover
SHOULD be 120 pixels on the smallest side -- for example, 192x120 or 120x160.¶
Versions of cover art can be differentiated by the filename, which is stored in the
FileName Element
. The default filename of the normal cover
in square or portrait mode
is cover.(jpg|png)
. When stored, the normal cover
SHOULD be the first Attachment in
storage order. The small cover
SHOULD be prefixed with "small_", such as
small_cover.(jpg|png)
. The landscape variant SHOULD be suffixed with "_land",
such as cover_land.(jpg|png)
. The filenames are case sensitive.¶
The following table provides examples of file names for cover art in Attachments.¶
FileName | Image Orientation | Pixel Length of Smallest Side |
---|---|---|
cover.jpg | Portrait or square | 600 |
small_cover.png | Portrait or square | 120 |
cover_land.png | Landscape | 600 |
smallcoverland.jpg | Landscape | 120 |
The Cues Element
provides an index of certain Cluster Elements
to allow for optimized
seeking to absolute timestamps within the Segment
. The Cues Element
contains one or
many CuePoint Elements
which each MUST reference an absolute timestamp (via the
CueTime Element
), a Track
(via the CueTrack Element
), and a Segment Position
(via the CueClusterPosition Element
). Additional non-mandated Elements are part of
the CuePoint Element
such as CueDuration
, CueRelativePosition
, CueCodecState
and others which provide any Matroska Reader
with additional information to use in
the optimization of seeking performance.¶
The following recommendations are provided to optimize Matroska performance.¶
Cues Element
.¶
CuePoint Element
.¶
Cues
unless
it references a Cluster Element
which contains a CodecState Element
but no keyframes.¶
CuePoint Element
with a CueDuration Element
.¶
CuePoint Elements
if a video track
is present. When included the CuePoint Elements
SHOULD reference audio keyframes
at most once every 500 milliseconds.¶
SimpleBlock
, or first
BlockGroup
within its Cluster Element
, then the CueRelativePosition Element
SHOULD be written to reference where in the Cluster
the reference frame is stored.¶
CuePoint Element
references Cluster Element
that includes a CodecState Element
,
then that CuePoint Element
MUST use a CueCodecState Element
.¶
CuePoint Elements
SHOULD be numerically sorted in storage order by the value of the CueTime Element
.¶
In Matroska, there are two kinds of streaming: file access and livestreaming.¶
File access can simply be reading a file located on your computer, but also includes
accessing a file from an HTTP (web) server or CIFS (Windows share) server. These protocols
are usually safe from reading errors and seeking in the stream is possible. However,
when a file is stored far away or on a slow server, seeking can be an expensive operation
and SHOULD be avoided. The following guidelines, when followed, help reduce the number
of seeking operations for regular playback and also have the playback start quickly without
a lot of data needed to read first (like a Cues Element
, Attachment Element
or SeekHead Element
).¶
Matroska, having a small overhead, is well suited for storing music/videos on file servers without a big impact on the bandwidth used. Matroska does not require the index to be loaded before playing, which allows playback to start very quickly. The index can be loaded only when seeking is requested the first time.¶
Livestreaming is the equivalent of television broadcasting on the internet. There are 2 families of servers for livestreaming: RTP/RTSP and HTTP. Matroska is not meant to be used over RTP. RTP already has timing and channel mechanisms that would be wasted if doubled in Matroska. Additionally, having the same information at the RTP and Matroska level would be a source of confusion if they do not match. Livestreaming of Matroska over HTTP (or any other plain protocol based on TCP) is possible.¶
A live Matroska stream is different from a file because it usually has no known end
(only ending when the client disconnects). For this, all bits of the "size" portion
of the Segment Element
MUST be set to 1. Another option is to concatenate Segment Elements
with known sizes, one after the other. This solution allows a change of codec/resolution
between each segment. For example, this allows for a switch between 4:3 and 16:9 in a television program.¶
When Segment Elements
are continuous, certain Elements
, like MetaSeek
, Cues
,
Chapters
, and Attachments
, MUST NOT be used.¶
It is possible for a Matroska Player
to detect that a stream is not seekable.
If the stream has neither a MetaSeek
list or a Cues
list at the beginning of the stream,
it SHOULD be considered non-seekable. Even though it is possible to seek blindly forward
in the stream, it is NOT RECOMMENDED.¶
In the context of live radio or web TV, it is possible to "tag" the content while it is
playing. The Tags Element
can be placed between Clusters
each time it is necessary.
In that case, the new Tags Element
MUST reset the previously encountered Tags Elements
and use the new values instead.¶
Matroska is based upon the principle that a reading application does not have to support 100% of the specifications in order to be able to play the file. A Matroska file therefore contains version indicators that tell a reading application what to expect.¶
It is possible and valid to have the version fields indicate that the file contains
Matroska Elements
from a higher specification version number while signaling that a
reading application MUST only support a lower version number properly in order to play
it back (possibly with a reduced feature set). For example, a reading application
supporting at least Matroska version V
reading a file whose DocTypeReadVersion
field is equal to or lower than V
MUST skip Matroska/EBML Elements
it encounters
but does not know about if that unknown element fits into the size constraints set
by the current Parent Element
.¶
The default value of an Element
is assumed when not present in the data stream.
It is assumed only in the scope of its Parent Element
. For example, the Language Element
is in the scope of the Track Element
. If the Parent Element
is not present or assumed,
then the Child Element
cannot be assumed.¶
The DefaultDecodedFieldDuration Element
can signal to the displaying application how
often fields of a video sequence will be available for displaying. It can be used for both
interlaced and progressive content. If the video sequence is signaled as interlaced,
then the period between two successive fields at the output of the decoding process
equals DefaultDecodedFieldDuration
.¶
For video sequences signaled as progressive, it is twice the value of DefaultDecodedFieldDuration
.¶
These values are valid at the end of the decoding process before post-processing (such as deinterlacing or inverse telecine) is applied.¶
Examples:¶
Encryption in Matroska is designed in a very generic style to allow people to implement whatever form of encryption is best for them. It is possible to use the encryption framework in Matroska as a type of DRM (Digital Rights Management).¶
Because encryption occurs within the Block Element
, it is possible to manipulate
encrypted streams without decrypting them. The streams could potentially be copied,
deleted, cut, appended, or any number of other possible editing techniques without
decryption. The data can be used without having to expose it or go through the decrypting process.¶
Encryption can also be layered within Matroska. This means that two completely different types of encryption can be used, requiring two separate keys to be able to decrypt a stream.¶
Encryption information is stored in the ContentEncodings Element
under the ContentEncryption Element
.¶
The PixelCrop Elements
(PixelCropTop
, PixelCropBottom
, PixelCropRight
, and PixelCropLeft
)
indicate when, and by how much, encoded videos frames SHOULD be cropped for display.
These Elements allow edges of the frame that are not intended for display, such as the
sprockets of a full-frame film scan or the VANC area of a digitized analog videotape,
to be stored but hidden. PixelCropTop
and PixelCropBottom
store an integer of how many
rows of pixels SHOULD be cropped from the top and bottom of the image (respectively).
PixelCropLeft
and PixelCropRight
store an integer of how many columns of pixels
SHOULD be cropped from the left and right of the image (respectively). For example,
a pillar-boxed video that stores a 1440x1080 visual image within the center of a padded
1920x1080 encoded image MAY set both PixelCropLeft
and PixelCropRight
to "240",
so that a Matroska Player
SHOULD crop off 240 columns of pixels from the left and
right of the encoded image to present the image with the pillar-boxes hidden.¶
The ProjectionPoseRoll Element (see Section 10.4.1.31.20.5) can be used to indicate that the image from the associated video track SHOULD be rotated for presentation. For instance, the following representation of the Projection Element Section 10.4.1.31.20) and the ProjectionPoseRoll Element represents a video track where the image SHOULD be presentation with a 90 degree counter-clockwise rotation.¶
<Projection> <ProjectionPoseRoll>90</ProjectionPoseRoll> </Projection>¶
The EBML Header
of each Matroska document informs the reading application on what
version of Matroska to expect. The Elements
within EBML Header
with jurisdiction
over this information are DocTypeVersion
and DocTypeReadVersion
.¶
DocTypeVersion
MUST be equal to or greater than the highest Matroska version number of
any Element
present in the Matroska file. For example, a file using the SimpleBlock Element
MUST have a DocTypeVersion
equal to or greater than 2. A file containing CueRelativePosition
Elements MUST have a DocTypeVersion
equal to or greater than 4.¶
The DocTypeReadVersion
MUST contain the minimum version number that a reading application
can minimally support in order to play the file back -- optionally with a reduced feature
set. For example, if a file contains only Elements
of version 2 or lower except for
CueRelativePosition
(which is a version 4 Matroska Element
), then DocTypeReadVersion
SHOULD still be set to 2 and not 4 because evaluating CueRelativePosition
is not
necessary for standard playback -- it makes seeking more precise if used.¶
DocTypeVersion
MUST always be equal to or greater than DocTypeReadVersion
.¶
A reading application supporting Matroska version V
MUST NOT refuse to read an
application with DocReadTypeVersion
equal to or lower than V
even if DocTypeVersion
is greater than V
. See also the note about Unknown Elements in Section 17.¶
There is no IETF endorsed MIME type for Matroska files. These definitions can be used:¶
The Segment Position
of an Element
refers to the position of the first octet of the
Element ID
of that Element
, measured in octets, from the beginning of the Element Data
section of the containing Segment Element
. In other words, the Segment Position
of an
Element
is the distance in octets from the beginning of its containing Segment Element
minus the size of the Element ID
and Element Data Size
of that Segment Element
.
The Segment Position
of the first Child Element
of the Segment Element
is 0.
An Element
which is not stored within a Segment Element
, such as the Elements
of
the EBML Header
, do not have a Segment Position
.¶
Elements
that are defined to store a Segment Position
MAY define reserved values to
indicate a special meaning.¶
This table presents an example of Segment Position
by showing a hexadecimal representation
of a very small Matroska file with labels to show the offsets in octets. The file contains
a Segment Element
with an Element ID
of "0x18538067" and a MuxingApp Element
with an Element ID
of "0x4D80".¶
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 |1A|45|DF|A3|8B|42|82|88|6D|61|74|72|6F|73|6B|61|18|53|80|67| 20 |93|15|49|A9|66|8E|4D|80|84|69|65|74|66|57|41|84|69|65|74|66|¶
In the above example, the Element ID
of the Segment Element
is stored at offset 16,
the Element Data Size
of the Segment Element
is stored at offset 20, and the
Element Data
of the Segment Element
is stored at offset 21.¶
The MuxingApp Element
is stored at offset 26. Since the Segment Position
of
an Element
is calculated by subtracting the position of the Element Data
of
the containing Segment Element
from the position of that Element
, the Segment Position
of MuxingApp Element
in the above example is '26 - 21' or '5'.¶
Matroska provides several methods to link two or many Segment Elements
together to create
a Linked Segment
. A Linked Segment
is a set of multiple Segments
related together into
a single presentation by using Hard Linking, Medium Linking, or Soft Linking. All Segments
within a Linked Segment
MUST utilize the same track numbers and timescale. All Segments
within a Linked Segment
MUST be stored within the same directory. All Segments
within a Linked Segment
MUST store a SegmentUID
.¶
Hard Linking (also called splitting) is the process of creating a Linked Segment
by relating multiple Segment Elements
using the NextUID
and PrevUID
Elements.
Within a Linked Segment
, the timestamps of each Segment
MUST follow consecutively
in linking order.
With Hard Linking, the chapters of any Segment
within the Linked Segment
MUST
only reference the current Segment
. With Hard Linking, the NextUID
and PrevUID
MUST
reference the respective SegmentUID
values of the next and previous Segments
.
The first Segment
of a Linked Segment
SHOULD have a NextUID Element
and MUST NOT
have a PrevUID Element
.
The last Segment
of a Linked Segment
SHOULD have a PrevUID Element
and MUST NOT
have a NextUID Element
.
The middle Segments
of a Linked Segment
SHOULD have both a NextUID Element
and a PrevUID Element
.¶
In a chain of Linked Segments
the NextUID
always takes precedence over the PrevUID
.
So if SegmentA has a NextUID to SegmentB and SegmentB has a PrevUID to SegmentC,
the link to use is SegmentA to SegmentB.
If SegmentB has a PrevUID to SegmentA but SegmentA has no NextUID, then the Matroska Player
MAY consider these two Segments linked as SegmentA followed by SegmentB.¶
As an example, three Segments
can be Hard Linked as a Linked Segment
through
cross-referencing each other with SegmentUID
, PrevUID
, and NextUID
, as in this table.¶
file name |
SegmentUID
|
PrevUID
|
NextUID
|
---|---|---|---|
start.mkv
|
71000c23cd310998 53fbc94dd984a5dd | n/a | a77b3598941cb803 eac0fcdafe44fac9 |
middle.mkv
|
a77b3598941cb803 eac0fcdafe44fac9 | 71000c23cd310998 53fbc94dd984a5dd | 6c92285fa6d3e827 b198d120ea3ac674 |
end.mkv
|
6c92285fa6d3e827 b198d120ea3ac674 | a77b3598941cb803 eac0fcdafe44fac9 | n/a |
An other example where only the NextUID
Element is used.¶
file name |
SegmentUID
|
PrevUID
|
NextUID
|
---|---|---|---|
start.mkv
|
71000c23cd310998 53fbc94dd984a5dd | n/a | a77b3598941cb803 eac0fcdafe44fac9 |
middle.mkv
|
a77b3598941cb803 eac0fcdafe44fac9 | n/a | 6c92285fa6d3e827 b198d120ea3ac674 |
end.mkv
|
6c92285fa6d3e827 b198d120ea3ac674 | n/a | n/a |
A next example where only the PrevUID
Element is used.¶
file name |
SegmentUID
|
PrevUID
|
NextUID
|
---|---|---|---|
start.mkv
|
71000c23cd310998 53fbc94dd984a5dd | n/a | n/a |
middle.mkv
|
a77b3598941cb803 eac0fcdafe44fac9 | 71000c23cd310998 53fbc94dd984a5dd | n/a |
end.mkv
|
6c92285fa6d3e827 b198d120ea3ac674 | a77b3598941cb803 eac0fcdafe44fac9 | n/a |
In this example only the middle.mkv
is using the PrevUID
and NextUID
Elements.¶
file name |
SegmentUID
|
PrevUID
|
NextUID
|
---|---|---|---|
start.mkv
|
71000c23cd310998 53fbc94dd984a5dd | n/a | n/a |
middle.mkv
|
a77b3598941cb803 eac0fcdafe44fac9 | 71000c23cd310998 53fbc94dd984a5dd | 6c92285fa6d3e827 b198d120ea3ac674 |
end.mkv
|
6c92285fa6d3e827 b198d120ea3ac674 | n/a | n/a |
Medium Linking creates relationships between Segments
using Ordered Chapters and the
ChapterSegmentUID Element
. A Segment Edition
with Ordered Chapters MAY contain
Chapter Elements
that reference timestamp ranges from other Segments
. The Segment
referenced by the Ordered Chapter via the ChapterSegmentUID Element
SHOULD be played as
part of a Linked Segment. The timestamps of Segment content referenced by Ordered Chapters
MUST be adjusted according to the cumulative duration of the the previous Ordered Chapters.¶
As an example a file named intro.mkv
could have a SegmentUID
of "0xb16a58609fc7e60653a60c984fc11ead".
Another file called program.mkv
could use a Chapter Edition that contains two Ordered Chapters.
The first chapter references the Segment
of intro.mkv
with the use of a ChapterSegmentUID
,
ChapterSegmentEditionUID
, ChapterTimeStart
, and optionally a ChapterTimeEnd
element.
The second chapter references content within the Segment
of program.mkv
. A Matroska Player
SHOULD recognize the Linked Segment
created by the use of ChapterSegmentUID
in an enabled
Edition
and present the reference content of the two Segments
together.¶
Soft Linking is used by codec chapters. They can reference another Segment
and jump to
that Segment
. The way the Segments
are described are internal to the chapter codec and
unknown to the Matroska level. But there are Elements
within the Info Element
(such as ChapterTranslate
) that can translate a value representing a Segment
in the
chapter codec and to the current SegmentUID
. All Segments
that could be used in a Linked Segment
in this way SHOULD be marked as members of the same family via the SegmentFamily Element
,
so that the Matroska Player
can quickly switch from one to the other.¶
The "default track" flag is a hint for a Matroska Player
and SHOULD always be changeable
by the user. If the user wants to see or hear a track of a certain kind (audio, video, subtitles)
and hasn't chosen a specific track, the Matroska Player
SHOULD use the first track
of that kind whose "default track" flag is set to "1". If no such track is found,
then the first track of this kind SHOULD be chosen.¶
Only one track of a kind MAY have its "default track" flag set in a segment. If a track entry does not contain the "default track" flag element, then its default value "1" is to be used.¶
The "forced" flag tells the Matroska Player
that it MUST display/play this track
or another track of the same kind that also has its "forced" flag set. When there are multiple
"forced" tracks, the Matroska Player
SHOULD determine the track based upon the language
of the forced flag or use the default flag if no track matches the use languages.
Another track of the same kind without the "forced" flag may be use simultaneously
with the "forced" track, like DVD subtitles.¶
TrackOperation
allows combining multiple tracks to make a virtual one. It uses
two separate system to combine tracks. One to create a 3D "composition" (left/right/background planes)
and one to simplify join two tracks together to make a single track.¶
A track created with TrackOperation
is a proper track with a UID and all its flags.
However the codec ID is meaningless because each "sub" track needs to be decoded by its
own decoder before the "operation" is applied. The Cues Elements
corresponding to such
a virtual track SHOULD be the sum of the Cues Elements
for each of the tracks it's composed of (when the Cues
are defined per track).¶
In the case of TrackJoinBlocks
, the Block Elements
(from BlockGroup
and SimpleBlock
)
of all the tracks SHOULD be used as if they were defined for this new virtual Track
.
When two Block Elements
have overlapping start or end timestamps, it's up to the underlying
system to either drop some of these frames or render them the way they overlap.
This situation SHOULD be avoided when creating such tracks as you can never be sure
of the end result on different platforms.¶
Overlay tracks SHOULD be rendered in the same channel as the track its linked to. When content is found in such a track, it SHOULD be played on the rendering channel instead of the original track.¶
There are two different ways to compress 3D videos: have each eye track in a separate track and have one track have both eyes combined inside (which is more efficient, compression-wise). Matroska supports both ways.¶
For the single track variant, there is the StereoMode Element
, which defines how planes are
assembled in the track (mono or left-right combined). Odd values of StereoMode means the left
plane comes first for more convenient reading. The pixel count of the track (PixelWidth
/PixelHeight
)
is the raw amount of pixels, for example 3840x1080 for full HD side by side, and the DisplayWidth
/DisplayHeight
in pixels is the amount of pixels for one plane (1920x1080 for that full HD stream).
Old stereo 3D were displayed using anaglyph (cyan and red colours separated).
For compatibility with such movies, there is a value of the StereoMode that corresponds to AnaGlyph.¶
There is also a "packed" mode (values 13 and 14) which consists of packing two frames together
in a Block
using lacing. The first frame is the left eye and the other frame is the right eye
(or vice versa). The frames SHOULD be decoded in that order and are possibly dependent
on each other (P and B frames).¶
For separate tracks, Matroska needs to define exactly which track does what.
TrackOperation
with TrackCombinePlanes
do that. For more details look at
Section 26.3 on how TrackOperation works.¶
The 3D support is still in infancy and may evolve to support more features.¶
The StereoMode used to be part of Matroska v2 but it didn't meet the requirement
for multiple tracks. There was also a bug in libmatroska prior to 0.9.0 that would save/read
it as 0x53B9 instead of 0x53B8. Matroska Readers
may support these legacy files by checking
Matroska v2 or 0x53B9. The older values were 0: mono, 1: right eye, 2: left eye, 3: both eyes.¶
Historically timestamps in Matroska were mistakenly called timecodes. The Timestamp Element
was called Timecode, the TimestampScale Element
was called TimecodeScale, the
TrackTimestampScale Element
was called TrackTimecodeScale and the
ReferenceTimestamp Element
was called ReferenceTimeCode.¶
The Block Element
's timestamp MUST be a signed integer that represents the
Raw Timestamp
relative to the Cluster
's Timestamp Element
, multiplied by the
TimestampScale Element
. See Section 27.4 for more information.¶
The Block Element
's timestamp MUST be represented by a 16bit signed integer (sint16).
The Block
's timestamp has a range of -32768 to +32767 units. When using the default value
of the TimestampScale Element
, each integer represents 1ms. The maximum time span of
Block Elements
in a Cluster
using the default TimestampScale Element
of 1ms is 65536ms.¶
If a Cluster
's Timestamp Element
is set to zero, it is possible to have Block Elements
with a negative Raw Timestamp
. Block Elements
with a negative Raw Timestamp
are not valid.¶
The exact time of an object SHOULD be represented in nanoseconds. To find out a Block
's
Raw Timestamp
, you need the Block
's Timestamp Element
, the Cluster
's Timestamp Element
,
and the TimestampScale Element
.¶
The TimestampScale Element
is used to calculate the Raw Timestamp
of a Block
.
The timestamp is obtained by adding the Block
's timestamp to the Cluster
's Timestamp Element
,
and then multiplying that result by the TimestampScale
. The result will be the Block
's Raw Timestamp
in nanoseconds. The formula for this would look like:¶
(a + b) * c a = `Block`'s Timestamp b = `Cluster`'s Timestamp c = `TimestampScale`¶
For example, assume a Cluster
's Timestamp
has a value of 564264, the Block
has a Timestamp
of 1233, and the TimestampScale Element
is the default of 1000000.¶
(1233 + 564264) * 1000000 = 565497000000¶
So, the Block
in this example has a specific time of 565497000000 in nanoseconds.
In milliseconds this would be 565497ms.¶
Because the default value of TimestampScale
is 1000000, which makes each integer in the
Cluster
and Block
Timestamp Elements
equal 1ms, this is the most commonly used.
When dealing with audio, this causes inaccuracy when seeking. When the audio is combined with video,
this is not an issue. For most cases, the the synch of audio to video does not need to be more than
1ms accurate. This becomes obvious when one considers that sound will take 2-3ms to travel a single meter,
so distance from your speakers will have a greater effect on audio/visual synch than this.¶
However, when dealing with audio-only files, seeking accuracy can become critical. For instance, when storing a whole CD in a single track, a user will want to be able to seek to the exact sample that a song begins at. If seeking a few sample ahead or behind, a crack or pop may result as a few odd samples are rendered. Also, when performing precise editing, it may be very useful to have the audio accuracy down to a single sample.¶
When storing timestamps for an audio stream, the TimestampScale Element
SHOULD have an accuracy
of at least that of the audio sample rate, otherwise there are rounding errors that prevent users
from knowing the precise location of a sample. Here's how a program has to round each timestamp
in order to be able to recreate the sample number accurately.¶
Let's assume that the application has an audio track with a sample rate of 44100. As written
above the TimestampScale
MUST have at least the accuracy of the sample rate itself: 1000000000 / 44100 = 22675.7369614512.
This value MUST always be truncated. Otherwise the accuracy will not suffice.
So in this example the application will use 22675 for the TimestampScale
.
The application could even use some lower value like 22674, which would allow it to be a
little bit imprecise about the original timestamps. But more about that in a minute.¶
Next the application wants to write sample number 52340 and calculates the timestamp. This is easy.
In order to calculate the Raw Timestamp
in ns all it has to do is calculate
Raw Timestamp = round(1000000000 * sample_number / sample_rate)
. Rounding at this stage
is very important! The application might skip it if it choses a slightly smaller value for
the TimestampScale
factor instead of the truncated one like shown above.
Otherwise it has to round or the results won't be reversible.
For our example we get Raw Timestamp = round(1000000000 * 52340 / 44100) = round(1186848072.56236) = 1186848073
.¶
The next step is to calculate the Absolute Timestamp
- that is the timestamp that
will be stored in the Matroska file. Here the application has to divide the Raw Timestamp
from the previous paragraph by the TimestampScale
factor and round the result:
Absolute Timestamp = round(Raw Timestamp / TimestampScale_factor)
, which will result in the
following for our example: Absolute Timestamp = round(1186848073 / 22675) = round(52341.7011245866) = 52342
.
This number is the one the application has to write to the file.¶
Now our file is complete, and we want to play it back with another application.
Its task is to find out which sample the first application wrote into the file.
So it starts reading the Matroska file and finds the TimestampScale
factor 22675 and
the audio sample rate 44100. Later it finds a data block with the Absolute Timestamp
of 52342.
But how does it get the sample number from these numbers?¶
First it has to calculate the Raw Timestamp
of the block it has just read. Here's no
rounding involved, just an integer multiplication: Raw Timestamp = Absolute Timestamp * TimestampScale_factor
.
In our example: Raw Timestamp = 52342 * 22675 = 1186854850
.¶
The conversion from the Raw Timestamp
to the sample number again requires rounding:
sample_number = round(Raw Timestamp * sample_rate / 1000000000)
.
In our example: sample_number = round(1186854850 * 44100 / 1000000000) = round(52340.298885) = 52340
.
This is exactly the sample number that the previous program started with.¶
Some general notes for a program:¶
Raw Timestamp
.¶
The TrackTimestampScale Element
is used align tracks that would otherwise be played at
different speeds. An example of this would be if you have a film that was originally recorded
at 24fps video. When playing this back through a PAL broadcasting system, it is standard to
speed up the film to 25fps to match the 25fps display speed of the PAL broadcasting standard.
However, when broadcasting the video through NTSC, it is typical to leave the film at its
original speed. If you wanted to make a single file where there was one video stream,
and an audio stream used from the PAL broadcast, as well as an audio stream used from the NTSC
broadcast, you would have the problem that the PAL audio stream would be 1/24th faster than
the NTSC audio stream, quickly leading to problems. It is possible to stretch out the PAL
audio track and re-encode it at a slower speed, however when dealing with lossy audio codecs,
this often results in a loss of audio quality and/or larger file sizes.¶
This is the type of problem that TrackTimestampScale
was designed to fix. Using it,
the video can be played back at a speed that will synch with either the NTSC or the PAL
audio stream, depending on which is being used for playback.
To continue the above example:¶
Track 1: Video Track 2: NTSC Audio Track 3: PAL Audio¶
Because the NTSC track is at the original speed, it will used as the default value of 1.0 for
its TrackTimestampScale
. The video will also be aligned to the NTSC track with the default value of 1.0.¶
The TrackTimestampScale
value to use for the PAL track would be calculated by
determining how much faster the PAL track is than the NTSC track. In this case,
because we know the video for the NTSC audio is being played back at 24fps and the video
for the PAL audio is being played back at 25fps, the calculation would be:¶
25/24 is almost 1.04166666666666666667¶
When writing a file that uses a non-default TrackTimestampScale
, the values of the Block
's
timestamp are whatever they would be when normally storing the track with a default value for
the TrackTimestampScale
. However, the data is interleaved a little differently.
Data SHOULD be interleaved by its Raw Timestamp, see Section 27.3, in the order handed back
from the encoder. The Raw Timestamp
of a Block
from a track using TrackTimestampScale
is calculated using:¶
(Block's Timestamp + Cluster's Timestamp) * TimestampScale * TrackTimestampScale
¶
So, a Block from the PAL track above that had a Scaled Timestamp, see Section 27.1, of 100
seconds would have a Raw Timestamp
of 104.66666667 seconds, and so would be stored in that
part of the file.¶
When playing back a track using the TrackTimestampScale
, if the track is being played by itself,
there is no need to scale it. From the above example, when playing the Video with the NTSC Audio,
neither are scaled. However, when playing back the Video with the PAL Audio, the timestamps
from the PAL Audio track are scaled using the TrackTimestampScale
, resulting in the video
playing back in synch with the audio.¶
It would be possible for a Matroska Player
to also adjust the audio's samplerate at the
same time as adjusting the timestamps if you wanted to play the two audio streams synchronously.
It would also be possible to adjust the video to match the audio's speed. However,
for playback, the selected track(s) timestamps SHOULD be adjusted if they need to be scaled.¶
While the above example deals specifically with audio tracks, this element can be used to align video, audio, subtitles, or any other type of track contained in a Matroska file.¶