Ende-zu-Ende Architekturen für die Übertragung von MPEG … · Übertragung von MPEG-4 Video...

25
Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Ende-zu-Ende Architekturen für die Übertragung von MPEG-4 Video Über das Internet Seminar: Datenkommunikation und Verteilte- Systeme Salaheddine Benyassine Matrikelnummer: 236577 Betreuung: Imed Bouazizi Lehrstuhl für Informatik IV, RWTH Aachen - 0 -

Transcript of Ende-zu-Ende Architekturen für die Übertragung von MPEG … · Übertragung von MPEG-4 Video...

Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV

Prof. Dr. rer. nat. Otto Spaniol

Ende-zu-Ende Architekturen für die Übertragung von MPEG-4 Video Über

das Internet

Seminar: Datenkommunikation und Verteilte-Systeme

Salaheddine Benyassine

Matrikelnummer: 236577

Betreuung: Imed Bouazizi Lehrstuhl für Informatik IV, RWTH Aachen

- 0 -

Einleitung ....................................................................................................................... 2

1. Einführung in MPEG-4 ............................................................................................ 2

1.1. Objektorientiert ........................................................................................................ 2

1.2. Video Kodierung ...................................................................................................... 3

1.3. Ströme in MPEG-4 ................................................................................................... 4

2. Internet Protokolle .................................................................................................... 5

2.2. RTP- Realtime Transport Protocol ........................................................................... 5

2.3. RTCP- Realtime Control Protocol ........................................................................... 6

3. Eine Architektur für die Übertragung von MPEG-4 Video über das Internet ..... 7

3.1. Einführung ................................................................................................................... 7

3.2. RTP/RTCP Protokoll ................................................................................................... 10

3.3. Ende-zu-Ende Rückmeldungskontroll-Protokoll ......................................................... 11

3.4. Ratenkontrolle bei MPEG-4 Kodierung ...................................................................... 13

3.4.1 Frame-Ebene .................................................................................................. 14

3.4.2 Berechnung der Bitrate .................................................................................. 14

3.4.3 VO-Ebene ...................................................................................................... 15

3.4.4 Frame Skipping .............................................................................................. 15

3.5. Paketierung von MPEG-4 Daten ................................................................................. 14

3.6. Fehlerkontrolle ............................................................................................................. 17

3.6.1 Forward Error Correction (FEC) ................................................................... 18 3.6.2 Automatic Repeat Request ............................................................................ 19

4. Simulationsergebnisse .................................................................................................. 20

5. Zusammenfassung ......................................................................................................... 22

Referenzen und Literatur ................................................................................................. 23

- 1 -

Einleitung In den letzten Jahren hat das Internet im Multimediabereich ein sehr schnelle Entwicklung durchlaufen. Video-Übertragung über das Internet hat z.B. durch MPEG-4 aufgrund der Un-terstützung niedriger Bandbreiten sogar bis 9,6Kbit/s entscheidend an Bedeutung gewonnen. Ein Problem hierbei besteht jedoch durch die unterschiedliche Übertragungsgeschwindigkeit und die damit verbundenen Qualität der Informationen. Video-Applikationen haben typischerweise Verzögerungen und Schwankungen (Jitter), was viele Realtime-Anwendungen unbrauchbar machen kann. Es muss also ein System entwickelt werden, das diese Problem anspricht und eine gute Qualität sicherstellt. In dieser Seminarar-beit wird ein Beispiel für ein solches System, eine Ende-zu-Ende Architektur für die Übertra-gung MPEG-4 über das Internet vorgestellt, die eine gute Qualität verspricht durch die effi-ziente Nutzung der maximal verfügbaren Netzbandbreite. Zunächst wird jedoch eine kurze Übersicht über die Standard MPEG-4 gegeben und die für unser Thema relevanten Internet-protokolle RTP/RTCP erläutert. Danach werden wir in die eigentliche Thematik des Seminars einsteigen und die Ende-zu-Ende Architektur für die MPEG-4-Übertragung übers Internet darstellen. 1. Einführung in MPEG-4 MPEG-4 ist ein durch die Moving Picture Coding Experts Group entwickelter Standard zur Kodierung von audio-visuellen Daten. Im Vergleich zu seinen Vorgängern, MPEG-1 und MPEG-2, bietet MPEG-4 effizientere Algorithmen zur Kompression und neue Techniken wie die modellbasierte Bildkodierung. Durch Betrachtung einzelner Objekte anstatt des gesamten Bildes werden bei dem Kodierverfahren sehr viel bessere Ergebnisse erzielt. Die wichtigste Neuerung von MPEG-4 ist aber die Flexibilität. So werden oft nicht konkrete Implementie-rungen standardisiert sondern nur ein Interface. Die Implementierung bleibt dem Autor über-lassen. 1.1. Objektorientiert Ein zentraler Punkt in der Entwicklung von MPEG-4 ist die Objektorientiertheit. So steht z.B. in MPEG-4 nicht mehr das Bild als Pixelmatrix, sondern das Objekt in Mittelpunkt. Eine MPEG-4 Szene besteht aus audiovisuellen Objekten (AVO), die individuell kodiert werden, um eine maximale Effizienz zu erreichen. Sie können unabhängig von anderen AVOs oder von der Hintergrundinformation repräsentiert werden. Ein AVO besteht aus einem oder meh-reren Videoobjekten und/oder Audioobjekten.

- 2 -

Abb. 1.1: Beispiel einer audiovisuellen Szene in MPEG-4. 1.2. Video Kodierung Wie im letzten Abschnitt angesprochen, besteht eine Szene aus mehreren Objekten. Wenn man sich einen Nachrichtensprecher denkt, könnte man sich vorstellen, dass diese Szene aus Sprecher und Hintergrundbild besteht. Dafür gibt es verschiedene Kodierverfahren für die einzelne Objekte.

(a) (b) Abb. 1.2.1: (a)Der Hintergrund und (b) der Sprecher Als Videoobjekte. Üblicherweise wird sich der Hintergrund nie ändern. Der Sprecher wird sich, wenn auch nicht viel, bewegen. Die beiden Objekte werden einzelnen kodiert. Bevor ein Video in einem Computernetzwerk übertragen werden kann, muss es digitalisiert und komprimiert werden. Die Kompression der Videodaten läuft bitweise ab. Dabei kann ein Einzelbild auf verschiedene Weise kodiert werden:

• als I-Frame (Intra Coded Frame) • als P-Frame (Prediction Coded Frame)

- 3 -

• als B-Frame (Bidirectionally Prediction Coded frame) Die I-Frames werden wie ein Standbild kodiert mittels JPEG-Komprimierung. Bei den P- und B-Frames macht man sich zunutze, dass viele Informationen redundant sind, wenn man eine Kette von ähnlichen Bilder kodieren will. So ist es bei dem oben aufgeführten Beispiel, bei dem sich nur der Sprecher bewegt und der Hintergrund unverändert bleibt. Die gesamten nachfolgenden Bilder müssen nur auf ihre Vorgänger verweisen. Oder wenn die Kamera sich über eine unbewegliche Landschaft bewegt, dann muss nur angegeben werden, in welcher Richtung und wie weit sich ein Bildausschnitt bewegt hat, um das nächste Bild darzustellen. Abgespeichert werden nicht mehr die ganzen Bildflächen, sondern nur noch Vektoren, die angeben, wohin sich ein Bildausschnitt (ein sog. Makroblock von 16*16 Pixeln) bewegt hat. Der Unterschied zwischen P- und B-frames besteht darin, dass sich die ersteren nur die Unterschiede zu vorher angezeigten Bildern berechnet werden, während bei B-Frames der Bezug in beide Richtungen stattfinden kann.

Abb. 1.2.2: Arten der Einzelbilder in MPEG. I-, B- und P-Frame. 1.3. Ströme in MPEG-4 Bevor die Daten über ein Netzwerk gehen, werden sie zu einem großen Stream zusammenge-fasst (Multiplex). Auf der Empfängerseite wird dieser Stream wieder in einzelne Streams zer-legt (Demultiplex). Anhand von Zeitstempeln werden die einzelne Ströme in der richtigen Reihenfolge wieder abgespielt werden. Da MPEG-4 Daten in mehrere Objekte unterteilt sind, betreffen die Stromeigenschaften das Multiplexing, das Demultiplexing und die Synchronisation mehrfacher Ströme.

- 4 -

Die AVO-Daten werden zu einem oder zu mehreren elementaren Strömen (Elementary Streams) gebündelt. Diese sind durch die Dienstgüte (Quality of Service QoS) charakterisiert. Die Elementary Streams werden dann in einem Multiplexverfahren zu einem Stream gebün-delt. Auf der Decoderseite wird dieser Stream dann durch Demultiplexer wieder zerlegt. 2. Internet Protokolle Um ein Video über das Netz betreiben zu können, genügt es in der Regel nicht, eine Netzver-bindung aufzubauen und die Daten ohne weitere Maßnahmen darüber zu verschicken. Zum Transport muss der Datenstrom in Pakete aufgeteilt werden, die getrennt verschickt wer-den. An die Empfängerseite müssen diese Pakete in der richtigen Reihenfolge zusammenge-setzt werden. Zudem müssen Empfänger sich während der Übertragung an variable Dienst-qualitäten (QoS) anpassen können. Es werden dafür üblicherweise die RTP/RTCP benutzt. 2.2. RTP- Realtime Transport Protocol Das Real-Time Transport Protocol (RTP) [1] wurde als Internet-Protokoll für Echtzeit-Über-tragungen über das User Datagram Protocol (UDP) und IP-Multicast entwickelt. Die Haupt-einsatzbereiche von RTP sind Conferencing und Medienstreaming. Dabei reichen die Mög-lichkeiten von einfachen Unicast-Verbindungen für Audiostreaming bis hin zu Videokonfe-renzen über Multicast. Die vier wichtigen Felder im RTP-Header sind Nutzdatentyp, Sequenznummer, Zeitstempel und Quellenidentifizierung (siehe Abbildung 2.2).

Nutzdatentyp

Sequenznummer

Zeitstempel

ID der Synchro-nisationsquelle

Verschiedene Felder

Abb. 2.2:Die Felder des RTP-Headers. Die RTP-Header enthalten Informationen, die es dem Empfänger erlauben, den Medienstrom zu rekonstruieren, sowie Informationen wie der Codec den Medienstrom in Pakete gespalten hat. Für einen Videostrom wird der Nutzdatentyp benutzt, um den Typ der Videokodierung

- 5 -

(z.B. MPEG-4) anzugeben. Auch hier kann der Sender die Videokodierung während einer Sitzung ändern. Weitere wichtige Felder des RTP-Headers sind:

• Sequenznummer: In diesem 16 Bit langen Feld wird die Sequenznummer für jedes ge-sendete RTP-Paket um Eins erhöht. Es kann vom Empfänger benutzt werden, um ei-nen Paketverlust zu erkennen und die Paketsequenz wiederherzustellen.

• Zeitstempel: Dieses Feld ist 32 Bit lang und wird vom Empfänger benutzt, um die ver-schiedenen Verzugszeiten (Paket-Jitter) von Paketen innerhalb eines Medienstroms auszugleichen.

• ID der Synchronisationsquelle: Das Feld ist 32 Bit lang und identifiziert die Quelle des RTP-Stroms.

2.3. RTCP- Realtime control Protocol RTCP ist ein Kontrollprotokoll und arbeitet zusammen mit RTP. In einer RTP-Sitzung senden die Teilnehmer regelmäßig RTCP-Nachrichten, um Informationen über Dienstgüte (QoS) und ähnliches auszutauschen. Die Teilnehmer liefern dieses Feedback mittels RTCP-Reportpaketen, die per Multicast an alle Teilnehmer der Übertragung gesendet werden. Es gibt zwei Typen dieser Reports, abhängig davon, ob der Teilnehmer als Empfänger oder als Sender fungiert. Empfänger erstellen einen Receiver Report (RR), Sender verschicken einen Sender Report (SR). Hauptzweck von RTCP ist es also, den Teilnehmern laufend aktuelle Informationen über die Anzahl der gesendeten Pakete, die Anzahl der verlorenen Pakete und Netzwerk-Jitter zu ge-ben. Dieses Feedback ermöglicht den Teilnehmern, den von ihnen generierten Datenstrom an die Netzbedingungen anzupassen. Noch eine wichtige Aufgabe ist es, für jeden Teilnehmer eine eindeutige Kennzeichnung zu übertragen, die wird vom Empfänger benutzt, um mehrere Datenströme eines Teilnehmers, die in getrennten Sessions übertragen wurden, wieder zu-sammenzuführen.

- 6 -

3. Eine Architektur für die Übertragung von MPEG-4 Video über das Internet In den letzten Jahren gewinnt das Internet immer mehr an Bedeutung und aufgrund der Flexi-bilität von MPEG-4 Video ist die Übertragung von MPEG-4 übers Internet eine wichtige Komponente von vielen Multimedia-Anwendungen geworden. Video-Anwendungen reagieren sehr empfindlich auf Ende-zu-Ende-Verzögerung und Verzö-gerungsschwankungen (Jitter). Weiterhin variieren die Verkehrlastbedingungen über dem Internet drastisch je nach Zeit. Im Folgenden werden wir eine Ende-zu-Ende Architektur für die Übertragung des MPEG-4 Videos über IP Netzen vorstellen. Das Ziel dieser Architektur ist es, sich veränderlichen Netzbedingungen anzupassen sowie ein effizientes Ausnutzen der Netzressourcen, um eine gute Qualität des übertragenen Videos zu erreichen. 3.1. Einführung

Abb. 3.1.1: Ende-zu-Ende Architektur für die Übertragung von MPEG-4

Die Abbildung 3.1.1 zeigt die Architektur für die Übertragung des MPEG-4 Videos über dem Internet an. Auf der Absenderseite wird das Video von einem adaptive MPEG-4 Codierer kodiert. Danach wird der kodierte Videostrom auf die Synchronisationsebene als Pakete ge-stellt, und dann geht vor dem Eintritt ins Internet durch die RTP/UDP/IP Ebenen. Pakete gel-ten als verloren durch Stauung an Router/Schalter(Switch) oder am Zielort durch große Ver-zugsverzögerung. Für Pakete, die erfolgreich übertragen wurden, gehen sie zuerst durch die RTP/UDP/IP Ebenen in umgekehrte Richtung, bevor sie am MPEG-4 Decoder dekodiert werden. Auf der Empfängerseite dieser Architektur steht ein Dienstgüte(QoS)-Monitor, um Informationen über das Netzverhalten zu erhalten, etwa die Paketverluste, Stauungen und Verzögerungen. Diese Informationen werden beim Rückmeldungsprotokoll verwendet, das der Quelle zurückgeschickt wird. Auf Grundlage von solcher Rückmeldungsinformation

- 7 -

schätzt der Absender die verfügbare Bandbreite und kontrolliert die Datenrate des MPEG-4 Codierers.

Abb. 3.1.2: Protokollebenen für die Übertragung des MPEG-4 Videos.

Der rechte Hälfte der Abbildung 3.1.2 zeigt die Strecke, die ein MPEG-4 Video zurücklegen muss in einem Endsystem. An der sendenden Seite komprimiert die Kompressionsebene die visuelle Information und generiert die Daten-Grundströme (ESs) (elementary streams ), die die codierte Darstellung der visuellen Objekte (VOss) enthält. Die ESs sind packetisiert als SL-packetized Ströme an der synchronen Ebene. Die SL-packetized Datenströme liefern Zeit- und Synchronisationsinformationen. Die SL-packetized Datenströme sind gemultiplext in einen FlexMux Datenstrom an der TransMux Ebene, die dann zu den aus RTP, UDP und IP zusammengesetzten Transportprotokolle übermittelt wird. Die entstehenden IP-Pakete werden dann übers Internet übertragen. An der Empfängerseite ist der Videostrom auf die umgekehrte Art verarbeitet. Die linke Hälfte der Abbildung 3.1.2 zeigt das Datenformat jeder Ebene an.

- 8 -

Abb. 3.1.3: Die Struktur des MPEG-4 Viedeocodierers. Die Abbildung 3.1.3 zeigt die Struktur des MPEG-4 Videocodierers an. Der Video Daten-strom wird zuerst in Videoobjekte (VOs) zerlegt, dann von einzelnen VO-Codierer kodiert. Die kodierten VO-Ströme werden als erstes packetisiert dann werden sie gemultiplext bei der Strom-Multiplexschnittstelle (Stream multiplex Interface). Der entstehende FlexMux -Datenstrom wird zu RTP/UDP/IP Modul weitergeleitet.

Abb. 3.1.4: Die Struktur des MPEG-4 Videodecoders. Die Struktur des MPEG-4 Videodecoders wird in Abbildung 3.1.4 gezeigt. Pakete von RTP/UDP/IP werden zur Strom-Demultiplexschnittstelle (Stream demultiplex interface) und FlexMux-Puffer übertragen. Die Pakete sind demultiplexed und werden in den entsprechen-den Decodierungspuffer befördert. Die Fehlerkomponente (Error Concealment) kopiert das vorherige Videoobjekt, wenn Paketverlust Wahrgenommen wird. Die Videoobjekt-Decoder dekodieren die Daten in den Decodierungspuffer und erzeugt zusammengesetzter Einheiten (CUs) (composition units), die zu den Kompositionsspeicher (Composition Memory) gelan-gen, von dort werden sie dann vom Compositor geholt.

- 9 -

3.2. RTP/RTCP Protokoll Das zuverlässige TCP-Protokoll, das den Bytestrom fehlerfrei vom Sender zum Empfänger überträgt, ist nicht geeignet für MPEG-4. Im Falle eines Paktverlustes werden die fehlerhaften Pakete erneut übertragen, woraus große Verzögerungen entstehen würden, was für eine Vi-deoübertragung inakzeptabel ist. Video-Anwendungen reagieren immer sehr empfindlich auf Ende-zu-Ende-Verzögerung, sie können aber gelegentlichen Datenverlust tolerieren. Es wird daher für unser Architektur das UDP-Protokoll als Transportprotokoll eingesetzt, um eine schnelle Übertragung vom MPEG-4 Datenströme zu erzielen. Das UDP-Protokoll ist ein un-zuverlässiges Protokoll und gibt keine Garantie dafür, dass die Datenströme bei dem Empfän-ger ankommen. Daher muss sich der Empfänger auf die Protokolle RTP/RTCP verlassen kön-nen, um die Paketverluste zu erkennen. RTP ist ein Internet Standardprotokoll, das dafür ent-worfen ist, Ende-zu-Ende Übertragungsfunktionen für Echtzeitanwendungen zu liefern. RTCP ist ein RTP-Begleiterprotokoll. RTCP schickt den Teilnehmern einer RTP-Sitzung QoS-Rückmeldung zu. Die Abbildung 3.2.1 zeigt die Implementierungsarchitektur für RTP/UDP/IP-Ebenen an. Die-ses Model ist eine Schlüsselkomponente der Realisierung des Rückmeldungsprotokolls (rate-based feedback control protocol) und des Fehlerkontrollprotokolls (error control). Vom sen-denden Teil generiert der MPEG-4-Codierer einen packetized Datenstrom (FlexMux stream), der als RTP-Paket zum Übertragen zur Verfügung steht. Andererseits werden die Informatio-nen aus dem Rückmeldungsprotokoll (Feedback Control Protocol) auf den RTCP-Generator übertragen. Die entstehenden RTCP- und RTP-Pakete werden an die UDP/IP-Ebene weiterge-leitet für die Internetübertragung. Auf dem Empfängerteil werden die erhaltenen IP-Pakete zunächst an der UDP/IP-Ebene aufgeteilt (un-packed), sodann von Filter und Dispatcher zur RTP/RTCP-Analysatoren gesendet, die RTP-Pakete werden dann von dem RTP-Analysator eingepackt und platziert in einem Puffer (Buffer und Loss Detector), um mögliche Paket-Verluste festzustellen. Wenn ein Paketverlust stattgefunden hat, wird eine Meldung an die Fehlerkontrolle (Error Concealment) gesandt. Der RTCP-Analysator analysiert die RTCP-Pakete und sendet eine Rückmeldung an die Rückmeldungssteuerungskomponente (Feedback Control Protokol).

- 10 -

Abb. 3.2.1: Architektur von den RTP/UDP/IP Ebenen. 3.3. Ende-zu-Ende Rückmeldungskontroll-Protokoll Einerseits reagieren Video-Anwendungen sehr empfindlich auf Ende-zu-Ende-Verzögerugen und Verzögerungsschwankungen, anderseits unterstützt das Internet normalerweise nicht jeg-liche Bandbreitenreservierungsmechanismen (z.B RSVP) oder andere, die Dienstgüte (QoS) garantieren. Weiterhin ist die verfügbare Bandbreite nicht immer bekannt, sondern variiert auch mit der Zeit. Deshalb muss ein Mechanismus vorort sein, damit die MPEG-4-Videoquelle die Netzbedingungen wahrnimmt, sodass er das Video mit einer entsprechenden Ausstoßrate (output rate) kodieren kann. Würden die Stauungshinweise (congestion indication) und die Rückmeldung (feedback) di-rekt am Punkt der Netzstauung durchgeführt werden, also genau am switch/router, könnte man leistungsfähige Ratenberechnungsalgorithmen (rate-calculation algorithms) direkt am switch gestalten und damit eine genaue verfügbare Bandbreiteninformation an die Quelle ü-bermitteln. Leider nehmen die IP-switch/router jedoch nicht aktiv an der Rückmeldungssteue-

- 11 -

rung teil. Im folgenden werden wir einen Entwurf des Rückmeldungsalgorithmus darstellen, der einzig auf den Endsystemen (Sender/Empfänger) basiert, ohne zusätzliche Erfordernisse an die IP-switch/router zu stellen. Wir lassen einfach die MPEG-4 Videoquelle (video source) nach und nach ihre Transferrate steigern, um verfügbare Netzbandbreite zu untersuchen. Durch diese Steigerung wird die Quellenrate die verfügbare Netzbandbreite erreichen und gleich danach überschreiten. Dann wird die Datenrate in die Stauungsregion fallen. Die Stauung (congestion) wird vom Empfän-ger durch Paketverluste und Verzögerung wahrgenommen, daraufhin schickt der Empfänger mittels RTCP-Pakete eine Rückmeldung an die Quelle. Sobald der Sender diese Information erhält, reduziert er seine Transferrate. Rückmeldungssteuerung-Algorithmus: Der Sender schickt periodisch ein RTCP-Kontrollpaket für jedes RTP-Paket Ns. Der Empfän-ger sendet seinerseits beim Erhalt von Nr Pakete oder wenigstens einmal alle 5 Sekunden eine RTCP-Rückmeldung an den Sender. Dieses Rückmeldungspaket enthält einen Hinweis auf den Paketverlust (packet loss ratio) Ploss, den der Empfänger wahrgenommen hat in der Zeit, wo die Nr-Pakete gesendet werden seit dem letzten RTCP-Rückmeldungspaket. Im Folgenden wird der Algorithmus vorgestellt. IR sei dabei die Anfangsrate (initial rate), MR die Minimalrate (minimum rate) und PR die Höchstrate (peak rate). AIR ist die Additive-Zunahmerate (additive increase rate), α ist der multiplikative Abnahmefaktor (multiplicative decrease factor) und Pthreshold ist die Schwelle an der der Paketverlust wahrgenommen wird: Senderverhalten

• Der Sender fängt die Übertragung mit einer Ausstoßrate (output rate) von r := IR, die größer/gleich seiner Minimalrate MR ist. Jedes RTP-Paket enthält eine Paketsequenz-nummer. • Für jedes sendende RTP-Paket schickt der Sender eine RTCP-Kontrollpaket. • Bei dem Erhalt eines RTCP-Rückmeldungspaketes mit Ploss vom Empfänger stellt sich

der Sender auf die folgenden Regel ein und ändert entsprechend seine Ausstoßrate: if ( Ploss ≤ Pthreshold ) r: = min{(r + AIR), PR}; else r: = max{(α × r), MR}.

- 12 -

Empfängerverhalten

• Der Empfänger verwaltet die Sequenznummer des RTP-Headers der angekommenen Pakete, um Paketverluste zu erkennen.

• Der Empfänger sendet bei Erhalt Nr Pakete oder alle 5 Sekunden RTCP-

Rückmeldungspakete an den Sender. Diese Pakete enthalten das wahrgenommene Ploss

in diesem Zeitintervall.

Der Algorithmus stellt während der Übertragung die Ausstoßrate des MPEG-4-Codierers ein, um den Paketverlust Ploss unter der Schwelle Pthreshold zu halten. 3.4. Ratenkontrolle bei MPEG-4 Kodierung Der im letzten Abschnitt beschriebene Rückmeldungssteuerungs-Algorithmus arbeitet mit dem Codierer, um die Zielrate zu ändern. Es muss also ein MPEG-4-Kodierung-Algorithmus entwickelt werden, sodass die Ausstoßrate des Codierers zur geschätzten Rate des im letzten Abschnitt vorgestellten Rückmeldungsprotokolls passt. Das Ziel der Ratenkontrolle ist es, eine maximale Qualität aus der vorhandene Bitrate zu erreichen. Video-Codierer wie H.261 und MPEG-1/2 ändern normalerweise die Quantisierungsparame-ter des Codierers, um Ratenadaption zu erreichen. Diese Kodierungsschemen führen die Ko-dierung mit konstanter Framerate durch ohne Berücksichtigung der Tatsache, dass innerhalb eines frames unterschiedliche Videoobjekte VO unterschiedliche Bitrates zum kodieren brau-chen. Unter dieser Kodierung führt sogar eine kleine Reduktion der Framerate zur Ver-schlechterung der Qualität in der Empfängerseite, insbesondere während einer dynamischen Szenenänderung. Das MPEG-4-Video-Codierer klassifiziert jedes Videoobjekt in einem VOP (visual object plane) und kodiert jeden VOP unabhängig von den andern VOPs. Solche Kodierung liefert eine große Flexibilität, um adaptive Kodierung auszuführen. Zusätzlich zur Veränderung der Quantisierungsparameter auf jedem VOP kann die Bitrate-Verteilung auf Videoobjekte dy-namisch eingestellt werden. Bei der Kodierung von Bildsequenzen greift man immer häufiger auf Verfahren der Rate-Distortion (RD) Optimierung zurück, um die Kodierungsmodi einzelner Bildbereiche zu bestimmen. Bei unserem Ratenkontroll-Schema betrachten wir drei Ebenen der Bildkodie-rung, und zwar die Frame-Ebene, die VO-Ebene und die MB-Ebene.

- 13 -

3.4.1 Frame-Ebene Für ein Frame i können wir das Auswerten des Bitrates wie folgt formulieren: Bi – Hi = a1 × Qi

-1 + a2 × Qi-2

Wobei

• Bi die Gesamtzahl von Bits darstellt, die für das Kodieren des aktuellen Frames i verwendet werden.

• Qi die Quantisierung für den aktuellen Frame i. • Hi die Bits, die für den Header benutzt werden. • a1, a2 die erste- und zweite-order-Koeffizienten in dem Rate-Distortion-Model .

Wir können die Gesamtzahl von Bits eienes Frames i berechnen, wenn wir a1 und a2 kennen. Wichtig in dieser Formel ist die Tatsache, dass jede Erhöhung der Quantisierungsparameter eines Frames i eine Senkung der Anzahl der Bits bedeuten würde.

3.4.2 Berechnung der Bitrate

Wir nehmen an, dass in einer Videofolge die I-Frames zuerst kodiert werden und dann die P-Frames. In dieser Stufe kodiert der Codierer das erste I-Frame, dann können die übrigen ver-fügbaren Bits für das Kodieren der anschließenden P-Frame berechnet werden mit der folgen-den Formel: ßt = Γ × r – I wobei

• ßt die übrige verfügbare Bitzahl für das Kodieren der anschließenden P-Frame zur Ko-dierungszeit t.

• Γ die Dauer der Videofolge (in Sekunden) • r bitrate der Videofolge(in Bits pro Sekunde) • I die Anzahl für das erste I-frame verwendeten bits

Also ist die Ausstoßrate gleich ß0/N0, wobei N0 die Anzahl der P-Frames in der Videofolge oder in einem GOP (Group of Picture) ist. Die Standardgröße vom Puffer ist r × 0.5 ( 500 ms als maximale Verzug), es wird für die bes-sere Verwaltung des Puffers die Puffer-Fülle auf r × 0.25 gesetzt.

- 14 -

3.4.3 VO-Ebene Für das Kodieren in der VO-Ebene müssen wir die Komplexität der VO berücksichtigen, da jedes VO eine andere Kodierungskomplexität (z.B. langsame Bewegung oder schnelle Bewe-gung) hat. Ohne diese Berücksichtigung könnte es passieren, dass der VO-Hintergrund viele Bits unbenutzt lässt, während der VO-Vordergrund mehr Bits braucht. Wir benutzen hier eine neue Bitzuordnungsmethode für VOs, die fähig ist, die verfügbare Bitzahl für jedes VO in Bezug auf Inhaltskomplexität und Wichtigkeit zu gestalten.

3.4.4 Frame Skipping

Um den Puffer-Überlauf (buffer overflow) zu verhindern, verwenden wir die Frame-Skipping-Kontrolle. Wenn der Codierer merkt, dass die nächste Frame-Kodierung den Puffer zum Überlauf bringen würde, lässt er das Kodieren des nächsten Frames aus. Vor dem Kodieren des nächste Frames prüft der Codierer die aktuelle Puffer-Fülle (buffer-fullness) und das geschätzte Bit-rate des nächsten Frames. Wenn die aktuelle Puffer-Fülle und das geschätzte Bit-rate größer als ein vordefinierter Sicherheitsfaktor (safety margin z.B 80% der Puffergröße) ist, wird der nächste Frame ausgelassen. Die Frame-Skipping kann wie folgt formuliert werden: While ((BufferFullness + ActualBitCountsForLastFrame

− ChannelOutputRate × FrameTimeInterval) ≥ BufferSize × SkipMargin) { Skip the next frame; BufferFullness := BufferFullness − ChannelOutputRate × FrameTimeInterval. } In dem vorgeschlagenen Frame-Skipping verwenden wir die Bitzahl des letzten Frames. Wenn die Summe der aktuellen Puffer-Fülle (BufferFullness) und die Bitzahl des letzten Frames minus der Ausstoßrate (ChannelOutputRate) während eines Frame-Intervalls (Frame-TimeInterval) den Sicherheitsfaktor (safety margin) des Puffers übersteigt, lassen wir den letzten Frame aus. 3.5. Paketierung von MPEG-4 Daten Bevor der komprimierte Videostrom über die IP-Netze übertragen wird, muss er einem Pake-tierungsverfahren unterstellt werden. An der Senderseite werden die Videodaten komprimiert, dann wird der komprimierte Videostrom an der Synchronen-Ebene SL in Pakete aufgeteilt und mit Zeit- und Synchronisationsinformation versehen, bevor die Pakete in die TransMux-

- 15 -

Ebene weitergeleitet werden. Ein Paketierungsalgorithmus an der SL spielt eine große Rolle für die Robustheit und die Effizienz der Übertragung von MPEG-4 übers Internet. Es gibt in der Literatur drei Paketierungsschemen: Le Leammec und Guillemot [2] verwenden in ihren Verfahren eine feste Paketgröße für MPEG-4 Videostrom. Dieses Paketierungssche-ma ist sehr einfach, ein Makroblock MB wird in zwei Pakete geteilt. Das zweite Schema ist von Turletti und Huitema [3], die vorgeschlagen haben, einen Makroblock nicht zu teilen, so dass der Verlust eines Paketes nur den Verlust eines MB bedeutet und eine verbesserte Feh-lerkorrektur mit sich bringt. Deshalb wurde dieses Paketierungsschema von The Internet En-gineering Task Force (IETF) empfohlen. Das dritte Schema wurde von Zhu [4] vorgeschla-gen: Um die Effizienz zu erhöhen, wird ein GOB (Group of Block) als Paket verwendet. Die-ses Schema wurde auch von TETF empfohlen. Wir werden hier ein Paketierungsschema behandeln, das das visuelle Objekt Plane VOP-Merkmal von MPEG-4 nutzt, und wir zeigen einen Paketierungsalgorithmus an die SL (Syn-chronenebene), der sowohl Effizienz als auch Robustheit für die Internetübertragung anbietet. Eine Paketgröße kann nicht größer als die Maximum Transit Unit MTU (die maximal zulässi-ge Größe eines Netzwerkpaketes in Byte) sein, deshalb muss jedes größere Paket in kleinere IP-Pakete fragmentiert werden. Für MPEG-4 Video wird abgeraten, Daten zu paketieren, die Informationen über zwei VOPs enthalten. Der Verlust eines solchen Paketes bedeutet auch den Verlust beider VOPs. Daher wollen wir festlegen, dass die Paketgröße das Minimum von der aktuellen VOP-Größe und der MTU-Größe ist (die Standardgröße von MTU beträgt 576 Bytes). Wenn ein VOP zu groß ist für ein einzelnes Paket, dann muss es in mehrere Pakete aufgeteilt werden. Wir versuchen die Robustheit zu erreichen, indem wir die Abhängigkeit zwischen benachbarten Paketen reduzieren. Wenn die MPEG-4 Header-Information in jedes Paket ko-piert wird, kann solche Abhängigkeit entfernt werden. Wir beschreiben zuerst die Funktionen und Parameter, die bei dem Algorithmus verwendet werden:

1. BitCount ist ein Zähler, der die Anzahl von Bits für den aktuellen Paketierungsprozess liest.

2. MaxPL: Maximum payload length (in Bits) = (path MTU – 50 bytes) × 8. 3. VOP_start_code ist ein vordefinierter Code am Anfang eines VOPs oder in der Grenze

zwischen zwei benachbarten VOPs. Der Paketierungsalgorithmus: Der Algorithmus überprüft zuerst, ob komprimierte Daten für die Paketierung vorhanden sind. Dann wird überprüft, ob der gelesene VOP in ein Paket passt, das nicht größer ist als die MaxPL. Wenn dies der Fall ist, werden die gelesenen Daten für die Paketierung in die nächste Stufe überreicht. Wenn nicht, greift der Algorithmus an der MB-Ebene. Wenn der

- 16 -

VOP_start_code nicht gefunden wird und die Anzahl von den gelesenen Bits kleiner als MaxPL ist, dann sind wir an das Ende des Videostroms angelangt und die restlichen Daten werden noch paketiert. while (there is encoded data to be packetized) { search for next VOP_start_code and BitCount cunts the number of bits of the video stream; if [(next VOP_start_code is found) and (BitCount – length of VOP_start_code ≤ MaxPL)] { /* Packetize by VOP boundary */ packetize the bits before next VOP_start_code; } else if (BitCount – length of VOP_start_code > MaxPL) { /* Packetize by MBs. */ Packetize as many MBs as Possible without exceeding MaxPL and without crossing Into next VOP; } else { /* Next VOP_start_code is not found, i.e. ,end of video. */ Packetize the remaining data. } } Aufgrund der Tatsache, dass ein VOP größer als ein MB oder ein GOB ist, zeigt dieser Pake-tierung-Algorithmus mehr Effizienz als der von Turletti und Huitema und der von Zhu. Weiterhin beseitigt er die Abhängigkeit zwischen Paketen, was das Problem des Schemas von Le Leannec und Guillemot ist. 3.6. Fehlerkontrolle Bei der Übertragung MPEG-4-Datenströme wirken sich Paketverluste besonders negativ auf die Wiedergabequalität aus. Da die Redundanz der Daten auf ein Minimum reduziert wurde, sind die Reparaturmöglichkeiten des Empfängers stark begrenzt. Im folgenden werden Techniken vorgestellt, die es ermöglichen, solche Paketverluste zu be-heben und im Anschluss daran werden wir eine einfache Fehlerkontrolle für unsere Ende-zu-Ende Architektur darstellen. Stauungen in den Routern sind die Hauptursache von Paketverlusten im Internet. Weiterhin macht das Kodieren von Daten diese generell anfälliger gegen Fehler. Obwohl MPEG-4-Videostrom einen Verlust tolerieren kann, verschlechtert sich die Qualität des Videos am

- 17 -

Empfänger. Um diese Fehler auszugleichen und eine akzeptable Qualität zu gewährleisten, muss eine Fehlerkontrolle vor Ort sein. Neben der Möglichkeit des Error Concealment, dem Verbergen von Paketverlusten durch geschickte Interpolation auf Anwendungsebene, gibt es auch Techniken, die verlorenen Pake-te auf der Ebene des Transportprotokolls wiederherzustellen [5, 6]. Nachfolgend sollen einige Techniken kurz vorgestellt werden.

3.6.1 Forward Error Correction (FEC)

Das Konzept von Forward Error Correction (FEC) ist das Hinzufügen von Reparaturdaten in den Datenstrom. Diese kann der Empfänger zur Rekonstruktion verlorener Pakete nutzen, ohne weiteren Kontakt zum Sender aufnehmen zu müssen. Reparaturdaten werden Parities genannt und werden auf Basis der Datenpakete errechnet. In dem FEC-Schema überträgt der Sender k Datenpakete und fügt h zusätzliche Parity-Pakete hinzu. Das Verhältnis h/k ist dabei ein Maß für die hinzugefügte Redundanz. Solange das Netzwerk nicht mehr als h der (h + k) Pakete verliert, kann der Empfänger die ursprünglichen k Datenpakete wiederherstellen. Abbildung 3.6.1 verdeutlicht diese Funktionsweise an einem Beispiel für k = 3 und h = 2. In diesem Fall erzeugt der FEC Encoder zwei Parity-Pakete (P1, P2) für jeweils drei gesendete Datenpakete. Gehen ein Datenpaket (D3) und ein Parity-Paket (P1) verloren, so kann der Empfänger das fehlende Datenpaket (D3) mit Hilfe des verbliebe-nen Parity-Pakets (P2) rekonstruieren.

Abb. 3.6.1. Ein Beispiel zur Funktionsweise von FEC Zu den Stärken von FEC zählt, dass FEC keinen Rückkanal zum Sender benötigt, und im Fall von Multicast ein einzelnes Parity-Paket den Verlust unterschiedlicher Datenpakete bei ver-schiedenen Empfängern reparieren kann. Zu den Schwächen von FEC zählt vor allem der benötigte Bandbreitenoverhead [7], was eine Benutzung mit MPEG-4 aufgrund der sehr nied-rigen Bitraten-Video ausschließt.

- 18 -

3.6.2 Automatic Repeat Request Ein anderes Mittel zur Reparatur von Paketverlusten ist Automatic Repeat Request (ARQ). Darunter versteht man die Retransmission der verlorenen Pakete [8]. Ein Retransmission- Schema besteht aus drei Teilen:

• der Erkennung von Paketverlusten, die via Timeout oder durch die Erkennung von Lücken im Datenstrom erfolgen kann,

• einer Feedback-Strategie, wobei der Empfänger entweder jedes empfangene Paket bestätigt oder den Verlust von Paketen meldet, und

• einer Retransmission-Strategie, die festlegt, welche Daten im Verlustfall erneut übertragen werden.

Gegenüber FEC hat ARQ den Vorteil, dass im störungsfreien Betrieb jeglicher Overhead vermieden werden kann, da auf Feedback und Retransmission verzichtet werden kann, solan-ge keine Paketverluste auftreten. Dies bringt allerdings den Nachteil mit sich, dass die benö-tigte Bandbreite sprunghaft ansteigt, sobald Paketverluste auftreten. Wurden die Verluste durch eine Überlastung des Übertragungsweges verursacht, wird diese durch den zusätzlichen Verkehr durch Retransmission nur verstärkt. Die Verlustrate der Pakete steigt somit sogar noch an. Daher ist es bei starker Netzwerkauslastung sinnvoll, bei bestimmten Paketen auf eine Retransmission zu verzichten. Ein anderer Nachteil ist die relativ lange Zeit, die benötigt wird, um den Verlust eines Pakets zu erkennen, ein Wiederholungspaket anzufordern und dieses zu übertragen. Abhängig von der jeweilige Netzwerkumgebung führt dies in vielen Fällen zu Verzögerungen, die für Video-Anwendungen nicht mehr zu tolerieren sind. Deshalb benutzen wir für unser Schema auch keinen Retransmission. Andere Methoden, um Fehler und Verlust bei Datenübertragung zu behandeln, sind zum Bei-spiel Resynchronization, Data Recovery und Error Concealment.

• Resynchronization Wenn zwei oder mehrere Datenströme aufgrund von Fehlern nicht mehr synchron zueinander laufen, muss versucht werden, wieder einen neuen Übereinstimungspunkt der Ströme zu fin-den. Dazu werden in MPEG-4 Resynchronization Marks in den kodierten Datenstrom einge-fügt.

- 19 -

• Data Recovery Bei einem großen Verlust von aufeinanderfolgenden Daten wird das Reversible Variable Length Coding (RVLC) eingesetzt, um zumindest einen Teil der Daten wiederzugewinnen. Dabei wird in dem fehlerhaften Datenintervall zuerst vom Anfang her solange versucht zu dekodieren, bis auf den Fehler gestoßen wird. Dasselbe wird vom Ende her wiederholt, so dass das Fehlerintervall als Bündelfehler übrig bleibt.

• Error Concealment Der fehlerbehaftete Teil wird durch den entsprechenden Block des vorherigen Bild ersetzt. Auch durch die Trennung von Bewegungsdaten und Bilddaten kann (bei Verlust der Bildda-ten) durch die vorhandene Bewegungsinformation der Ablauf wiedergewonnen werden. Die meisten Methoden für die Fehlerkontrolle sind nur in drahtloser Umgebung anwendbar. Wir verwenden in unserer Architektur ein einfaches Schema für die Fehlerkontrolle, die Pa-ketverluste werden vom QoS-Monitor anhand der RTP-Paketssequenznummer an der Emp-fängerseite (siehe Abb. 3.1.1) wahrgenommen. In unserer Implementierung betrachten wir ein Paket dann als verloren, wenn die vier ihm folgenden Pakete angekommen sind (auch wenn das Paket in einen späteren Zeitpunkt ankommen würde). Wir wählen hier das vierte Paket als die Schwelle. Das Algorithmus für die Fehlerkontrolle besteht aus zwei Teilen: Wenn ein Paketverlust wahrgenommen wird, werden auf der Decoder-Seite die Daten vom vorherigen VOP wiederholt, um die verlorene Blöcke wiederherzustellen. Auf der Codierer-Seite kodiert der Codierer I-VOP periodisch, um die Fehlerfortpflanzung (error propagation) zu unterdrü-cken. 4. Simulationsergebnisse In diesem Abschnitt werden wir unsere vorgeschlagene Architektur und Algorithmen auf ei-nem Netzsimulator durchführen, um zu demonstrieren, dass diese Architektur und Algorith-men sehr wichtig sind für:

• die Übertragung von MPEG-4-Videoströmen über das Netz mit guter Qualität unter niedrigen Bitraten und veränderlichen Netzbedingungen,

• das effiziente Ausnutzen und Anpassen der verfügbaren Netzbandbreite.

- 20 -

Wir verwenden ein peer-to-peer Netzwerk (Abbildung 4.1) für die Simulation.

Abb. 4.1. peer-to-peer Netzwerk Wir zeigen die Leistung eines MPEG-4 Videos unter veränderlicher Netzbandbreite. In dieser Simulation aktivieren wir eine MPEG-4 unter der peer-to-peer-Konfiguration. Die Verbindungskapazität zwischen SW1 und SW2 variiert von 15 kbits/s bis 50 kbits/s in dem Zeitintervall von 0s bis 450s. Die Abbildung 4.2 zeigt die Netzbedingungsbandbreite (net-work link bandwidth) und das Verhalten der Quellen-Rate (source-rate). Die Quelle ist in der Lage, ihre Ausstoßrate einzustellen, um sich an die veränderliche Bandbreite anzupassen. Die Abbildung 4.3 zeigt die Verbindungsauslastung (link utilization) und den Paketverlust (packet loss ratio) während desselben Simulationslauf von Abbildung 4.2.

Abb. 4.2. Quellen-Rate und die verfügbare Netzbandbreite Der Sender erhöht die Rate, bis sie die verfügbare Bandbreite erreicht. Danach wird ein Pa-ketverlust am Empfänger wahrgenommen und eine Rückmeldung an den Sender übermittelt. Nach Erhalt dieser Information senkt der Sender die Rate. Trotz der Schwankungen ist die durchschnittliche Auslastung der Verbindung über 80%, was ein recht gutes Ergebnis für die Rückmeldungssteuerung in einem breiten Netzwerk ist (1000 km zwischen SW1 und SW2). Weiterhin beträgt die durchschnittliche Paketverlust-ratio nur 0.34%, was die Wirksamkeit des Rückmeldungssteuerungsalgorithmus demonstriert.

- 21 -

Abb. 4.3. Die Benutzung der verfügbare Netzbandbreite und Paketverlust Um die Qualität des MPEG-4 Videos zu prüfen, spielen wir die dekodierte Videofolge am Empfänger. Die Abbildung 4.4 zeigt ein Videoframe am Empfänger während der Zeitinterval-le [0s,s150s), [150s, 300s) und [300s, 450s], jede Abbildung zeigt die gleiche Szene an. Die Bildqualität ist unter allen diesen drei verschiedenen Bitraten recht gut.

(a) (b) (c)

Abb. 4.4. (a) Videoframe während [0s, 150s) (b) Videoframe während [150s, 300s) (c) Videoframe während [300s, 450s]

5. Zusammenfassung Um MPEG-4-Videos übers Internet zu übertragen und eine zufriedenstellende Bildqualität zu gewährleisten, müssen viele Hindernisse bewältigt werden. Die fehlende QoS Unterstützung, das Variieren der Bandbreite, Verzögerung und Verlust mit der Zeit bleiben die großen Prob-leme bei MPEG-4-Übertragung über das Internet. Also ist es für Endsysteme (Sender und Empfänger) wichtig, Protokolle zu gestalten, die die fehlende QoS ausgleichen. In dieser Ausarbeitung wurde eine Architektur vorgestellt, die Lösungsvorschläge anbietet.

- 22 -

Nach einer Einführung in MPEG-4 und RTP/RTCP wurden die vier Komponenten für die Video-Übertragung vorgestellt: - eine Rückmeldungssteuerung und Quellenratenadaption, sodass der Sender seine Ausstoßra-te nach erhalt des Empfänger-feedbacks einstellen kann. Es wurde dafür ein Algorithmus vorgestellt, der während der Übertragung die Ausstoßrate der MPEG-4 Codierer einstellt, um die verfügbare Netzbandbreite auszuschöpfen. - ein Paketierungsschema, das das VOP-Merkmal von MPEG-4 benutzt. Hierfür wurde ein Paketierungsalgorithmus vorgestellt, der die Paketgroße der zu übertragenen Daten feststellt, um einen effizienten Transfer zu erzielen. - schließlich wurde eine einfache Fehlerkontrolle vorgestellt, die entstehenden Fehler und Verluste nach der Übertragung auszugleichen versucht. Zum Schluss zeigten die Simulationsergebnisse, dass unsere vorgeschlagene Übertragungsar-chitektur und Algorithmen dazu fähig sind, gute Qualität unter niedrigen Bitraten und verän-derlichen Netzbedingungen zu liefern. Referenzen und Literatur [1] Henning Schulzrinne, Stephen Casner, Ron Frederick und Van Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, IETF, Januar 1996. [2] F. Le Leannec and C.M. Guillemot, “Error resilient video transmission over the Internet” in Proc.SPIE Visual Communications and Image Processing (VCIP’99), June 1999. [3] T. Turletti and C. Huitema, “RTP payload format for H.261 video streams” IETF, RFC 2032, Oct. 1996. [4] C. Zhu, “RTP payload format for H.261 video streams” IETF, RFC 2190, Sept. 1997. [5] Colin Perkins und Orion Hodson. Options for Repair of Streaming Media. RFC 2354, IETF, Juni 1998. [6] Georg Carle und Ernst W. Biersack. Survey of Error Recovery Techniques for IPbased Audio-Visual Multicast Applications. IEEE Network, 11(6), Dezember 1997.

- 23 -

- 24 -

[7] Christos Papadopoulos und Gurudatta M. Parulkar. Retransmission-Based Error Control for Continuous Media Applications. In Proceedings of NOSSDAV. 1996. [8] David Leon und Viktor Varsa. RTP Retransmission Framework. Internet-Draft, IETF, März 2002. draft-ietf-avt-rtp-retransmission-00. R. Steinmetz: "Multimedia Technologie - Grundlagen, Komponenten u. Systeme", Springer-Verlag, 1999 MPEG Requirements Group, " Overview of the MPEG-4 Standard", Doc. ISO/MPEG N2459, MPEG Atlantic City Meeting, October 1998 Christine Guillemot, Stefan Wesner und Paul Christ. Integrating MPEG-4 into the Internet. Band 1629, Mai 1999.