12.5. Video Telephony or Streaming with FUs and Forward Error Correction (Videotelefonie oder Streaming mit FUs und FEC)

12.5. Video Telephony or Streaming with FUs and Forward Error Correction (Videotelefonie oder Streaming mit FUs und Vorwärtsfehlerkorrektur (Forward Error Correction, FEC))

Dieses Schema wurde implementiert und hat sich als leistungsfähig erwiesen, insbesondere bei höheren Paketverlustraten [19].

Das effizienteste Mittel gegen Paketverluste in Szenarien, in denen Retransmissionen nicht anwendbar sind, ist die Vorwärtsfehlerkorrektur (FEC). Obwohl die Anwendungsschicht-Ende-zu-Ende-Nutzung von FEC oft weniger effizient ist als ein FEC-basierter Schutz einzelner Links (insbesondere wenn Links unterschiedlicher Charakteristik im Übertragungspfad liegen), ist Anwendungsschicht-Ende-zu-Ende-FEC in einigen Szenarien unvermeidlich. RFC 5109 [18] bietet Mittel zur generischen Anwendungsschicht-Ende-zu-Ende-FEC in Paketverlustumgebungen. Ein binärer vorwärtsfehlerkorrigierender Code entsteht durch Anwendung der XOR-Operation auf die Bits an derselben Bitposition in verschiedenen Paketen. Der binäre Code kann durch die Parameter (n,k) spezifiziert werden, wobei k die Anzahl der in der Verbindung verwendeten Informationspakete und n die Gesamtzahl der für k Informationspakete erzeugten Pakete ist, d. h. es werden n-k Paritätspakete für k Informationspakete erzeugt.

Wenn ein Code mit den Parametern (n,k) im Rahmen von RFC 5109 verwendet wird, sind die folgenden Eigenschaften wohlbekannt:

a) Wird er über ein RTP-Paket angewendet, liefert RFC 5109 nur Paketwiederholung.

b) RFC 5109 ist bitrate-effizientester, wenn XOR-verbundene Pakete gleiche Länge haben.

c) Bei gleicher Paketverlustwahrscheinlichkeit p und festem k wird die Restfehlerwahrscheinlichkeit umso kleiner, je größer n ist. Beispielsweise beträgt bei einer Paketverlustwahrscheinlichkeit von 10 %, k=1 und n=2 die Restfehlerwahrscheinlichkeit etwa 1 %, während sie für n=3 etwa 0,1 % beträgt.

d) Bei gleicher Paketverlustwahrscheinlichkeit p und festem Codierungsrate k/n wird die Restfehlerwahrscheinlichkeit umso kleiner, je größer n ist. Beispielsweise beträgt bei einer Paketverlustwahrscheinlichkeit von p=10 %, k=1 und n=2 die Restfehlerrate etwa 1 %, während sie für einen erweiterten-Golay-Code mit k=12 und n=24 etwa 0,01 % beträgt.

Für die Anwendung von RFC 5109 in Kombination mit H.264-Baseline-codiertem Video ohne FUs (Fragmentation Units) können mehrere Optionen in Betracht gezogen werden:

1. Der Videoencoder erzeugt NAL-Units, für die jedes Videobild in einem einzelnen Slice codiert ist. Bei Anwendung von FEC könnte ein einfacher Code verwendet werden, z. B. (n=2, k=1). Das heißt, jede NAL-Unit würde im Wesentlichen nur wiederholt. Der Nachteil ist offensichtlich die schlechte Code-Leistung gemäß d) oben und die geringe Flexibilität, da nur (n, k=1)-Codes verwendet werden können.

2. Der Videoencoder erzeugt NAL-Units, für die jedes Videobild in einem oder mehreren aufeinanderfolgenden Slices codiert ist. Bei FEC könnte ein besserer Code, z. B. (n=24, k=12), über eine Folge von NAL-Units verwendet werden. Je nach Anzahl der RTP-Pakete pro Frame kann ein Verlust eine erhebliche Verzögerung verursachen, die sinkt, wenn mehr RTP-Pakete pro Frame verwendet werden. Pakete völlig unterschiedlicher Länge könnten ebenfalls verbunden werden, was die Bitrate-Effizienz gemäß b) oben verringert. Mit etwas Sorgfalt und für Slices von 1 kB oder größer kann jedoch ähnliche Länge (Unterschied 100-200 Byte) erzeugt werden, was die Biteffizienz nicht katastrophal senkt.

3. Der Videoencoder erzeugt NAL-Units, für die ein bestimmtes Frame k Slices von annähernd gleicher Länge enthält. Dann kann bei FEC ein besserer Code, z. B. (n=24, k=12), über die NAL-Unit-Folge pro Frame verwendet werden. Die Verzögerung gegenüber 2) oben kann sinken, aber mehrere Nachteile sind offensichtlich. Erstens sinkt die Codierungseffizienz des codierten Videos erheblich, da slice-strukturierte Codierung Intra-Frame-Prädiktion verringert und zusätzlicher Slice-Overhead nötig ist. Zweitens ist vorcodierte Inhalte oder Video beim Betrieb über ein Gateway üblicherweise nicht so mit k Slices codiert, dass FEC anwendbar ist. Schließlich ist die Codierung von Video mit k gleich langen Slices nicht geradlinig und kann mehr als einen Codierungsdurchlauf erfordern.

Viele der genannten Nachteile lassen sich vermeiden, indem FUs in Kombination mit FEC angewendet werden. Jede NAL-Unit kann in eine beliebige Anzahl von FUs im Wesentlichen gleicher Länge aufgeteilt werden; daher kann FEC mit vernünftigem k und n angewendet werden, selbst wenn der Encoder keinen Aufwand betrieben hat, gleich lange Slices zu erzeugen. Beispielsweise kann eine codierte Slice-NAL-Unit, die ein ganzes Frame enthält, in k FUs aufgeteilt werden, und ein Parity-Check-Code (n=k+1, k) kann angewendet werden. Dies hat jedoch den Nachteil, dass, sofern nicht alle erzeugten Fragmente wiederhergestellt werden können, der ganze Slice verloren geht. Es geht also ein größerer Bereich verloren als wenn das Frame in mehrere Slices aufgeteilt worden wäre.

Das vorgestellte Verfahren ermöglicht gute Übertragungsfehlertoleranz, auch wenn keine zusätzliche Redundanz auf Quellcodierungsebene (wie periodische Intra-Frames) vorhanden ist. Folglich kann dieselbe codierte Videosequenz genutzt werden, um maximale Kompressionseffizienz und Qualität bei fehlerfreier Übertragung und bei Übertragung über fehleranfällige Netze zu erreichen. Darüber hinaus erlaubt das Verfahren die Anwendung von FEC auf vorcodierte Sequenzen ohne Verzögerungszusatz. In diesem Fall können vorcodierte Sequenzen, die nicht für fehleranfällige Netze codiert sind, dennoch fast zuverlässig übertragen werden, ohne umfangreiche Verzögerungen. Zusätzlich führen gleich lange FUs zu einer bitrate-effizienten Nutzung von RFC 5109.

Hängt die Fehlerwahrscheinlichkeit von der Länge des übertragenen Pakets ab (z. B. bei mobiler Übertragung [15]), sind die Vorteile der Anwendung von FUs mit FEC noch offensichtlicher. Im Wesentlichen erlaubt die Flexibilität der FU-Größe, für jede NAL-Unit angemessene FEC anzuwenden und ungleiche Fehlerabsicherung von NAL-Units.

Bei Verwendung von FUs und FEC ist der entstehende Overhead erheblich, liegt aber in derselben Größenordnung wie die Anzahl Bits, die für intra-codierte Makroblöcke aufgewendet werden müsste, wenn keine FEC angewendet wird. In [19] wurde gezeigt, dass die Gesamtleistung des FEC-basierten Ansatzes die Qualität bei gleicher Fehlerrate und gleicher Gesamtbitrate einschließlich Overhead verbesserte.