Zusammenfassung

  • Vor den komprimierten Daten trägt jede CellB-RTP-Nutzlast vier vorzeichenlose 16-Bit-Werte: X/Y der ersten 4×4-Zelle sowie Bildbreite und -höhe in Pixeln.
  • Mehrbyte-Codes dürfen kein Paket überschreiten. Nach einem Paketverlust beginnt das nächste vollständig empfangene Paket deshalb an einer Codegrenze und nennt seine räumliche Startposition.
  • Das Format begrenzt Folgeschäden, ersetzt aber keine verlorenen Daten. Koordinaten, Maße, gemeinsamer Frame-Zeitstempel und Marker beweisen weder vollständige Zellen noch übereinstimmende Quantisierungstabellen, erfolgreiche Dekodierung oder sichtbare Kontinuität.

Bei komprimiertem Video kann ein fehlendes Paket zwei Lücken reißen. Seine Bildinformation fehlt. Zugleich kann der Empfänger den Anschluss verlieren: Beginnen die nächsten Bytes mit einem neuen Befehl oder mitten in einem alten, und an welche Stelle des Bildes gehören sie?

RFC 2029 trennte diese Probleme. Das im Oktober 1996 veröffentlichte Format versprach keine Rekonstruktion des verlorenen Inhalts. Es wiederholte genügend Kontext, damit der Verlust eines Pakets nicht zwingend auch alle nachfolgenden Pakete unverständlich machte.

Der räumliche Anker wurde pro Paket erneuert

Am Anfang der CellB-Nutzlast stehen Cell X Location, Cell Y Location, Width of Image und Height of Image. Jedes Feld umfasst 16 Bit und verwendet Netzwerkbyteordnung. Die Koordinaten zählen CellB-Zellen; jede Zelle deckt 4×4 Pixel ab. Breite und Höhe werden dagegen in Pixeln angegeben.

Damit verfügt jedes Paket über eine Art Adresse: erster Block an dieser Stelle, innerhalb eines Bildes dieser Größe. Die Bildmaße dürfen nur zwischen Frames wechseln. Trotzdem werden sie in jedem Paket wiederholt, sodass ein späteres Paket sie nicht aus einem möglicherweise verlorenen Vorgänger übernehmen muss.

Die Adresse bleibt eine Behauptung des Senders. Sie enthält keine Liste erwarteter Zellen und bestätigt weder die Ankunft früherer Bereiche noch die vollständige Abdeckung des Bildes. Auch Überlappungen oder unplausible Koordinaten werden durch die bloße Existenz der Felder nicht ausgeschlossen. Der Empfänger weiß, wo er ansetzen soll; er weiß noch nicht, ob das Gesamtbild vollständig ist.

Die Paketgrenze durfte keinen Code zerreißen

Der CellB-Strom verwendet verschiedene Codelängen. Ein regulärer, vier Byte langer Zellcode beschreibt einen 4×4-Block. Ein ein Byte langer Skip-Code überspringt eine bis 32 Zellen. Weitere Befehle kündigen neue Y/Y- oder U/V-Quantisierungstabellen mit jeweils 512 folgenden Bytes an.

Die Paketgröße kann der Implementierer bis hin zu einem vollständigen Frame wählen. Mehrbyte-Codes müssen jedoch vollständig in einem Paket liegen. Ein Netzwerkschnitt darf also weder einen vier Byte langen Zellcode noch eine Tabellenaktualisierung auf zwei Pakete verteilen.

Diese Regel liefert den syntaktischen Gegenpart zur Koordinate. Verschwindet ein Paket, beginnt das nächste intakte Paket nicht mit dem verwaisten Ende eines verlorenen Befehls. Seine Nutzlast startet an einer Codegrenze, sein Header nennt den Ort der ersten Zelle.

Das ist lokale Resynchronisierung. Es ist keine Fehlerkorrektur. RFC 2029 definiert hier weder Wiederholung noch Vorwärtsfehlerkorrektur, Redundanz oder Ersetzung der fehlenden Zellen. Die verlorene Region bleibt verloren; lediglich die Ausbreitung des Parserschadens wird eingedämmt.

Frame-Markierungen zählen keine Pakete

CellB verwendet einen RTP-Takt von 90 kHz. Alle Pakete eines Frames teilen denselben Zeitstempel, das Marker-Bit kennzeichnet dessen letztes Paket. So werden die räumlich adressierten Teile einem zeitlichen Frame zugeordnet.

Ein gemeinsamer Zeitstempel ist aber keine Mitgliederliste. Marker sagt, welches Paket der Sender als letztes gekennzeichnet hat; es sagt nicht, ob alle davor angekommen sind. RTP-Sequenznummern können Lücken erkennen lassen und die Sendereihenfolge wiederherstellen. Die RTP-Grundlage stellt zugleich klar, dass RTP Zustellung, Rechtzeitigkeit, Ankunftsreihenfolge und Dienstgüte nicht garantiert.

Ein korrekt markiertes Endpaket kann daher zusammen mit einer Lücke im Frame ankommen. Seine Metadaten sind Belege für die Kennzeichnung und Platzierung, nicht für die Vollständigkeit des Inhalts.

Eine verlorene Tabelle verändert die Bedeutung intakter Indizes

CellB speichert in den U/V- und Y/Y-Feldern Indizes auf Chrominanz- und Luminanzvektortabellen. Welche Pixelwerte entstehen, hängt vom Tabellenzustand im Decoder ab.

RFC 2029 beschreibt Befehle, die jede Tabelle durch 512 neue Bytes ersetzen. Das mitgelieferte Beispielpaar aus Encoder und Decoder implementierte diese Funktion nicht, doch künftige Codecs konnten sie nutzen. Weil die Aktualisierung ein Mehrbyte-Code ist, bleibt eine empfangene Tabelle innerhalb einer Paketgrenze vollständig.

Geht dagegen das ganze Aktualisierungspaket verloren, hilft die Grenze allein nicht. Ein späteres Paket kann syntaktisch sauber, räumlich korrekt adressiert und dem richtigen Frame zugeordnet sein. Der Empfänger kann seine Indizes trotzdem mit der alten Tabelle auswerten. Die Position stimmt, die Pixelbedeutung nicht.

Das RFC berichtet damit keinen konkreten Zwischenfall. Die Schlussfolgerung folgt aus dem Zusammenspiel von Indexsemantik und Paketregel. Sie zeigt, welche Abhängigkeit aufgehoben wurde—Position und Codefortsetzung—und welche bestehen blieb: vorherige Zustandsänderungen.

Vom Paketnachweis bis zum Sehergebnis fehlen mehrere Stufen

Eine belastbare Prüfung hält Transportreihenfolge, deklarierte Position, Syntaxgrenze und Frame-Zuordnung auseinander. Erst darüber hinaus folgen Tabellenzustand, Decoderergebnis, Rendering und Ausgabe am Endgerät.

Für die Behauptung eines vollständigen Frames braucht man tatsächliche Nutzlasten und eine validierte räumliche Abdeckung. Für korrekte Pixel braucht man die richtige Tabellenversion und Decoderbelege. Für Wiedergabequalität braucht man Zeit- und Endpunktmessungen. Kein Feld des acht Byte großen CellB-Headers überspringt diese Nachweise.

IANA führt CelB weiterhin als festen RTP-Nutzlasttyp 25 für Video mit 90.000 Hz und Verweis auf RFC 2029. Das belegt eine Parametervergabe, nicht den heutigen Einsatz. Auch der fortbestehende Status Proposed Standard belegt weder Interoperabilität noch Dienstqualität.

Die historische Leistung von RFC 2029 war deshalb präzise: Ein intaktes Folgepaket erhielt einen eigenständigen räumlichen und syntaktischen Einstieg. Aus einem Verlust musste nicht zwangsläufig ein unbeschränkter Dekodierausfall werden. Diese Grenze gilt auch für die Sprache der Beweise. Weiterlesen zu können heißt nicht, das Fehlende wiedergefunden zu haben.

Quellen