Zusammenfassung

  • RFC 5334 behandelt Konformität je Medientyp; ein pauschales „Ogg unterstützt“ beweist weder Unterstützung aller drei Typen noch aller enthaltenen Codecs.
  • Deklarierter Typ, Streaminventar, Decoderfähigkeit, Behandlung je Stream und Präsentationsergebnis brauchen getrennte Nachweise.

Ein grünes Badge verlor sein Subjekt

Eine Plattform meldet „Ogg support: yes“. Im Test lief eine Datei mit audio/ogg und einem bekannten Audiostream. Später trifft application/ogg mit mehreren wissenschaftlichen Signalen, Script-Steuerung und einem unbekannten logischen Stream ein. Das gleiche Badge wird als Zulassungsnachweis verwendet, obwohl nie geprüft wurde, ob das Modul diesen Medientyp und seine Anforderungen erfüllt.

RFC 5334 definiert eine Implementierung als Softwaremodul, das einen der registrierten Typen unterstützt, und betrachtet Konformität für jeden Typ einzeln. Ein Modul kann mehrere unterstützen; daraus folgt aber nicht, dass eine bestandene Prüfung alle anderen abdeckt. Selbst innerhalb eines Typs bleibt Codec-Unterstützung eine weitere Dimension.

Das ist mehr als Testhygiene. Ein unqualifiziertes Produktmerkmal wandert in Ausschreibungen, Asset-Gates und Sicherheitsrichtlinien. Dort wird aus „ein Beispiel spielte“ die Behauptung „jedes Ogg-Objekt ist vollständig und sicher verarbeitbar“.

Drei Typen teilen einen Container, nicht dieselbe Verpflichtung

application/ogg bildet den weitesten Bereich für komplexe, multiplexierte oder wissenschaftliche Daten. video/ogg gilt für Material, das eine visuelle Oberfläche benötigt. audio/ogg ist für überwiegend akustischen Inhalt vorgesehen, auch wenn Liedtext, Metadaten oder Cover vorhanden sind.

Die Typen sind nach Verwendung verschachtelt. Sie sind keine exklusiven Listen erlaubter Streams. Deshalb kann ein Audiotyp Bildmaterial enthalten und ein Videotyp Audio und zeitgesteuerten Text. Das äußere Label leitet zur passenden Behandlungsklasse, ersetzt aber kein internes Inventar.

Auch die Anforderungen unterscheiden sich. application/ogg muss einen Skeleton-Stream enthalten, der die übrigen logischen Streams beschreibt. Bei Audio und Video ist Skeleton empfohlen. Ein Test, der nur das gemeinsame OggS erkennt, prüft keine dieser typabhängigen Pflichten.

Inventar und Fähigkeit sind zwei Verträge

Ein physischer Ogg-Bitstream kann mehrere logische Bitstreams multiplexen. Skeleton kann sie beschreiben, ohne zuerst jeden Header zu dekodieren. Ein korrektes Inventar sagt jedoch nicht, dass lokale Decoder vorhanden, aktiviert oder für konkrete Parameter geeignet sind.

Umgekehrt kann ein Decoder einen bekannten Stream abspielen, obwohl das für application/ogg vorgeschriebene Inventar fehlt. Lokaler Erfolg heilt den Vertragsfehler nicht. Er belegt nur, dass eine Teilstrecke zufällig genügend Information fand.

Der optionale codecs-Parameter ist eine dritte Sicht. Fehlt er, existieren weiterhin Codec-Kennungen in den Headern. Ist er vorhanden, bleibt er eine Deklaration. Die Plattform sollte äußere Angabe, Skeleton und beobachtete Header vergleichen, statt einen Wert zum Ersatz der anderen zu machen.

Teilverarbeitung ist kein Gesamtzertifikat

RFC 5334 empfiehlt, einen identifizierten, aber nicht dekodierbaren logischen Stream zu ignorieren und die verstandenen Streams weiterzuverarbeiten. Das erhält Vorwärts- und Rückwärtskompatibilität. Ein altes Modul kann den Hauptinhalt nutzen, obwohl eine neue Zusatzspur vorhanden ist.

Die Telemetrie muss dieses Ergebnis als teilweise benennen. Für lockere Wiedergabe kann es genügen. Für Barrierefreiheit, Archivtreue oder Beweissicherung kann der ignorierte Stream zwingend sein. Ein allgemeines Erfolgsbit kennt diesen Zweck nicht.

Ebenso wenig verlangt die Norm pauschal, das gesamte Objekt wegen einer unbekannten Spur abzulehnen. Ein Produkt darf strengere Regeln festlegen, muss aber offenlegen, dass sie aus der eigenen Policy stammen. Konformität, Fähigkeit und Geschäftsanforderung sind verschiedene Autoritäten.

Gemeinsame Signale beweisen nur Gemeinsamkeiten

Alle drei Typen verwenden das Capture Pattern OggS. Es identifiziert die Containerfamilie, nicht den richtigen Medientyp, die Streamliste oder einen Wiedergabeerfolg. Dateiendungen tragen ebenfalls begrenzte Kompatibilitätsinformation. RFC 5334 führte .ogx für komplexe Anwendungen ein, weil .ogg historisch oft als reines Vorbis-Audio verstanden wurde.

Ogg liefert auch keine generische Signatur oder Verschlüsselung. Geschützte Daten können enthalten oder der Gesamtstream extern geschützt werden. Herkunft und Berechtigung müssen separat belegt werden. Ausführbarer oder ressourcenintensiver Inhalt bleibt möglich; ein bekanntes Format ist keine Ausführungserlaubnis.

Ein aussagekräftiges Supportprofil nennt daher Medientyp, Skeleton-Verhalten, erkannte Streamtypen, verfügbare Decoder, Grenzwerte und die Definition von Vollständigkeit. Alles andere ist Marketing, nicht Betriebsbeweis.

Quellen und Evidenzgrenze

Die Quellen belegen Standards, Registrierungen und Entwicklung, nicht ein aktuelles Produkt, Asset, Deployment, Sicherheitsereignis oder Wiedergabeergebnis.