Zusammenfassung

  • Der IESG genehmigte draft-ietf-avtcore-rtp-jpegxs-3ed-07 am 14. September als Proposed Standard; am 21. September fehlte weiterhin eine RFC-Nummer, und die RFC-Editor-Warteschlange verlangte Eingaben der Autoren.
  • Bestehende RFC-9134-konforme Implementierungen bleiben in ihrem unterstützten Funktionsumfang gültig. Daraus folgt keine TDC-Fähigkeit eines alten Empfängers.
  • Eine Editions-Kompatibilitätsquittung sollte Dokumentstatus, beide Builds, das genaue SDP, den Nicht-TDC-Rückfall und abgegrenzte Medientests verbinden.

Ein genehmigtes Dokument erzeugt noch kein Bild am Ausgang. Zwischen der IESG-Entscheidung und dem Produktionsmonitor liegen die RFC-Herstellung, das IANA-Register, Lieferstände der Hersteller, die Schnittmenge zweier Endpunkte und ein tatsächlicher Decodiertest.

Am 14. September 2026 genehmigte der IESG Revision 07 von RTP Payload Format for ISO/IEC 21122 (JPEG XS) zur Veröffentlichung als Proposed Standard. Ein Proposed Standard ist kein Internet Standard. Eine Protocol Action ist auch nicht die Veröffentlichung des RFC.

Der öffentliche Stand vom 21. September zeigt den Übergang. Datatracker führt das Dokument in der RFC Ed Queue. In der RFC-Editor-Warteschlange sind das Intake Form und eine Antwort der Autoren ausstehend. Es gibt noch keine RFC-Nummer. IANA muss die geänderte Version erneut prüfen; der öffentliche Eintrag video/jxsv verweist weiter auf RFC 9134. Das sind keine technischen Ablehnungen, sondern getrennte Produktionszustände.

Obsoletes bedeutet nicht Abschaltung

Revision 07 sagt, dass das künftige Dokument RFC 9134 ablösen wird. Diese Beziehung macht die neue Spezifikation zur maßgeblichen Referenz. Sie deaktiviert keine installierten Geräte, widerruft keine Firmware und beendet am Veröffentlichungstag keinen Nicht-TDC-Stream.

Die Überarbeitung ist auf inkrementelle Einführung ausgelegt. Vorhandene konforme RFC-9134-Implementierungen bleiben gültig, und Legacy-Systeme arbeiten innerhalb ihres unterstützten Funktionsumfangs weiter. Genau dort liegt die Grenze: Die alte Kompatibilitätsmenge bleibt erhalten, ohne dass alte Hardware neue Fähigkeiten erhält.

TDC bringt Zustand zwischen Bildern

Die ersten beiden JPEG-XS-Ausgaben nutzten Intra-Codierung. Die dritte Ausgabe ergänzt Temporal Differential Coding und verwendet zeitliche Dekorrelation im Wavelet-Bereich. Ein Nicht-TDC-Codestream ist als eigenständiges Bild decodierbar. Ein TDC-Codestream kann von rekonstruierten Koeffizienten des vorangegangenen Codestreams abhängen: ein Frame Buffer für progressive Inhalte, zwei getrennte Buffer für Interlaced oder PsF.

Deshalb berücksichtigt die Revision den SLI-Marker für TDC-Slices und ergänzt fbblevel, die Frame-Buffer-Bandbreitenstufe. fbblevel darf nur bei TDC vorkommen und muss dem Wert im JPEG-XS-Bildsegment entsprechen. Dasselbe Konsistenzprinzip gilt für profile, level und sublevel.

Ein älterer Empfänger kann somit weiterhin konform Nicht-TDC verarbeiten und dennoch weder das TDC-Profil noch den nötigen Buffer besitzen. Rückwärtsverträgliches Design erhält die bisherige Schnittmenge; es erweitert nicht automatisch den Decoder.

SDP beschreibt die konkrete Schnittmenge

Der Subtyp bleibt video/jxsv, die RTP-Uhr läuft mit 90 kHz, und packetmode ist erforderlich. SDP trägt jxsv/90000 in a=rtpmap; a=fmtp enthält packetmode und optionale Werte wie profile, level, sublevel und fbblevel.

Im Unicast-Offer/Answer muss der Answerer alle angebotenen Parameter und Werte unterstützen, sonst muss er die Session ablehnen. Bei Annahme gibt er dieselben Werte zurück. Der Offerer trägt damit die Verantwortung, eine erwartbar unterstützte Kombination zu wählen.

Die Regel verhindert ein unklares Teil-Ja, schafft aber keinen automatischen Rückfall. Nach einer abgelehnten TDC-Offerte ist zu prüfen, ob Sender oder Orchestrierung eine neue, ausdrücklich TDC-freie Offerte senden. Selbst eine angenommene SDP-Beschreibung beweist erst die Parameterübereinstimmung, nicht die fehlerfreie Decodierung.

Ein nachprüfbarer Beleg statt eines Labels

Die Editions-Kompatibilitätsquittung sollte Revision und SHA-256, IESG-/RFC-Editor-/IANA-Stand, die spätere RFC-Nummer, video/jxsv, Payload Type, Clock, packetmode, Profil, Level, Sublevel, fbblevel und TDC-Status enthalten. Hinzu kommen Produkte, Builds, Firmware und Konfiguration beider Seiten, Offer und Answer oder Ablehnung, Nicht-TDC-Fallback, Testsample, Signalform, Framerate, Dauer und Paketbedingungen sowie Fehler, Korrektur, Wiederholung, Rollback und Ausstiegskriterium.

Auch der Geltungsbereich gehört in den Befund. Ein Gerätepaar und ein progressives Sample decken nicht alle Levels, Interlaced-Formate oder Gateways ab. Ein TDC-Fehler widerlegt umgekehrt nicht den Nicht-TDC-Betrieb nach RFC 9134. Belastbar ist die enge Aussage: Diese beiden Builds tauschten diesen Stream unter diesen Bedingungen aus.

Quellen

  1. IETF Datatracker: JPEG-XS-RTP-Überarbeitung
  2. Dokumenthistorie
  3. Text von Revision 07
  4. RFC-Editor-Warteschlange
  5. RFC 9134
  6. IANA-Registrierung video/jxsv