Zusammenfassung

  • RFC 9924 beschreibt APV-Decoderfähigkeit profilbezogen als Profil-Level-Band-Tupel: Funktionsumfang, Luma-Samplerate und Tile-Geometrie sowie maximale codierte Datenrate.
  • Gültige Syntax, erklärte Fähigkeit, erfolgreicher Decode, begrenzter Ressourcenverbrauch, wahrgenommene Qualität und Produktionsfreigabe sind getrennte Belege.

Der entscheidende Fehler kann in einer einzigen Tabellenzelle stehen. „APV: ja“ sieht in einer Beschaffungsliste eindeutig aus. Es fehlt jedoch, welche Bildlast, Tile-Struktur und Datenrate der Empfänger für welches Profil tatsächlich zusagt. Aus einer Suchhilfe wird so unbemerkt ein Leistungsversprechen.

In einem rein illustrativen Übergabefall wird hochratiges 8K-Material angeliefert. Der Parser erkennt Syntax und Profil. Das für dieses Profil deklarierte Level deckt Samplerate und Tiles nicht ab; das Band reicht für den Datenstrom ebenfalls nicht. Ein anderes Material decodiert und scheitert später an der visuellen Freigabe. Es handelt sich um verschiedene Grenzen, nicht um ein einziges Kompatibilitätsurteil.

RFC 9924, Advanced Professional Video, erschien im Februar 2026 als Informational-Dokument im Independent Stream. Der Eintrag des RFC Editor stellt klar, dass es weder ein IETF-Produkt noch Ausdruck eines IETF-Konsenses ist. Die Veröffentlichung beglaubigt keine Implementierung, Messung oder Markteinführung.

APV zielt auf professionelle Aufzeichnung und Postproduktion mit niedriger Verzögerung, hohem Durchsatz und wiederholtem Decodieren und Neucodieren. Das Verfahren ist intra-frame-only und nutzt Tiles zur Parallelisierung. Beschrieben werden 2K-, 4K- und 8K-Material mit codierten Raten bis zu einigen Gbit/s, Chromaformen von 4:0:0 bis 4:4:4:4, Alpha, HDR und benutzerdefinierte Metadaten.

Die Syntax reicht von 10 bis 16 Bit. Gegenwärtig definierte Profile betreffen jedoch 10 und 12 Bit. Ein 16-Bit-Wertebereich in der Syntax ist kein definiertes 16-Bit-Profil und schon gar kein Nachweis einer entsprechenden Produktfähigkeit.

Das Profil legt eine Teilmenge algorithmischer Funktionen und die Pflichten jedes konformen Decoders fest. Es ist kein Maß für Arbeitsspeicher, Bildrate oder Qualitätsurteil. Das Level begrenzt die Luma-Samplerate und Tile-Geometrie. Das Band bestimmt innerhalb eines Levels die höchste codierte Datenrate.

Diese Angaben gelten pro Profil. Eine Implementierung darf für unterschiedliche Profile unterschiedliche Level unterstützen. Das höchste aufgeführte Profil kann deshalb nicht als gemeinsame Spitzenleistung des ganzen Decoders gelesen werden. Zwei Produkte mit demselben Profilnamen können verschiedene Lastbereiche zusagen.

RFC 9924 verzichtet zudem auf einzeln wählbare Decoderoptionen. Jede Option würde die Kombinationen vermehren, die ein Encoder erzeugen und ein Decoder erwarten könnte. Die Spezifikation macht Implementierungen nicht identisch; sie hält Unterschiede an expliziten Profil-, Level- und Bandgrenzen fest und begrenzt damit die Interoperabilitätskomplexität.

Die reservierten Kennungen folgen absichtlich verschiedenen Regeln. Ein reservierter profile_idc zwischen bekannten Werten darf nicht als Zwischenfähigkeit verstanden werden, denn Profile sind Funktionsmengen und keine lineare Rangfolge. Reservierte level_idc- und band_idc-Werte zwischen festgelegten Werten sind dagegen als Zwischenfähigkeiten zu behandeln, weil sie geordnete Ressourcenhüllen beschreiben.

Laufender Code liefert weitere, aber keine endgültigen Belege. OpenAPV und seine Bitstream-Tests, das Android-16-Material zu APV, die Seite zu FFmpeg 8.0 und der zitierte Encoder-Commit sind konkrete Implementierungsflächen. Ihre Erreichbarkeit beweist keine vollständige Konformität, Geschwindigkeit, Geräteabdeckung, Sicherheit, Bildqualität oder Produktionsnutzung.

Eine belastbare Prüfung trennt ihre Fragen. Ist der Bitstream syntaktisch gültig? Liegt sein Tupel innerhalb der für dieses Profil erklärten Fähigkeit? Decodiert der exakt bezeichnete Build? Bleiben Zeit, Speicher und Fehlerpfad begrenzt? Entspricht die Ausgabe nach einer angegebenen Methode der Referenz? Akzeptiert die Produktion sie einschließlich Farbe, Metadaten und Mehrgenerationenverhalten?

Die Sicherheitsanforderungen zeigen den Wert dieser Trennung. Vorhersagbare Headerbits und Padding dürfen nicht mit Chiffren oder Modi kombiniert werden, die gegen Known-Plaintext-Angriffe anfällig sind; APV stellt keine Vertraulichkeit bereit. Bösartige Payloads dürfen weder Speicher überlaufen lassen noch übermäßige Ressourcen beanspruchen; Integer-Overflow-Prüfungen sind erforderlich. Ein später Fehler nach vollständiger Erschöpfung ist kein robuster Fehlerpfad.

Auch der Encoder kann über ein Transcoding-Gateway feindliche Eingaben erhalten. Seltenere Encoderprobleme sind nicht unmöglich. Unbekannte Metadatentypen darf der Decoder nicht verarbeiten, weil Fehlinterpretation einen unbekannten Zustand erzeugen kann. Dass der Inhalt nicht zur Ausführung gedacht ist, garantiert ebenfalls keine Sicherheit vor malformed media.

Die Errata-Suche zu RFC 9924 beschreibt Dokumentpflege, nicht Binärqualität. „Perceptually lossless“ bleibt ein Entwurfsziel, bis Material, Anzeige, Methode und Ergebnis einer Bewertung offengelegt sind.

Heng Lus Running-Code Primacy rückt den tatsächlich ausgeführten Parser, Decoder, Encoder und das Gateway vor das Produktlabel. Minimum Initial Specification hält die gemeinsame Verpflichtung schmal und präzise. Reality Layers verhindert, dass Publikation, Syntax, Erklärung, Ausführung, Ausgabe, Wahrnehmung und Freigabe zu einem Status verschmelzen.

Der nützliche Nachweis verbindet das Tupel des Materials mit dem erklärten Tupel des Decoders für dieses Profil. Hinzu kommen Abmessungen, Framerate, Tiles, Chroma, Alpha, Bittiefe, Datenrate, Build, Konfiguration, Ergebnisse, Ressourcenspitzen, Metadatenbehandlung, Vergleichsmethode, Ausgabekennung und Produktionsentscheidung. „APV unterstützt“ darf eine Vorauswahl eröffnen. Einen Vertrag darf es nicht ersetzen.

Quellen