Zusammenfassung

  • RFC 2038 schrieb eine Paketierung vor, bei der sich der nächste MPEG-Slice-Anfang ohne Suche im Payload erkennen ließ. Die Bits B und E beschrieben, wie der RTP-Payload an Slice-Grenzen ausgerichtet war.
  • Jedes Videopaket wiederholte Temporal Reference (TR), Picture Type (P) und die jeweils nötigen Vorwärts- und Rückwärtsparameter der Bewegungsvektoren. Nach Verlust eines GOP Header oder Picture Header ließ sich daraus am nächsten Slice ein begrenzter Ersatzkontext bilden.
  • Sequenzlücke, B/E und wiederholter Zustand belegen nur die Grundlage einer lokalen Neustartentscheidung. Sie belegen weder frühere Slices noch wahrheitsgemäße Header, ein vollständiges Bild, verfügbare Referenzbilder, korrekte Decodierung, lückenlose Wiedergabe, Zuschauerempfang oder QoS.

Im Mitschnitt folgt auf RTP-Paket 1440 unmittelbar Paket 1442. Das zweite Paket trägt B=1, Temporal Reference 8 und den Bildtyp P samt Vorwärtsvektorparametern. Für den Empfänger ist das genug, um das beschädigte Fragment nicht weiterzureichen, einen kleinen Teil des verlorenen Bildkontexts zu ersetzen und dem Decoder den neuen Slice-Anfang anzubieten.

Es ist nicht genug, um das Ergebnis „wiederhergestellt“ zu nennen. In Paket 1441 könnten unverzichtbare Makroblöcke gelegen haben. Das Referenzbild für das P-Bild könnte fehlen oder selbst beschädigt sein. Der Sender könnte das B-Bit falsch gesetzt haben. Auch ein syntaktisch akzeptierter Ersatzheader kann von den ursprünglichen Werten abweichen.

Die Stärke von RFC 2038 lag gerade in dieser Begrenzung: Der Standard machte einen erneuten Einstieg möglich, ohne die unbekannte Vergangenheit in bekannte Bildqualität umzudeuten.

Die Erholungseinheit wurde für RTP sichtbar

Ein komprimierter MPEG-Strom besteht nicht aus beliebig neu betretbaren, unabhängigen Blöcken. Räumliche und zeitliche Abhängigkeiten können dafür sorgen, dass der Verlust weniger Daten später eingetroffene Bytes nutzlos macht. Große Bilder müssen zugleich auf Pakete unterhalb einer üblichen Netz-MTU verteilt werden.

RFC 2038 band diese Aufteilung an klare Positionen. Ein Video Sequence Header musste am Beginn eines RTP-Payloads stehen. Ein GOP Header begann den Payload oder folgte unmittelbar auf den Sequence Header. Ein Picture Header begann ebenfalls den Payload oder folgte dem GOP Header. Jeder dieser Elementary-Stream-Header musste vollständig in ein einziges Paket passen.

Für Slices formulierte das RFC die eigentliche Wiederaufnahmeregel. Der Slice galt als vorgesehene MPEG-Erholungseinheit nach Verlust oder Beschädigung. Sein Anfang durfte das erste Datum im Payload sein, nach den zulässigen MPEG-Headern folgen oder hinter einer ganzen Zahl vollständiger Slices im selben Payload liegen. Ein Slice durfte dennoch über Paketgrenzen reichen. Das Format versprach also nie „ein Paket pro Slice“.

Diese Ordnung ersparte dem Empfänger nach einem Verlust das Durchsuchen beliebiger Payload-Bytes nach einem Startcode. Die Paketierung hatte einen semantisch brauchbaren Punkt an eine signalisierbare Stelle gelegt. Der Codec definierte die Erholungseinheit; der RTP-spezifische Header machte sie sichtbar. Sichtbarkeit verlieh dem Transport aber keine Aussagegewalt über die Richtigkeit des MPEG-Inhalts.

B und E beschrieben Ausrichtung, nicht Vollständigkeit

Auf den festen RTP-Header folgte ein 32 Bit langer Videoheader. B=1 bedeutete, dass der Payload mit einem Slice-Startcode begann, allenfalls nach einem Video Sequence Header, GOP Header oder Picture Header. E=1 bedeutete, dass das letzte Payload-Byte zugleich das Ende eines MPEG-Slice war.

Mit den vier Kombinationen ließ sich erkennen, ob ein Paket an beiden Slice-Grenzen ausgerichtet war, einen fortgesetzten Slice begann, einen früher begonnenen Slice abschloss oder nur ein Mittelstück enthielt. Diese Form war bekannt, bevor der komprimierte Payload vollständig analysiert wurde.

Doch B=1 blieb eine Behauptung des Senders. Das Bit authentifizierte weder den tatsächlichen Startcode noch die folgenden Bytes. E=1 führte nicht Buch über andere Fragmente desselben Slice. Auch ein beidseitig ausgerichtetes Paket konnte nach einer Sequenzlücke eintreffen, durch die ein anderer Teil des Bildes verschwunden war. Umgekehrt konnte ein Paket ohne B und E bytegenau eintreffen und mangels seines Anfangs trotzdem unbrauchbar sein.

Die präzise Beweisaussage lautet deshalb: B/E belegen den im Paketheader getragenen Grenzzustand. Ob echte MPEG-Syntax, ein vollständiger Slice und decodierbare Daten vorliegen, muss auf den jeweiligen Schichten gesondert geprüft werden.

Ein verkleinertes Bilddossier reiste in jedem Paket mit

Zusätzlich zur Ausrichtung wiederholte RFC 2038 wesentliche Bildwerte. Das zehn Bit breite TR führte die Temporal Reference des aktuellen Bildes innerhalb seiner GOP und blieb für alle RTP-Pakete dieses Bildes gleich. Das drei Bit breite P bezeichnete ein I-, P-, B- oder D-Bild und blieb ebenfalls konstant.

Vier weitere Felder übernahmen aus dem jüngsten Picture Header die Full-Pel-Kennzeichen und f-codes für Rückwärts- und Vorwärtsbewegungsvektoren. I-Bilder setzten sie sämtlich auf null. P-Bilder nutzten das Vorwärtspaar und nullten das Rückwärtspaar. B-Bilder konnten alle vier verwenden. Das war keine Kopie des Bildes und auch kein vollständiger Picture Header, sondern ein bewusst kleines Dossier für ausgewählte Rekonstruktionen.

Ging der einzige Picture Header mit einem Paket verloren, konnte ein späterer Slice zwar sichtbar sein, dem Decoder aber Bildtyp und Vektorinterpretation fehlen. Die Wiederholung löste diese Abhängigkeit am nächsten verwendbaren Slice: Grenze und minimale Eingaben kamen gemeinsam an.

Die wiederholten Werte lieferten außerdem einen Konsistenzhinweis. Unerwartete Änderungen von TR oder P konnten auf einen verlorenen GOP Header oder Picture Header deuten. Anhang 1 schlug Zähler für Referenz- und abhängige Bilder vor und verglich deren Erwartung mit der wiederholten Temporal Reference. Eine Abweichung zeigte, dass lokale Erwartung und Paketdeklaration auseinanderliefen. Sie enthüllte weder den ursprünglichen Headerinhalt noch die Ursache der Lücke.

Der rekonstruierte Header blieb eine Näherung

Für einen verlorenen GOP Header empfahl RFC 2038 einen Ersatz mit Null-Timecode, dem closed_gop-Wert der vorherigen GOP und broken_link=1. Einen verlorenen Picture Header konnte der Empfänger am nächsten Beginning-of-slice aus P, TR, den vier Vektorfeldern und stromabhängigen Vorgabewerten bilden.

„Rekonstruktion“ bedeutete hier nicht Wiedergewinnung. Der Null-Timecode war nicht der verschwundene Senderwert. Ein übernommenes altes Kennzeichen war keine Beobachtung der neuen GOP. Ein Default blieb eine Annahme des Empfängers. broken_link=1 machte diese Grenze sogar ausdrücklich sichtbar: Über die Bruchstelle hinweg durfte der prädiktive Zusammenhang nicht als verlässlich gelten.

Ein solcher Ersatz konnte einen Decodierversuch ermöglichen. Er belegte nicht, dass alle Referenzen existierten oder der sichtbare Inhalt korrekt war. Das Format hielt Verarbeitungskontinuität und Inhaltskorrektheit auseinander.

Eine Sequenzlücke löste Schadensbegrenzung aus

Anhang 1 gab einen einfachen Ablauf vor: Zeigte eine Lücke in den RTP-Sequenznummern Verlust an, durfte der Empfänger weitere Pakete verwerfen, bis eines mit Beginning-of-slice eintraf. Dort war genug Zustand vorhanden, um MPEG-Verarbeitung wieder zu beginnen, gegebenenfalls nach Ersatz eines GOP oder Picture Header.

RTP-Sequenznummern steigen mit den gesendeten Datenpaketen und helfen bei Verlustanzeige und Senderreihenfolge. RTP garantierte jedoch weder Zustellung noch Reihenfolge, Rechtzeitigkeit oder Dienstgüte. Eine bei einem Empfänger beobachtete Lücke unterscheidet für sich allein keinen physischen Verlust von Umordnung oder unvollständiger Erfassung. Ebenso wenig verrät sie den Inhalt des fehlenden Pakets.

Das Verwerfen bis B war daher Schadensbegrenzung, kein endgültiges Urteil. Möglicherweise intakte Fortsetzungsbytes wurden geopfert, weil ihr erforderlicher Anfang unbekannt war. Lokale Erholbarkeit entstand dadurch, dass die Implementierung Unsicherheit nicht überspielte.

Sieben Belege dürfen nicht zu „erholt“ verschmelzen

Eine Untersuchung sollte mindestens sieben Beobachtungen trennen: RTP-Sequenzkontinuität; B/E-Deklaration; tatsächlich geparste MPEG-Grenzsyntax; wiederholter TR/P/Vektorzustand; Vorhandensein und Integrität erforderlicher Referenzbilder; Decoderausgabe einschließlich Fehlerverdeckung; zeitgerechte Wiedergabe und Beobachtung beim Publikum.

Jede frühere Ebene kann die Prüfung der nächsten begründen, aber nicht deren Ergebnis ersetzen. Ein stimmiges B/E-Muster belegt kein vollständiges Bild. Plausible TR/P-Werte sind nicht der verlorene Header. Erfolgreiches Parsen belegt keine korrekte Prädiktion. Ein ausgegebenes Frame belegt keine lückenlose Präsentation. Ein Player-Ereignis belegt nicht, dass ein Mensch das Ergebnis sah oder akzeptierte.

RFC 2038 erschien im Oktober 1996 als Proposed Standard und wurde im Januar 1998 durch RFC 2250 abgelöst. Das heutige IANA-RTP-Register führt den statischen Payload Type 32 als MPV mit 90 kHz und verweist auf RFC 2250. Das belegt eine Registerzuweisung, nicht heutige Nutzung, Implementierungsqualität oder Verkehr in einem bestimmten Netz.

Der dauerhafte Gedanke des kurzlebigen Standards lautet: Resilienz wird besser, wenn die wirkliche Erholungseinheit eines komprimierten Formats an der Paketgrenze sichtbar ist und der kleinste nötige Zustand in ihrer Nähe wiederholt wird. Eine Neustartgrenze ist die Erlaubnis, es erneut zu versuchen. Sie ist kein Beleg dafür, dass das Bild davor oder danach vollständig war.

Quellen