Zusammenfassung

  • RFC 9559 kann einen legalen EBML-Aufbau, beschriebene Tracks und strukturierte Blocks belegen. Dieser Beleg endet vor Codec-Fähigkeit, geschlossenen Referenzen und synchronisierter Präsentation.
  • Cues darf ausgewählte Zeiten und Tracks erfassen; ein Livestream darf darauf verzichten. Ein Indextreffer belegt nicht, dass ein Seek ein eigenständig decodierbares sichtbares Bild erreicht.
  • Default- und Forced-Flags speisen die Player-Policy. Sie protokollieren nicht, welche Audio-, Untertitel- oder Barrierefreiheits-Spur beim konkreten Zuschauer ankam.

Ein Matroska Reader akzeptiert den EBML Header und läuft durch einen gültigen Elementbaum. Aus diesem lokalen Erfolg wird schnell das globale Urteil „abspielbar“. Die im Oktober 2024 auf dem IETF Standards Track veröffentlichte RFC 9559 ist genauer. Sie standardisiert einen Container: Track-Identität, Ablage codierter Frames, Zeitangaben und Indizes. Keiner dieser Mechanismen ist bereits der Bildschirm.

Die Legalisierung von Element ID 0x80 zeigt das Verhältnis von Dokument und Betrieb. RFC 8794 hatte den Wert reserviert, obwohl Matroska-Implementierungen ihn für ChapterDisplay nutzten. RFC 9559 brachte den gemeinsamen Text mit laufendem Code zusammen. Sie zertifizierte damit nicht nachträglich jedes historische File oder jede Reader-Entscheidung.

Lesbarkeit kann reduzierte Funktion bedeuten

DocTypeVersion muss das neueste verwendete Element abdecken. DocTypeReadVersion gibt an, welche Mindestversion für Wiedergabe genügt, gegebenenfalls mit reduziertem Funktionsumfang. Das RFC-Beispiel erlaubt ein CueRelativePosition aus Version 4 bei Read Version 2: Es verbessert die Seek-Genauigkeit, ist aber für normale Wiedergabe nicht zwingend.

Ein kompatibler Reader muss unbekannte Elemente überspringen, solange sie in die Größenregeln des Elternteils passen. „Erfolgreich geöffnet“ kann also heißen, dass Informationen absichtlich ungenutzt blieben. Ein belastbarer Beleg nennt Reader-Version, deklarierte Versionen und übersprungene Elemente.

Ein Block braucht Frame-Grenzen und Referenzgeschichte

Block und SimpleBlock bündeln Tracknummer, relativen Cluster-Zeitstempel, Flags, optionales Lacing und einen oder mehrere Frames. Xiph-, EBML- und Fixed-Size-Lacing sparen Overhead, verlangen aber eine korrekte Rekonstruktion der inneren Grenzen. Das Ende des Elements zu finden heißt nicht, jeden Frame richtig getrennt zu haben.

Danach entscheidet Referenzzustand. Wird ein abhängiger Frame fälschlich als Random Access Point behandelt, kann der Seek falsche Ausgabe oder sogar einen Absturz erzeugen. Manche Intra-only-Frames in AV1 oder VP9 lassen sich isoliert decodieren, setzen den Codec-Zustand jedoch nicht zurück. Spätere Bilder brauchen weiterhin eine Vergangenheit, die beim Sprung verloren ging. Entscheidend ist, ob am Ziel alle künftigen Referenzen geschlossen sind.

CodecID und bei Bedarf CodecPrivate benennen und initialisieren das Format. Gemeinsame Codec Mappings koordinieren Bezeichner, installieren aber keinen Decoder und belegen weder Profilunterstützung noch Ausgabe. Das ist ein eigener Fähigkeitsnachweis.

Ein gelesener Zeitstempel ist noch keine Zuschauerzeit

Die Präsentationszeit verbindet Cluster-Zeit, signierten Block-Wert, TrackTimestampScale, TimestampScale und gegebenenfalls CodecDelay. Frames mit negativer Zeit müssen möglicherweise decodiert, dürfen aber nicht gezeigt werden. Bruchteile sollen auf die nächste Nanosekunde gerundet werden.

RFC 9559 hält zugleich fest, dass viele historische Reader einen nicht standardmäßigen TrackTimestampScale ignorieren. Zwei Implementierungen können deshalb aus gültiger Syntax unterschiedliche operative Zeitleisten bauen. Bei Track Operations mit Überlappung kann das System Frames verwerfen oder verschieden rendern; plattformübergreifend ist das Ergebnis nicht sicher.

Darum gehören Recheneingaben, erzeugte Zeiten, A/V-Synchronität und Output-Fingerprints in den Beleg. Ein geparstes Integer ist kein präsentierter Moment.

Cues weist den Weg, beendet den Seek aber nicht

Cues indexiert ausgewählte Cluster für schnelleren Zugriff auf absolute Zeiten. Der Index kann jeden Block oder nur eine Auswahl erfassen. Für nicht-live Dateien werden Cues und Punkte für Video-Keyframes empfohlen; Audioeinträge dürfen bei vorhandenem Video fehlen. Auch ohne Index kann der Reader die Datei absuchen.

Prüfen muss man daher Coverage für Track und Zielzeit, Cluster- und Relativposition, Referenzschluss und schließlich den Abstand zwischen angefordertem und gezeigtem Frame. Der Cues-Hit schließt nur die Adressierung.

Im Livestream ändert sich die Evidenzfläche. Fortlaufende Segments dürfen SeekHead, Cues, Chapters und Attachments nicht benutzen. Fehlen die beiden Listen am Anfang, soll der Stream als nicht seekable gelten. Das kann für Live korrekt und für ein Produktversprechen zum Zurückspulen ungenügend sein.

Der Container trifft keine Nutzerentscheidung

FlagDefault macht einen Track für automatische Sprachwahl geeignet; der Player darf ihn etwa für Barrierefreiheitspräferenzen überstimmen. FlagForced fordert bestimmte Untertitel auch dann an, wenn die gewählte Audiospur gewöhnlich keine bräuchte. Weitere Flags kennzeichnen Hör- und Sehunterstützung, Beschreibung, Originalsprache und Kommentar.

Das sind Policy-Eingaben. Der tatsächliche Nachweis verbindet sie mit Nutzerpräferenz, Player-Priorität, ausgewählten Track UIDs und einem hör- oder sichtbaren Canary. Nach Heng Lus Running-Code-Linse koordiniert das RFC; konkrete Bytes, Parser, Decoder, Renderer und beobachtete Ausgabe entscheiden, was geschah.