Matroska: MKV and MKA

Matroska stores multiple encoded tracks, timing information, and optional chapters and attachments in an extensible media container.

A film's main picture, original soundtrack, translation, commentary, and subtitles can all share one Matroska file. The container keeps their descriptions and timing separate so the viewer can choose a combination without duplicating the picture.

.mkv usually denotes video; .mka usually denotes audio without video. Both use the Matroska family. To understand what a reader does with either one, follow its structure from descriptions to media.

Elements describe other elements

Matroska uses EBML, a binary system of identified elements. An element has an ID, an encoded size, and data. Some elements contain a number or text; others contain child elements. The reader uses the known size and type to move through this hierarchy.

An EBML header identifies the document convention. The Matroska Segment contains the presentation's major structures. This is a hierarchy inside the format, not a claim that the whole movie is one network segment.

Segment component Reader's use
Info Overall timing scale and segment information
Tracks Codec, configuration, and properties of each media component
Clusters Groups of timed media blocks
SeekHead Locations of major elements
Cues Timeline entries used to find media efficiently
Chapters, Tags, Attachments Navigation, description, and supporting resources

The design permits optional elements a reader does not implement to be skipped by their declared size. Required interpretation still depends on the document version and the relevant component. Extensibility means the structure can evolve; it does not make every possible new feature behave identically in old software.

Reading one video block and the accompanying sound

The Tracks element identifies a video track and its CodecID. The codec mapping explains where decoder setup is stored and how the block's payload represents encoded units. A codec-private field may contain initialization information the decoder needs before processing media.

The reader then encounters Clusters containing blocks assigned to track numbers. Blocks from video and audio can be interleaved in file storage. Their track identities let the demuxer build separate sequences for decoding.

A cluster has a timestamp and a block has a relative timestamp. With an illustrative TimestampScale of 1,000,000 nanoseconds per tick, a cluster at 12,000 ticks and a block offset of 40 ticks represent:

(12,000 + 40) × 1,000,000 ns = 12.040 seconds

This example assumes the ordinary unit track scale. The block's place among file bytes is not itself its presentation time: a nearby audio block can use a different offset and contain a different amount of sound.

Selecting an English soundtrack tells the reader which audio track's blocks to deliver. It does not delete the German or commentary blocks stored in the file. That distinction is useful in Emby when a change in selected sound or subtitles changes processing even though the same MKV video remains selected.

Looking up a scene

To seek, a reader can use Cues to find a suitable cluster or block location near the requested time, then decode from a usable video random-access point. SeekHead serves another lookup role by locating top-level structures such as Tracks or Cues. A pointer to a structure and a pointer from media time to data are different kinds of index.

The seeking walkthrough explains why the decoder may reconstruct preceding pictures before showing the desired one. A Cue supplies a useful address; it does not remove dependencies in the compressed video.

Information outside the timed blocks

A font attachment supplies a file that a subtitle renderer may use. A cover image can be another attachment. These resources are not timed sound or picture streams, so preserving the main tracks during a remux does not automatically preserve them.

Ordinary chapters label points in a fixed timeline. Ordered editions can instead define ranges and references that compose a different sequence. Tags describe the file or particular objects. Together these features explain why a file's meaning is richer than a list of copied video and audio packets.

For a repackaged copy, compare the intended presentation components: selected tracks and language descriptions, timing, usable seeking, chapters, and supporting resources. Matroska's structure makes those individually describable, and an inspection can establish which of them the output actually retained.

See Also

References