Summary

  • RFC 9559 can prove that a Matroska reader encountered a legal EBML document, track description and block structure. That receipt ends before codec support, reference closure and synchronized presentation.
  • Cues may cover selected times and tracks, while live streams may legitimately omit them. A valid index is not proof that a requested seek landed on a decodable visible frame.
  • Default and forced track flags guide player policy but do not record the audio, subtitle or accessibility path a particular viewer actually received.

A Matroska reader opens the file, accepts its EBML header and walks a legal tree of elements. The temptation is to call the result playable. RFC 9559 is more exact than that shorthand. It standardizes a container: the structure that identifies tracks, stores encoded frames, places timestamps and offers indexes. Each of those mechanisms supplies evidence, but none is the final screen or speaker.

Published on the IETF Standards Track in October 2024, RFC 9559 formalizes a format that was already widely implemented. Its update to EBML is revealing. RFC 8794 had reserved the one-octet Element ID 0x80, even though deployed Matroska software used it for ChapterDisplay. The new RFC makes that identifier legal. The common document caught up with running code; publication did not retrospectively prove that every historical file, parser or chapter display behaved alike.

Readable is a bounded compatibility decision

The EBML header separates DocTypeVersion from DocTypeReadVersion. The former must cover the newest Matroska element used. The latter states the minimum version a reader needs to play the file, potentially with a reduced feature set. RFC 9559's own example permits a version-4 CueRelativePosition while keeping the read version at 2 because the element improves seek precision but is not essential to ordinary playback.

That is disciplined interoperability, not a full-feature certificate. A compatible reader must skip unknown elements that fit their parent constraints. “Opened successfully” may therefore mean that the reader deliberately ignored information another implementation would use. The receipt should name the reader, the declared versions and every skipped element before it claims more than structural acceptance.

Blocks must become frames, and frames must carry their history

A Block or SimpleBlock combines a track number, a timestamp relative to its Cluster, flags, optional lacing and one or more encoded frames. Xiph, EBML and fixed-size lacing save overhead by packing frames together. Correctly finding the element boundary is not the same as correctly recovering every frame boundary inside it.

Reference state creates another divide. RFC 9559 warns that a dependent frame incorrectly treated as a random-access point can produce bogus output or even crash. Some intra-only AV1 or VP9 frames decode without another frame yet do not reset codec state; following pictures may still depend on history that a seek has discarded. The key question is not merely “is there a frame here?” but “does this point close every reference required for what comes next?”

The container's CodecID and optional CodecPrivate data tell an implementation how encoded bytes are identified and initialized. The Matroska codec mappings make those identifiers common. They do not install a decoder, grant it resources or prove its output. That adjacent boundary belongs to a separate capability receipt, not to the element parser.

A parsed timestamp is not yet the viewer's time

Matroska has Segment ticks and Track ticks. A block's presentation timestamp combines the Cluster timestamp, the signed block timestamp, TrackTimestampScale, TimestampScale and, where present, CodecDelay. Negative-time frames may need to be decoded but must not be shown. Floating-point results should be rounded to the nearest nanosecond.

RFC 9559 also records an awkward operational fact: many historical readers ignore a non-default TrackTimestampScale, so values other than 1.0 may fail in many places. A writer can therefore satisfy the syntax while two readers construct different operational timelines. Track operations add another branch; when component tracks overlap, the underlying system may drop or render frames differently, and the specification says the end result cannot be assured across platforms.

This is not an argument against standards. It is the reason to retain the calculation inputs and compare produced timestamps, synchronization and output fingerprints rather than treating a parsed integer as a presentation outcome.

Cues describe an available route, not a completed seek

Cues indexes selected Cluster positions for faster access to absolute times. It is flexible: a writer can index every block timestamp or only some. For ordinary files the RFC says Cues should be present and each video keyframe should normally have a CuePoint; audio references may be omitted when video exists. A reader can also seek without the index by searching through the file.

The evidence is consequently conditional. First ask whether the requested track and time are covered. Then ask whether the cue reaches the right cluster and relative position. Then verify that the target closes its references, the decoder reconstructs forward from it, and the displayed frame falls inside the permitted seek error. A cue hit closes only the routing step.

Livestreaming changes the contract deliberately. Continuous live segments must not use SeekHead, Cues, chapters or attachments. A stream with neither index at its beginning should be treated as non-seekable. Absence can be valid for the mode, while remaining decisive for a product that promised scrubbing or replay.

The container does not choose on the viewer's behalf

FlagDefault makes a track eligible for automatic selection by language. A player may override it, including for accessibility preferences. FlagForced asks a player to show a subtitle track even when the current audio choice would not normally call for subtitles. Other flags describe hearing-impaired, visual-impaired, descriptive, original-language and commentary tracks.

These fields are policy inputs. They do not reveal the user's preference, the player's precedence rules or the track UIDs that reached the output device. A conforming file can offer the right accessibility track while a local policy chooses another. The decisive receipt joins container flags to player settings, selected tracks and an audible or visible canary.

Heng Lu's running-code principle supplies the proper finish line. The RFC is a coordination artifact. The observed result belongs to the implementation chain: exact bytes, parser decisions, recovered frames, reference state, timestamp arithmetic, cue route, track policy, decoder, renderer and output. Keep those layers separate and Matroska's precision becomes more useful, not less.