Zusammenfassung

  • RFC 2032 verbot, einen H.261-Makroblock auf zwei RTP-Pakete zu verteilen. Pakete mussten an Makroblockgrenzen beginnen und enden.
  • GOBN, MBAP, QUANT, HMVD/VMVD sowie I/V übertrugen den nötigen Startzustand. So konnte die Syntax nach einem Verlust wieder lesbar werden, ohne dass verlorene Bilddaten zurückkehrten.
  • Optionale FIR- und NACK-Meldungen forderten ein vollständiges INTRA-Bild an oder bezeichneten fehlende Sequenznummern. Eine adressierte Bitte war noch kein Beleg für Ausführung und sichtbare Reparatur.

Ein Videostrom kann seine Grammatik wiederfinden, während sein Bild beschädigt bleibt. RFC 2032 entwarf genau für diesen Zwischenzustand.

Der Proposed Standard erschien im Oktober 1996 und beschrieb H.261 direkt in RTP. H.261 stammte aus der Welt leitungsvermittelter ISDN-Kanäle; H.221-Rahmen konnten Video, Ton, Daten und Fehlerkorrektur verbinden. Die Internet-Nutzlast übernahm diese 512-Bit-Rahmen nicht, sondern transportierte den Huffman-codierten Videostrom. Paketverlust wurde damit nicht abgeschafft. Das Format musste verhindern, dass ein fehlendes Datagramm jede spätere Dekodierung zerstörte.

Die Makroblockgrenze war eine Ausfallgrenze

Ein H.261-Bild gliedert sich in Groups of Blocks mit jeweils 33 Makroblöcken. Ein Makroblock umfasst 16 mal 16 Bildpunkte. RFC 2032 erklärte ihn zur Fragmentierungseinheit: Kein Makroblock durfte ein Paket überschreiten, und zwischen GOB-Kopf und erstem Makroblock durfte ebenfalls nicht geschnitten werden.

Variable Huffman-Codes erklären die Strenge. Beginnt der Empfänger nach einem Verlust an einer beliebigen Bitstelle, kann er ein Feld nicht sicher von der Fortsetzung eines früheren Codes unterscheiden. Eine bekannte Grenze mit explizitem Startkontext gibt dem nächsten Paket wieder eine eindeutige Syntax.

Bildlich unabhängig wird es dadurch nicht. H.261 nutzt Zwischenbildvorhersage und Differenzwerte. Ein korrekt gelesener Makroblock kann von einer Referenzregion abhängen, die zuvor verloren ging. Der RFC weist darauf hin, dass beschädigte Bereiche bestehen bleiben können, bis die betreffenden Makroblöcke wieder INTRA-codiert werden. Der Neustart begrenzt Unverständlichkeit, nicht Schaden.

Vier Byte trugen das Gedächtnis des Starts

SBIT und EBIT markieren, wie viele Bits im ersten und letzten Oktett nicht zum Videostrom gehören. Damit passt eine bitgenaue Codesyntax in oktettausgerichtete Netzwerkpakete.

GOBN bezeichnet die Group of Blocks am Paketanfang; Null bedeutet den Beginn mit einem Bildkopf. MBAP speichert den Makroblock-Adressprädiktor relativ zum GOB-Anfang. QUANT hält den Quantisierer für den folgenden Makroblock. HMVD und VMVD stellen die horizontalen und vertikalen Referenzdaten für differenziell codierte Bewegungsvektoren bereit.

Diese Werte sind Dekodierzustand, kein Befund über die Anzeige. MBAP ist keine Bildschirmkoordinate einer reparierten Fläche. Es macht eine Adressdifferenz interpretierbar. Ein rekonstruierbarer Bewegungsvektor beweist ebenso wenig, dass sein Referenzbild fehlerfrei war.

I und V sind vorsichtige Hinweise. I bezeichnet einen ausschließlich INTRA-codierten Strom, V die mögliche Verwendung von Bewegungsvektoren. Laut RFC lassen sie sich aus dem Strom ableiten; eine konforme Implementierung darf konservativ V=1 und I=0 setzen. Die Bits wählen einen sicheren Decoderpfad, kontrollieren aber nicht jeden Makroblock und messen keine Qualität.

Ein markiertes Ende machte den Rahmen nicht vollständig

Alle RTP-Pakete eines Bildes teilen einen 90-kHz-Zeitstempel. Das Marker-Bit steht im letzten Paket eines Frames, damit der Empfänger nicht auf den nächsten Bildstartcode warten muss. Enthält ein Paket mehrere Bilder, gilt der RTP-Zeitstempel nur für das erste; weitere Anzeigezeiten folgen aus H.261-Köpfen.

Damit sind Zeit und deklariertes Ende bekannt. Der Marker bestätigt nicht, dass alle vorherigen Sequenznummern eingetroffen sind. RTP kann eine Lücke sichtbar machen; UDP liefert dem Sender aus dem Senden allein keine Empfangsbestätigung. „Letztes Paket empfangen“ und „vollständiges Bild empfangen“ sind nicht derselbe Messwert.

Eindämmung war keine Korrektur

RFC 2032 nennt drei Gegenmaßnahmen: regelmäßige reine INTRA-Bilder, eine an Verlust angepasste Auffrischungsrate und eine Auffrischungsanforderung des Decoders. Jede Maßnahme eröffnet einen Regelkreis. Keine dokumentiert von selbst dessen Abschluss.

Mit Paketgrenzen und kopiertem Kontext kann spätere Syntax überleben. Die fehlende Region bleibt trotzdem leer, eine beschädigte Referenz kann Vorhersagen verfälschen, und eine verspätete Korrektur verfehlt das Wiedergabefenster. Das Paketformat schützt zukünftige Interpretierbarkeit. Wiederherstellung verlangt weitere Ereignisse und Beobachtungen.

FIR und NACK machten Absicht adressierbar

Der RFC definierte optionale H.261-spezifische RTCP-Meldungen. Full INTRA-frame Request mit Payload Type 192 bat den Coder, das nächste Bild vollständig INTRA zu codieren; die SSRC bezeichnete den anfordernden Empfänger. Negative Acknowledgement mit Typ 193 führte in FSN die erste vermisste RTP-Sequenznummer und in BLP eine 16-Bit-Maske für die folgenden Nummern.

FIR bedeutet: Erneuere die Vorhersagebasis. NACK bedeutet: Diese Positionen habe ich nicht gesehen. Beides übersetzt eine lokale Beobachtung in eine handhabbare Adresse.

Die Verfahren blieben optional und topologieabhängig. Negative Bestätigungen konnten bei vielen Teilnehmern schaden. Die direkte Übertragung vom Decoder zum Coder funktionierte nur ohne Mixer und Translator; das IVS-Beispiel schaltete sie nur für kleine Empfängergruppen ein. Unterstützung, Rückweg und Skalierung waren Voraussetzungen außerhalb der Felder.

Ein beobachtetes FIR belegt die gesendete Bitte, nicht ihren Empfang oder ein tatsächlich erzeugtes INTRA-Bild. Ein NACK belegt die Verlustsicht des Empfängers, nicht eine verfügbare oder rechtzeitige Neuübertragung. Erst Quellaktion, Folgepakete, Decodergebnis und Anzeigezeit schließen die Beweiskette.

Die Spezifikation endete vor dem Ergebnis

Lu Hengs Prinzip der minimalen Anfangsspezifikation beschreibt die Grenze treffend. RFC 2032 standardisierte nur den gemeinsamen Kern: erlaubte Schnitte, Startkontext, Zeit, Frame-Ende und optionale Rückmeldesyntax. Pufferfrist, Auffrischungsstrategie, Bandbreitenkosten und akzeptabler Schaden blieben lokale Entscheidungen.

Die Vorrangstellung laufenden Codes liefert den Prüfmaßstab. Ein veröffentlichtes Feldformat, korrekt gesetzte Felder, Zustellung in beide Richtungen, ausgeführte Coderaktion und rechtzeitig dargestelltes Bild sind verschiedene Realitäten. Ein Mechanismusname darf nicht als Beleg für die ganze Kette dienen.

RFC Editor führt RFC 2032 heute als durch RFC 4587 abgelöst. Ohne die Nachfolgemechanik zu behandeln, bleibt die historische Leistung klar: Ein Verlust sollte weniger vom Strom unverständlich machen, und Reparaturabsicht bekam eine Adresse. Das reparierte Bild musste weiterhin gesondert bewiesen werden.

Quellen