Zum Hauptinhalt springen

5.8. Fragmentation Units (FUs) (Fragmentierungseinheiten)

5.8. Fragmentation Units (FUs) (Fragmentierungseinheiten)

Dieser Nutzlasttyp erlaubt es, eine NAL unit in mehrere RTP-Pakete zu zerlegen. Das auf der Anwendungsschicht zu tun statt auf untere Schichten (z. B. IP) zu vertrauen, hat folgende Vorteile:

  • Das Nutzlastformat kann NAL units größer als 64 kByte über ein IPv4-Netz transportieren, wie sie in voraufgezeichneter Video, insbesondere in HD-Formaten, vorkommen können (es gibt eine Grenze der Anzahl von Slices pro Bild, was eine Grenze der NAL units pro Bild bedingt und sehr große NAL units erzeugen kann).
  • Der Fragmentierungsmechanismus erlaubt die Zerlegung einer einzelnen NAL unit und die Anwendung generischer Vorwärtsfehlerkorrektur wie in Abschnitt 12.5 beschrieben.

Fragmentierung ist nur für eine einzelne NAL unit definiert, nicht für Aggregationspakete. Ein Fragment einer NAL unit besteht aus einer ganzzahligen Anzahl aufeinanderfolgender Oktette dieser NAL unit. Jedes Oktett der NAL unit MUSS Teil von genau einem Fragment dieser NAL unit sein. Fragmente derselben NAL unit MÜSSEN in aufeinanderfolgender Reihenfolge mit aufsteigenden RTP-Sequenznummern gesendet werden (ohne andere RTP-Pakete im selben RTP-Paketstrom zwischen erstem und letztem Fragment). Entsprechend MUSS eine NAL unit in RTP-Sequenznummern-Reihenfolge wieder zusammengesetzt werden.

Wird eine NAL unit fragmentiert und in Fragmentierungseinheiten (FUs) übertragen, spricht man von einer fragmentierten NAL unit. STAPs und MTAPs DÜRFEN NICHT fragmentiert werden. FUs DÜRFEN NICHT verschachtelt sein; eine FU DARF keine andere FU enthalten.

Der RTP-Zeitstempel eines RTP-Pakets, das eine FU trägt, wird auf den NALU-time der fragmentierten NAL unit gesetzt.

Abbildung 14 zeigt das RTP-Nutzlastformat für FU-A. Eine FU-A besteht aus einem einoktettigen Fragmentierungseinheiten-Indikator, einem einoktettigen Fragmentierungseinheiten-Header und einer Fragmentierungseinheiten-Nutzlast.

 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 14. RTP-Nutzlastformat für FU-A

Abbildung 15 zeigt das RTP-Nutzlastformat für FU-B. Eine FU-B besteht aus einem einoktettigen Fragmentierungseinheiten-Indikator, einem einoktettigen Fragmentierungseinheiten-Header, einer Decoding Order Number (DON) (in Netzwerk-Byte-Reihenfolge) und einer Fragmentierungseinheiten-Nutzlast. Mit anderen Worten: Die Struktur von FU-B ist dieselbe wie die von FU-A, außer dem zusätzlichen DON-Feld.

 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | DON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 15. RTP-Nutzlastformat für FU-B

Der NAL-unit-Typ FU-B MUSS im Interleaved-Paketisierungsmodus für die erste Fragmentierungseinheit einer fragmentierten NAL unit verwendet werden. Der NAL-unit-Typ FU-B DARF in keinem anderen Fall verwendet werden. Mit anderen Worten: Im Interleaved-Modus hat jede fragmentierte NALU eine FU-B als erstes Fragment, gefolgt von einem oder mehreren FU-A-Fragmenten.

Das FU-Indikator-Oktett hat folgendes Format:

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

Werte gleich 28 und 29 im Typ-Feld des FU-Indikator-Oktetts kennzeichnen FU-A bzw. FU-B. Die Verwendung des F-Bits ist in Abschnitt 5.3 beschrieben. Der Wert des NRI-Feldes MUSS gemäß dem NRI-Feld der fragmentierten NAL unit gesetzt werden.

Der FU-Header hat folgendes Format:

   +---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+

S: 1 Bit

Ist es auf eins gesetzt, zeigt das Start-Bit den Beginn einer fragmentierten NAL unit an. Ist die folgende FU-Nutzlast nicht der Beginn der Nutzlast einer fragmentierten NAL unit, ist das Start-Bit null.

E: 1 Bit

Ist es auf eins gesetzt, zeigt das End-Bit das Ende einer fragmentierten NAL unit an, d. h. das letzte Byte der Nutzlast ist auch das letzte Byte der fragmentierten NAL unit. Ist die folgende FU-Nutzlast nicht das letzte Fragment einer fragmentierten NAL unit, ist das End-Bit null.

R: 1 Bit

Das reservierte Bit MUSS 0 sein und vom Empfänger IGNORIERT werden.

Type: 5 Bits

Der NAL-unit-Nutzlasttyp wie in Tabelle 7-1 von [1] definiert.

Der Wert von DON in FU-Bs wird wie in Abschnitt 5.5 gewählt.

Hinweis (informativ): Das DON-Feld in FU-Bs erlaubt es Gateways, NAL units in FU-Bs zu fragmentieren, ohne eingehende NAL units in die NAL-unit-Dekodierreihenfolge zu bringen.

Eine fragmentierte NAL unit DARF NICHT in einer einzigen FU übertragen werden; Start- und End-Bit DÜRFEN NICHT beide im selben FU-Header auf eins gesetzt sein.

Die FU-Nutzlast besteht aus Fragmenten der Nutzlast der fragmentierten NAL unit, sodass bei sequentiellem Aneinanderhängen der FU-Nutzlasten aufeinanderfolgender FUs die Nutzlast der fragmentierten NAL unit rekonstruiert werden kann. Das NAL-unit-Typ-Oktett der fragmentierten NAL unit ist nicht als solches in der Fragmentierungseinheiten-Nutzlast enthalten; vielmehr werden die Informationen des NAL-unit-Typ-Oktetts in den F- und NRI-Feldern des FU-Indikator-Oktetts und im Typ-Feld des FU-Headers übermittelt. Eine FU-Nutzlast KANN eine beliebige Anzahl von Oktetten haben und KANN leer sein.

Hinweis (informativ): Leere FUs sind erlaubt, um die Latenz einer bestimmten Klasse von Sendern in nahezu verlustfreien Umgebungen zu verringern. Diese Sender zeichnen sich dadurch aus, dass sie NALU-Fragmente paketisieren, bevor die NALU vollständig erzeugt und damit die NALU-Größe bekannt ist. Wären NALU-Fragmente der Länge null nicht erlaubt, müsste der Sender mindestens ein Bit des folgenden Fragments erzeugen, bevor das aktuelle Fragment gesendet werden könnte. Aufgrund von H.264-Eigenschaften, bei denen manchmal mehrere Makroblöcke null Bits belegen, ist das unerwünscht und kann Verzögerung hinzufügen. Die (mögliche) Verwendung von NALU-Fragmenten der Länge null sollte jedoch gegen das erhöhte Risiko abgewogen werden, mindestens einen Teil der NALU wegen der zusätzlichen Pakete für die Übertragung zu verlieren.

Geht eine Fragmentierungseinheit verloren, SOLLTE der Empfänger alle folgenden Fragmentierungseinheiten in Sendereihenfolge verwerfen, die zur selben fragmentierten NAL unit gehören.

Ein Empfänger in einem Endpunkt oder in einem MANE DARF die ersten n-1 Fragmente einer NAL unit zu einer (unvollständigen) NAL unit zusammenfassen, auch wenn Fragment n dieser NAL unit nicht empfangen wird. In diesem Fall MUSS das forbidden_zero_bit der NAL unit auf eins gesetzt werden, um eine Syntaxverletzung anzuzeigen.