Zusammenfassung

  • BMPEG verband ganze Videoslices, ganze Audioframes, einen 90-kHz-Bildzeitstempel, Audiolänge und signierten Audio Offset in einem RTP-Strom.
  • Diese Angaben beschrieben die Verpackung des Senders; vollständige Ankunft, korrekter Decoderzustand, Lippensynchronität, Gerätausgabe und Publikum blieben getrennte Tatsachen.

Ein Paket mit dem Anschein eines Programms

Die Nutzlast wirkte vollständig: zuerst Video, danach Audio für die Dauer des enthaltenen Bildsegments. Der RTP-Header lieferte Reihenfolge, Bildzeit und Bildende. Der BMPEG-Header ergänzte Bildtyp, Änderung der MPEG-Headerdaten, Audio Length und den zeitlichen Abstand des Audiobeginns.

Für einen VOD-Server von 1998 war das attraktiv. Ein Programm brauchte einen Port. Bereits verschachtelt gespeichertes Material musste nicht in zwei Sessions zerlegt werden. Gemeinsame Header senkten den Overhead; das Beispiel nannte rund ein Prozent bei 4 Mbit/s. Auch ein gemeinsamer Puffer konnte kleiner sein als zwei Puffer für unabhängig verzögerte Ströme.

Die Spezifikation nannte das implicit synchronization. Gemeint war eine transportierte Zeitbeziehung. Das war noch keine Messung der Ausgänge.

Effizienz gegen Modularität

RFC 2343 war Experimental und ausdrücklich kein Internetstandard. Bündelung war eine Option, wenn ihre Vorteile den Verlust der Modularität getrennter Audio- und Videoströme rechtfertigten.

Damit wurden auch Fehler gekoppelt. Ein verlorenes Paket konnte Ton und Bild beschädigen. Der Empfänger konnte Medien weniger unabhängig auswählen. Große Pakete drohten den Path MTU zu überschreiten und in unteren Schichten fragmentiert zu werden.

BMPEG ließ MPEG-Systems-Information weg, die als redundant zu RTP galt. Die Aufgabe verschwand nicht, sondern wechselte den Besitzer. Packetizer, Receiver und Anwendung mussten sich weiterhin über Zeit, Zustand, Puffer und Recovery einig sein. Syntaxkonformität allein garantierte diese Übereinstimmung nicht.

Codec-Grenzen als Transport-Grenzen

Ein Video_Sequence_Header begann die Nutzlast. Ein GOP_header begann sie oder folgte dem Sequence Header. Ein Picture_Header begann sie oder folgte dem GOP. Jedes Paket enthielt eine ganze Zahl von Videoslices.

Diese Regeln schufen bekannte Wiedereinstiegspunkte. Sie verhinderten keine Fragmentierung. Der Sender musste Slice-Größe und Anzahl auf den MTU abstimmen. Andernfalls griff die Fragmentierung der unteren Schicht, mit größerem Verlustschaden und möglichen Problemen bei der RSVP-Klassifikation.

Auf das Video folgten ganze Audioframes, die seine Dauer abdeckten. Ein längerer Audioframe konnte mehrere nachfolgende Pakete audiofrei machen. Der letzte Frame durfte zur Verlustvorsorge wiederholt werden.

Ein Parser konnte all das akzeptieren, ohne zu wissen, ob ein Fragment fehlte, eine Wiederholung hörbar wurde oder der Puffer vor dem nächsten brauchbaren Frame leer lief.

Reihenfolge und Medienzeit waren verschieden

Der 32-Bit-Zeitstempel mit 90 kHz gab die Sampling-Zeit des Bildes an. Alle Pakete eines Bildes teilten ihn; Marker kennzeichnete das Paket mit dem Bildende.

Bei B-Bildern unterschieden sich Übertragungs- und Darstellungsreihenfolge, weshalb Zeitstempel nicht monoton sein mussten. Reine Headerpakete nutzten die Zeit des folgenden Bildes. Die Sequenznummer beschrieb dagegen die Transportreihenfolge.

Audio Offset maß in signierten Samples den Abstand zwischen Audiobeginn und Paketzeit. Bei 44,1 kHz waren es ungefähr ±750 ms. Bei sehr niedriger Bildrate, etwa einem Bild pro Sekunde, konnte das Format laut RFC ungeeignet sein.

Audio wurde nicht mit B-Bildern umsortiert. Es blieb in Übertragungsreihenfolge; der Offset erklärte seine vorgesehene Ausgabezeit. Ein korrekter Wert war ein Koordinatenpunkt, kein Beleg für Clock-Umrechnung, Gerätelatenz oder wahrgenommene Synchronität.

Schadensortung war keine Wiederherstellung

Lücken in Sequenznummer und Zeitstempel zeigten Verlust. Slice-Nummer und erste Macroblock-Position halfen bei der Abschätzung. Bei Verlust innerhalb eines Bildes konnte der Decoder Pixel eines früheren Bildes wiederholen. Fehlendes Audio ließ sich durch Hintergrundgeräusch ersetzen, um Lücken zu verbergen und Lip-Sync zu stützen.

Diese Ausgabe war konstruiert. Wiederholte Pixel und eingesetztes Audio waren nicht das verlorene Original. Concealment verkleinerte die sichtbare Störung, nicht den Datenverlust.

Das N-Bit meldete geänderte Sequence-, Extension-, GOP- oder Picture-Header. Ging neuer Zustand verloren, konnte Verwerfen bis zum nächsten Picture Start nötig sein. Nach starkem Verlust war ein neuer Sequence Header erforderlich.

BMPEG enthielt keinen speziellen Picture Counter wie die Temporal Reference aus RFC 2250. Ein verlorener GOP_header konnte unbemerkt bleiben und nachfolgende B-Bilder falsch decodieren. Parsebarkeit bewies keinen richtigen Kontext.

Nach dem Format folgten weitere Beweise

Zu prüfen waren rechtzeitige Ankunft, Fragment-Reassembly, Vollständigkeit der Bildpakete, Headerzustand, Decode, Umrechnung in Ausgabezeiten, A/V-Clock-Ausrichtung, Rendering, physischer Bildschirm- und Audiopfad, Mute/Hidden-Zustand und tatsächliches Publikum.

RTP reservierte keine Ressourcen und garantierte keine QoS. Ein gültiges Paket konnte zu spät kommen. Ein vollständiges Bild konnte von verlorenem Vorzustand abhängen. Ein decodierter Frame konnte verworfen werden. „Playing“ konnte im Hintergrund stehen. Ein leuchtender Bildschirm konnte einen leeren Sessel bedienen.

RFC 2343 machte die Aussage des Packetizers präzise. Gerade deshalb ist ihre Grenze sichtbar: Die Nutzlast bezeugte Verpackung, nicht Wiedergabe.