Zusammenfassung

  • RFC 3984 trennte H.264-Bilddaten von den Sequenz- und Bildparametersätzen, die ihre Dekodierregeln enthielten; ein Slice konnte Regeln referenzieren, ohne sie mitzuliefern.
  • Transportmetriken erfassten diesen Zustand nicht. Fehlende, verspätete oder zu früh überschriebene SPS/PPS konnten viele intakte Folgepakete unbrauchbar machen.

Die Betriebsanzeige ist grün. Sequenznummern bilden eine nahezu lückenlose Reihe, Zeitstempel bewegen sich plausibel, die Jitterwerte bleiben niedrig. Das Bild zerfällt trotzdem. Ein solches Dashboard irrt nicht über das, was es misst. Es misst nur nicht den Zustand, von dem die Nutzdaten abhängen.

RFC 3984 legte im Februar 2005 das RTP-Nutzlastformat für H.264 fest. Status, Errata und Datatracker-Verlauf zeigen, dass RFC 6184 die Spezifikation später ablöste. Historisch bemerkenswert ist neben Paketierung und Fragmentierung vor allem die Behandlung des Decoderzustands: Die Regeln zur Auslegung eines Bildes konnten einen anderen Weg nehmen als das Bild.

H.264 lagert wiederverwendete Informationen in Parametersätze aus. Ein Sequenzparametersatz, SPS, beschreibt Eigenschaften einer codierten Videosequenz. Ein Bildparametersatz, PPS, enthält Eigenschaften für codierte Bilder, etwa Modi oder die Zuordnung von Makroblöcken zu Slice-Gruppen. Der Slice-Header wiederholt diese Angaben nicht, sondern nennt Kennungen.

Damit entsteht eine Referenzbeziehung. Eine Kennung ist kein Parametersatz. Der richtige Satz muss vor der abhängigen NAL-Einheit in Dekodierreihenfolge verfügbar und aktiv sein. Ein Paket kann auf der RTP-Zeitachse rechtzeitig eintreffen und auf der Konfigurationszeitachse zu früh sein.

Die RFC 3550 definiert die Reichweite der üblichen Messwerte. Sequenznummern dienen Verlustfeststellung und Reihenfolge, Zeitstempel dem Abtastzeitpunkt und der Synchronisierung. Weder Status, Errata noch Datatracker machen daraus eine Versionsanzeige für SPS/PPS. Aus Transportgesundheit folgt keine Konfigurationsgesundheit.

RFC 3984 ordnete die Zustellung in drei Prinzipien. A bedeutete zuverlässige Übertragung außerhalb des Medienbands vor Beginn der RTP-Sitzung. B bedeutete zuverlässige Aktualisierung außerhalb des Bands während der Sitzung. C bedeutete Zustellung innerhalb des RTP-Stroms. Die Fassung von 2005 empfahl A und B als zuverlässige Wege. Für C waren Wiederholung, erneute Übertragung oder Vorwärtsfehlerkorrektur wichtig, weil der Verlust eines Parametersatzes viele spätere NAL-Einheiten beeinflussen konnte.

sprop-parameter-sets konnte initiale Parametersatz-NALs base64-codiert in der Medienbeschreibung tragen. Sie mussten Einheiten, die auf sie verweisen, in Dekodierreihenfolge vorausgehen. Der Parameter war ausdrücklich keine Fähigkeitsangabe. Er beschrieb den vorgesehenen Zustand des Stroms, nicht die Gesamtheit dessen, was ein Empfänger unterstützt.

Außerbandzustand verbindet Medien mit Signalisierung. RFC 4566, Status, Errata und Datatracker definieren SDP als Beschreibungsformat. RFC 3264 ordnet Offer/Answer und lässt nur ein offenes Angebot zu; Status, Errata und Verlauf dokumentieren diesen Ablauf.

Bei einer zuverlässigen Aktualisierung empfahl RFC 3984, die Signalisierungsbestätigung abzuwarten, bevor abhängige NAL-Einheiten gesendet werden. Eine Implementierung muss dennoch festlegen, was bestätigt wurde: Empfang, Prüfung, Speicherung oder Aktivierung. SDP ist kein universeller Beleg dafür, dass der Decoder das nachfolgende Bild erfolgreich darstellt.

Die Kennungslebensdauer war eine weitere verborgene Metrik. Wird ein PPS unter derselben ID ersetzt, während alte Slices noch im Netz oder im Puffer liegen, lösen sie ihre alte Referenz gegen neue Regeln auf. Die Paketbytes können vollständig sein. Der semantische Bezug ist dennoch falsch.

RFC 3984 riet daher zu einer lange unbenutzten Kennung oder zu einer neuen Kennung. Das Sicherheitsfenster umfasst Laufzeit, Umordnung, Jitterpuffer und Decoderhaltung. Erst wenn die letzte abhängige Einheit abgeflossen ist, kann die alte Bedeutung gefahrlos aufgegeben werden.

Bei mehreren Sendern kommt Namenshoheit hinzu. Zwei Encoder können dieselbe ID für verschiedene Sätze verwenden und für sich genommen korrekt arbeiten. Ein Mixer oder Gateway muss Bereiche zuteilen, Referenzen umschreiben oder Kontexte trennen. Ohne gemeinsamen Eigentümer des Namensraums wird lokale Gültigkeit zur globalen Kollision.

Auch die Kombination der Kanäle erforderte Kontrolle. RFC 3984 wollte Prinzip B und C nicht ohne ausreichende Synchronisierung mischen. Ein später Teilnehmer kennt womöglich nur den ursprünglichen Außerbandzustand und hat eine frühere In-Band-Aktualisierung verpasst. Ein verlorenes Update lässt einen Empfänger veraltete Regeln behalten, obwohl alle folgenden Bildpakete eintreffen.

RFC 6184 änderte später die allgemeine Präferenz. Status, Errata und Datatracker zeigen, dass In-Band- und Außerbandübertragung zugelassen werden und in-band-parameter-sets zur Aushandlung gehört. Die dauerhafte Lehre lautet daher nicht „immer außer Band“, sondern „gewählten Weg und Zustandswechsel explizit machen“.

RFC 7798 behandelt später HEVC über RTP; Status, Errata und Datatracker erlauben einen Vergleich. Parametersatzsignalisierung blieb eine Aufgabe von Videonutzlastformaten. Daraus folgt keine Aussage über einheitliche Verbreitung oder identische Implementierungen.

Der große Wirkungsradius erklärt auch die Sicherheitsbetrachtung. Ein beschädigtes Bildpaket kann örtlich begrenzten Schaden erzeugen. Ein manipulierter Parametersatz verändert potenziell die Interpretation vieler nachfolgender Einheiten. Integrität und Ursprungsauthentisierung schützen daher nicht bloß ein kleines Steuerpaket, sondern eine längere Kette abhängiger Medien.

Ein belastbares Dashboard müsste neben Verlust und Jitter die referenzierte SPS/PPS-Version, deren Alter, Herkunft, Aktivierungszeit und Ablaufhorizont zeigen. Für Vorfälle sind SDP-Austausch, Bestätigungen, In-Band-Sätze, Nutzlasttypwechsel und Pufferdauer aufzubewahren. Sonst ist „alle Pakete vorhanden“ eine präzise, aber unvollständige Diagnose.

RFC 3984 macht sichtbar, warum verteilte Systeme mehrere Uhren brauchen. Datenzustellung und Bedeutungszustellung sind unterschiedliche Vorgänge. Erst ein explizites Modell für Version, Besitz, Bestätigung und Auslaufen verbindet sie zu einem dekodierbaren Strom.

Quellen