8.4. Parameter Set Considerations (Überlegungen zu Parametersätzen)

8.4. Parameter Set Considerations (Überlegungen zu Parametersätzen)

Die H.264-Parametersätze sind ein grundlegender Teil des Videocodecs und für dessen Betrieb unerlässlich (siehe Abschnitt 1.2). Aufgrund ihrer Eigenschaften und ihrer Bedeutung für den Dekodierungsprozess können verlorene oder fehlerhaft übertragene Parametersätze am Empfänger kaum lokal verborgen werden. Ein Verweis auf einen beschädigten Parametersatz hat normalerweise fatale Folgen für den Dekodierungsprozess. Beschädigung kann beispielsweise durch fehlerhafte Übertragung oder Verlust einer Parametersatz-NAL-Einheit, aber auch durch unzeitige Übertragung einer Parametersatz-Aktualisierung auftreten. Eine Parametersatz-Aktualisierung bezeichnet eine Änderung mindestens eines Parameters in einem Bild- oder Sequenzparametersatz, bei der der Bild- bzw. Sequenzparametersatz-Identifier unverändert bleibt. Daher werden die folgenden Empfehlungen als Leitfaden für den Implementierer des RTP-Senders gegeben.

Parametersatz-NALUs können mit drei verschiedenen Prinzipien transportiert werden:

A. Verwendung eines Sitzungssteuerungsprotokolls (außerhalb der Bandbreite) vor der eigentlichen RTP-Sitzung.

B. Verwendung eines Sitzungssteuerungsprotokolls (außerhalb der Bandbreite) während einer laufenden RTP-Sitzung.

C. Innerhalb des RTP-Paketstroms in der Nutzlast (in der Bandbreite) während einer laufenden RTP-Sitzung.

Es wird empfohlen, die Prinzipien A und B innerhalb eines Sitzungssteuerungsprotokolls zu implementieren. SIP und SDP können wie im SDP-Offer/Answer-Modell und in den vorherigen Abschnitten dieses Memos beschrieben verwendet werden. Abschnitt 8.2.2 enthält eine ausführliche Diskussion des Transports von Parametersätzen in der Bandbreite oder außerhalb der Bandbreite in SDP Offer/Answer unter Verwendung der Medientyp-Parameter sprop-parameter-sets, sprop-level-parameter-sets, use-level-src-parameter-sets und in-band-parameter-sets. Dieser Abschnitt enthält Richtlinien, wie die Prinzipien A und B innerhalb von Sitzungssteuerungsprotokollen implementiert werden sollten. Er ist unabhängig vom jeweiligen verwendeten Protokoll. Prinzip C wird durch das in dieser Spezifikation definierte RTP-Nutzlastformat unterstützt. Es gibt Topologien wie Topo-Video-switch-MCU [29], für die die Verwendung von Prinzip C wünschenswert sein kann.

Wenn In-Band-Signalisierung von Parametersätzen verwendet wird, SOLLTEN die Bild- und Sequenzparametersatz-NALUs in der RTP-Nutzlast mit einer zuverlässigen Methode der RTP-Zustellung übertragen werden (siehe unten), da der Verlust eines Parametersatzes von einem der beiden Typs wahrscheinlich die Dekodierung eines erheblichen Teils des entsprechenden RTP-Paketstroms verhindert.

Wenn In-Band-Signalisierung von Parametersätzen verwendet wird, SOLLTE der Sender die Fehlercharakteristika berücksichtigen und Mechanismen einsetzen, um eine hohe Wahrscheinlichkeit für die korrekte Zustellung der Parametersätze zu gewährleisten. Mechanismen, die die Wahrscheinlichkeit einer korrekten Empfangs erhöhen, umfassen Paketwiederholung, FEC und Retransmission. Die Verwendung eines unzuverlässigen Out-of-Band-Steuerungsprotokolls hat ähnliche Nachteile wie die In-Band-Signalisierung (möglicher Verlust) und kann darüber hinaus zu Synchronisationsschwierigkeiten führen (siehe unten). Daher wird es NICHT EMPFOHLEN.

Parametersätze DÜRFEN während der Lebensdauer einer Sitzung mit den Prinzipien B und C hinzugefügt oder aktualisiert werden. Es ist erforderlich, dass Parametersätze am Dekodierer vor den NAL-Einheiten vorhanden sind, die auf sie verweisen. Aktualisierung oder Hinzufügen von Parametersätzen kann weitere Probleme verursachen ; daher SOLLTEN die folgenden Empfehlungen berücksichtigt werden.

• Wenn Parametersätze hinzugefügt oder aktualisiert werden, SOLLTE darauf geachtet werden, dass jeder Parametersatz vor seiner Verwendung zugestellt wird. Wenn neue Parametersätze hinzugefügt werden, werden zuvor unbenutzte Parametersatz-Identifier verwendet. Es ist üblich, dass keine Synchronisation zwischen Out-of-Band-Signalisierung und In-Band-Verkehr besteht. Wenn Out-of-Band-Signalisierung verwendet wird, wird EMPFOHLEN, dass ein Sender nicht mit dem Senden von NALUs beginnt, die die hinzugefügten oder aktualisierten Parametersätze benötigen, bevor eine Zustellungsbestätigung vom Signalisierungsprotokoll vorliegt.

• Wenn Parametersätze aktualisiert werden, SOLLTE das folgende Synchronisationsproblem berücksichtigt werden. Beim Überschreiben eines Parametersatzes am Empfänger muss der Sender sicherstellen, dass der betreffende Parametersatz von keiner NALU benötigt wird, die sich in Netzwerk- oder Empfängerpuffern befindet. Andernfalls kann eine Dekodierung mit einem falschen Parametersatz auftreten. Um dieses Problem zu verringern, wird EMPFOHLEN, entweder nur solche Parametersätze zu überschreiben, die lange nicht verwendet wurden (um sicherzustellen, dass alle zugehörigen NALUs verarbeitet wurden), oder stattdessen einen neuen Parametersatz hinzuzufügen (was negative Folgen für die Effizienz der Videokodierung haben kann).

Informativer Hinweis: In einigen Topologien wie Topo-Video-switch-MCU [29] kann der Ursprung des gesamten Satzes von Parametersätzen von mehreren Quellen stammen, die nicht eindeutige Parametersatz-Identifier verwenden können. In diesem Fall kann ein Angebot einen vorhandenen Parametersatz überschreiben, wenn kein anderer Mechanismus existiert, der die Eindeutigkeit der Parametersätze im Out-of-Band-Kanal ermöglicht.

• In einer Mehrteilnehmersitzung MUSS ein Teilnehmer Parametersätze von verschiedenen Quellen, wann immer möglich, mit der Quellenidentifikation verknüpfen, z. B. durch Übermittlung out-of-band transportierter Parametersätze, da verschiedene Quellen typischerweise unabhängige Räume von Parametersatz-Identifier-Werten verwenden.

• Das Hinzufügen oder Ändern von Parametersätzen durch gleichzeitige Verwendung der Prinzipien B und C in derselben RTP-Sitzung kann aufgrund mangelnder Synchronisation zwischen Steuer- und RTP-Kanal zu Inkonsistenzen der Parametersätze führen. Daher DÜRFEN die Prinzipien B und C NICHT beide in derselben Sitzung verwendet werden, es sei denn, ausreichende Synchronisation kann bereitgestellt werden.

In einigen Szenarien (z. B. wenn nur die Teilmenge dieser Nutzlastformatspezifikation entsprechend H.241 verwendet wird) oder Topologien ist es nicht möglich, Out-of-Band-Übertragung von Parametersätzen einzusetzen. In diesem Fall müssen Parametersätze In-Band übertragen werden. Hier ist die Synchronisation mit den Nicht-Parametersatz-Daten im Bitstream implizit, aber die Möglichkeit eines Verlusts muss berücksichtigt werden.

Die Verlustwahrscheinlichkeit SOLLTE mit den oben diskutierten Mechanismen verringert werden. Wird ein Verlust eines Parametersatzes erkannt, kann die Wiederherstellung z. B. mit einer Decoder-Refresh-Point-Prozedur unter Verwendung von RTCP-Feedback Full Intra Request (FIR) [30] erreicht werden. Zwei Beispiele für Decoder-Refresh-Point-Prozeduren werden im informativen Abschnitt 8.5 bereitgestellt.

• Wenn Parametersätze zunächst mit Prinzip A bereitgestellt und später In-Band (Prinzip C) hinzugefügt oder aktualisiert werden, besteht ein Risiko im Zusammenhang mit der Aktualisierung der Out-of-Band gelieferten Parametersätze. Wenn Empfänger einige In-Band-Aktualisierungen verpassen (z. B. wegen Verlust oder spätem Einstieg), versuchen diese Empfänger, den Bitstream mit veralteten Parametern zu dekodieren. Daher wird EMPFOHLEN, Parametersatz-IDs zwischen Out-of-Band- und In-Band-Parametersätzen aufzuteilen.