1. Introduction (Einführung)

Dieses Memo spezifiziert eine RTP-Nutzlastspezifikation für den Videocodierungsstandard, der als ITU-T-Empfehlung H.264 [1] und ISO/IEC-Internationaler Standard 14496-10 [2] bekannt ist (beide auch als Advanced Video Coding (AVC) bekannt). In diesem Memo wird der Name H.264 für den Codec und den Standard verwendet, aber dieses Memo ist gleichermaßen auf das ISO/IEC-Gegenstück des Codierungsstandards anwendbar.

Dieses Memo ersetzt RFC 3984. Änderungen gegenüber RFC 3984 sind in Abschnitt 14 zusammengefasst. Fragen zur Rückwärtskompatibilität mit RFC 3984 werden in Abschnitt 15 diskutiert.

1.1. The H.264 Codec (Der H.264-Codec)

Der H.264-Videocodec hat einen sehr breiten Anwendungsbereich, der alle Formen von digital komprimiertem Video abdeckt, von Internet-Streaming-Anwendungen mit niedriger Bitrate bis hin zu HDTV-Rundfunk und Digital-Cinema-Anwendungen mit nahezu verlustfreier Codierung. Im Vergleich zum aktuellen Stand der Technik ist die Gesamtleistung von H.264 so, dass Bitraten-Einsparungen von 50% oder mehr berichtet werden. Die Qualität von digitalem Satellitenfernsehen beispielsweise wurde als bei 1,5 Mbit/s erreichbar gemeldet, verglichen mit dem aktuellen Betriebspunkt von MPEG-2-Video bei etwa 3,5 Mbit/s [10].

Die Codec-Spezifikation [1] selbst unterscheidet konzeptionell zwischen einer Video Coding Layer (VCL) und einer Network Abstraction Layer (NAL). Die VCL enthält die Signalverarbeitungsfunktionalität des Codecs; Mechanismen wie Transformation, Quantisierung und bewegungskompensierte Vorhersage; und einen Schleifenfilter. Sie folgt dem allgemeinen Konzept der meisten heutigen Videocodecs, einem makroblockbasierten Coder, der Inter-Bild-Vorhersage mit Bewegungskompensation und Transformationscodierung des Residualsignals verwendet. Der VCL-Encoder gibt Slices aus: eine Bitfolge, die die Makroblockdaten einer ganzzahligen Anzahl von Makroblöcken und die Informationen des Slice-Headers enthält (enthält die räumliche Adresse des ersten Makroblocks im Slice, den anfänglichen Quantisierungsparameter und ähnliche Informationen). Makroblöcke in Slices sind in Scan-Reihenfolge angeordnet, es sei denn, eine andere Makroblockvergabe wird unter Verwendung der Syntax von Slice-Gruppen angegeben. Intra-Bild-Vorhersage wird nur innerhalb eines Slice verwendet. Weitere Informationen finden sich in [10].

Der NAL-Encoder kapselt die Slice-Ausgabe des VCL-Encoders in Network Abstraction Layer Units (NALUs), die für die Übertragung über Paketnetze oder zur Verwendung in paketorientierten Multiplexumgebungen geeignet sind. Anhang B von H.264 definiert einen Kapselungsprozess zur Übertragung solcher NALUs über bytestream-orientierte Netzwerke. Im Rahmen dieses Memos ist Anhang B nicht relevant.

Intern verwendet die NAL NAL-Einheiten. Eine NAL-Einheit besteht aus einem Ein-Byte-Header und der Nutzlast-Bytefolge. Der Header gibt den Typ der NAL-Einheit, das (potenzielle) Vorhandensein von Bitfehlern oder Syntaxverletzungen in der NAL-Einheits-Nutzlast und Informationen über die relative Wichtigkeit der NAL-Einheit für den Decodierungsprozess an. Diese RTP-Nutzlastspezifikation ist so konzipiert, dass sie die Bitfolge in der NAL-Einheits-Nutzlast nicht kennt.

Eine der Haupteigenschaften von H.264 ist die vollständige Entkopplung der Übertragungszeit, der Decodierungszeit und der Abtast- oder Präsentationszeit von Slices und Bildern. Der in H.264 spezifizierte Decodierungsprozess kennt keine Zeit, und die H.264-Syntax trägt keine Informationen wie die Anzahl übersprungener Frames (wie es in Form der Temporal Reference in früheren Videokompressionsnormen üblich ist). Außerdem gibt es NAL-Einheiten, die viele Bilder beeinflussen und daher von Natur aus zeitlos sind. Aus diesem Grund erfordert die Handhabung des RTP-Zeitstempels einige besondere Überlegungen für NAL-Einheiten, für die die Abtast- oder Präsentationszeit nicht definiert oder zum Übertragungszeitpunkt unbekannt ist.

1.2. Parameter Set Concept (Parametersatz-Konzept)

Ein sehr grundlegendes Designkonzept von H.264 ist die Erzeugung selbstständiger Pakete, um Mechanismen wie die Header-Duplizierung von RFC 4629 [11] oder MPEG-4 Visuals Header Extension Code (HEC) [12] überflüssig zu machen. Dies wurde durch Entkopplung von Informationen erreicht, die für mehr als einen Slice relevant sind, vom Medienstrom. Diese Meta-Informationen höherer Ebene sollten zuverlässig, asynchron und im Voraus vom RTP-Paketstrom gesendet werden, der die Slice-Pakete enthält. (Vorkehrungen zum In-Band-Senden dieser Informationen sind auch für Anwendungen verfügbar, die keinen für diesen Zweck geeigneten Out-of-Band-Transportkanal haben.) Die Kombination der Parameter höherer Ebene wird als Parametersatz bezeichnet. Die H.264-Spezifikation umfasst zwei Arten von Parametersätzen: Sequenzparametersätze und Bildparametersätze. Ein aktiver Sequenzparametersatz bleibt während einer codierten Videosequenz unverändert, und ein aktiver Bildparametersatz bleibt innerhalb eines codierten Bildes unverändert. Die Sequenz- und Bildparametersatzstrukturen enthalten Informationen wie Bildgröße, verwendete optionale Codierungsmodi und Makroblock-zu-Slice-Gruppen-Zuordnung.

Um Bildparameter (wie die Bildgröße) ändern zu können, ohne Parametersatz-Updates synchron zum Slice-Paketstrom übertragen zu müssen, können Encoder und Decoder eine Liste von mehr als einem Sequenz- und Bildparametersatz führen. Jeder Slice-Header enthält ein Codewort, das den zu verwendenden Sequenz- und Bildparametersatz angibt.

Dieser Mechanismus ermöglicht die Entkopplung der Übertragung von Parametersätzen vom Paketstrom und deren Übertragung durch externe Mittel (z.B. als Nebeneffekt des Fähigkeitsaustauschs) oder über ein (zuverlässiges oder unzuverlässiges) Steuerungsprotokoll. Es kann sogar möglich sein, dass sie nie übertragen werden, sondern durch eine Anwendungsentwurfsspezifikation festgelegt sind.

1.3. Network Abstraction Layer Unit Types (Network Abstraction Layer-Einheitstypen)

Tutorial-Informationen zum NAL-Design finden sich in [13], [14] und [15].

Alle NAL-Einheiten bestehen aus einem einzelnen NAL-Einheitstyp-Oktett, das auch als Nutzlast-Header dieses RTP-Nutzlastformats dient. Es folgt eine Beschreibung der Nutzlast einer NAL-Einheit.

Die Syntax und Semantik des NAL-Einheitstyp-Oktetts sind in [1] spezifiziert, aber die wesentlichen Eigenschaften des NAL-Einheitstyp-Oktetts werden unten zusammengefasst. Das NAL-Einheitstyp-Oktett hat folgendes Format:

   +---------------+
   |0|1|2|3|4|5|6|7|
   +-+-+-+-+-+-+-+-+
   |F|NRI|  Type   |
   +---------------+

Die Semantik der Komponenten des NAL-Einheitstyp-Oktetts, wie in der H.264-Spezifikation angegeben, wird nachfolgend kurz beschrieben.

F: 1 Bit forbidden_zero_bit. Die H.264-Spezifikation erklärt einen Wert von 1 als Syntaxverletzung.

NRI: 2 Bits nal_ref_idc. Ein Wert von 00 zeigt an, dass der Inhalt der NAL-Einheit nicht zur Rekonstruktion von Referenzbildern für die Inter-Bild-Vorhersage verwendet wird. Solche NAL-Einheiten können verworfen werden, ohne die Integrität der Referenzbilder zu gefährden. Werte größer als 00 zeigen an, dass die Decodierung der NAL-Einheit erforderlich ist, um die Integrität der Referenzbilder aufrechtzuerhalten.

Type: 5 Bits nal_unit_type. Diese Komponente spezifiziert den NAL-Einheits-Nutzlasttyp, wie in Tabelle 7-1 von [1] und später in diesem Memo definiert. Für eine Referenz aller derzeit definierten NAL-Einheitstypen und ihrer Semantik siehe Abschnitt 7.4.1 in [1].

Dieses Memo führt neue NAL-Einheitstypen ein, die in Abschnitt 5.2 vorgestellt werden. Die in diesem Memo definierten NAL-Einheitstypen sind in [1] als nicht spezifiziert markiert. Darüber hinaus erweitert diese Spezifikation die Semantik von F und NRI, wie in Abschnitt 5.3 beschrieben.