Paper

Transcription

Paper

T ECHNISCHEU NIVERSITÄTI LMENAU
Fakultät für Informatik und Automatisierung
Institut für Praktische Informatik
Fachgebiet Telematik
DIPLOMARBEIT ZUR ERLANGUNG DES
AKADEMISCHEN GRADES DIPLOMINFORMATIKER
Thema:
Kodierverfahren für die verteilte Übertragung QOSsensitiver Datenströme über hochdynamische Netzwerke
Verfasser:
Holger Kärst
geboren am:
01.07.1976
Studiengang:
Informatik
Schwerpunkt:
Telematik
verantwortlicher Hochschullehrer:
Prof. Dr.-Ing. Dietrich Reschke
betreuender wiss. Mitarbeiter:
Dipl.-Inf. Thorsten Strufe
Beginn der Arbeit:
03.05.2004
Abgabe der Arbeit:
03.11.2004
Inv.Nr:
2004-11-03/096/IN99/2253
Kurzfassung
Die Erweiterung des Informationsaustauschs mit multimedialen Elementen wird bei
aktuellen und zukünftigen Kommunikationsprozessen immer bedeutungsvoller. Durch
Fortschritte in der Video- und Audiokodierung sind Multimediaübertragungen in
verschiedenen Netzwerken möglich. Eine große Vielfalt existierender, kompakter, mobiler
Endgeräte ermöglicht die Realisierung einer überall verfügbaren, mobilen, multimedialen
Kommunikation. Die aktuellen mobilen Netzwerktechniken stellen Kapazitäten zur
Verfügung, die für die drahtlose Übertragung multimedialer Inhalte ausreichend sind.
Zukünftige mobile Kommunikationssysteme haben die Aufgabe, multimediale
Informationen einfach und effizient zwischen verschiedenen mobilen Endgeräten
austauschen zu können.
Das Ziel dieser Arbeit ist die Entwicklung eines Konzepts, das einen neuen Ansatz für die
Verteilung multimedialer Daten in hochdynamischen Netzwerken beschreibt. Über diesen
Ansatz soll ein effizientes multimediales Dienstangebot für heterogene Endgeräte
bereitgestellt und gleichzeitig eine kooperative Lastverteilung bei der Dienstbereitstellung
zwischen den Teilnehmern des Netzwerks ermöglicht werden. Ein ausgewähltes
Kodierverfahren liefert dabei die Grundlage für das Konzept.
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Inhaltsverzeichnis
1.
Einleitung ................................................................................................................. 1
1.1.
Ziel dieser Arbeit ....................................................................................................... 2
1.2.
Aufbau dieser Arbeit ................................................................................................. 2
2.
Vorbetrachtungen.................................................................................................... 3
2.1.
Netzwerktechnik........................................................................................................ 3
2.1.1.
AdHoc-Netzwerk................................................................................................... 3
2.1.2.
Vorteile von dynamischen Netzen gegenüber Netzen mit Infrastruktur ............... 5
2.2.
Multimediale Daten ................................................................................................... 5
2.2.1.
Digitalisierung analoger Signale ........................................................................... 5
2.2.2.
Eigenschaften digitalisierter Videosignale ............................................................ 6
2.2.3.
Eigenschaften digitalisierter Audiosignale............................................................ 8
2.2.4.
Notwendigkeit einer Komprimierung digitalisierter multimedialer Elemente...... 8
2.2.5.
Grundlagen der Komprimierung von Video- und Audiodaten.............................. 9
2.2.6.
Grundlagen für eine skalierbare Kodierung multimedialer Daten ...................... 15
3.
Anforderungsanalyse ............................................................................................ 16
3.1.
Analyse der speziellen Eigenschaften der Teilgebiete ............................................ 16
3.1.1.
Netzwerk.............................................................................................................. 16
3.1.2.
Multimediadaten.................................................................................................. 17
3.1.3.
Endgeräte............................................................................................................. 18
3.2.
Konkrete Anforderungen der Teilgebiete an das System........................................ 18
3.2.1.
Netzwerk.............................................................................................................. 18
3.2.2.
Multimediadaten.................................................................................................. 19
3.2.3.
Endgeräte............................................................................................................. 20
4.
Entwurf................................................................................................................... 21
4.1.
Netzwerkstruktur ..................................................................................................... 21
4.2.
Netzwerkknoten....................................................................................................... 21
4.3.
Verteilung ................................................................................................................ 21
5.
Spezifikation........................................................................................................... 23
5.1.
Hauptquelle.............................................................................................................. 23
5.1.1.
Aufnahmegeräte................................................................................................... 24
5.1.2.
Encoder................................................................................................................ 24
5.1.3.
Transformator ...................................................................................................... 24
5.1.4.
Absicherung vor Übertragungsfehlern ................................................................ 25
5.1.5.
Server................................................................................................................... 25
5.1.6.
Schnittstellen ....................................................................................................... 26
5.2.
Verteilerquelle ......................................................................................................... 27
Verfasser: Holger Kärst
i
Diplomarbeit
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
5.2.6.
Inv.Nr.: 2004-11-03/096/IN99/2253
Wiedergabeeinheit ............................................................................................... 28
Client ................................................................................................................... 28
Bereitstellungspuffer ........................................................................................... 29
Puffermanager ..................................................................................................... 30
Server................................................................................................................... 31
Schnittstellen ....................................................................................................... 32
5.3.
Datenstruktur ........................................................................................................... 33
6.
Auswahl der Komponenten für die Implementierung ....................................... 34
6.1.
Untersuchung aktueller Standards zur Kodierung multimedialer Informationen ... 34
6.1.1.
H.261 ................................................................................................................... 34
6.1.2.
H.263 ................................................................................................................... 35
6.1.3.
Verifikation des MPEG1-Standards .................................................................... 35
6.1.4.
6.1.5.
6.2.
Untersuchung von Protokollen der Anwendungsschicht ........................................ 86
6.2.1.
Real Time Streaming Protokoll (RTSP).............................................................. 86
6.2.2.
Session Description Protocol (SDP).................................................................... 88
6.3.
Untersuchung von Protokollen der Transportschicht .............................................. 91
6.3.1.
Transport Control Protocol (TCP)....................................................................... 91
6.3.2.
User Datagram Protocol (UDP)........................................................................... 91
6.3.3.
Realtime Transmission Protocol (RTP)............................................................... 92
6.3.4.
Realtime Transmission Control Protocol (RTCP)............................................... 95
6.4.
Analyse einer Auswahl verfügbarer Encoder / Stream-Server................................ 98
6.4.1.
Microsoft Windows Media Server ...................................................................... 98
6.4.2.
Real Networks Helix Server ................................................................................ 99
6.4.3.
Apple Darwin Server ........................................................................................... 99
6.4.4.
DivX .................................................................................................................. 100
6.4.5.
XviD .................................................................................................................. 100
6.4.6.
Fraunhofer IIS MPEG4 Encoder / Stream-Server............................................. 101
6.4.7.
MPEGable Broadcaster ..................................................................................... 101
6.4.8.
MPEG4IP-MP4Live .......................................................................................... 102
6.4.9.
Fazit ................................................................................................................... 103
6.5.
Analyse einer Auswahl verfügbarer Decoder / Wiedergabeeinheiten................... 105
6.6.
Plattform für die Implementierung des Multisource-Streaming-Ansatzes............ 106
6.6.1.
Netzwerkstruktur ............................................................................................... 106
6.6.2.
Netzwerkknoten................................................................................................. 106
6.6.3.
Protokolle .......................................................................................................... 109
6.6.4.
Entwicklungsumgebung .................................................................................... 110
7.
Implementierung ................................................................................................. 111
7.1.
Hauptquelle............................................................................................................ 111
7.1.1.
MultisourceHq ................................................................................................... 111
7.1.2.
ClientHauptquelle.............................................................................................. 113
7.1.3.
ServerHauptquelle ............................................................................................. 114
ii
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7.2.
Verteilerquelle ....................................................................................................... 118
7.2.1.
Multisource........................................................................................................ 118
7.2.2.
Client ................................................................................................................. 120
7.2.3.
Server................................................................................................................. 126
7.3.
Kernsystem ............................................................................................................ 126
7.3.1.
BufferManager................................................................................................... 126
7.3.2.
Buffer................................................................................................................. 128
7.3.3.
CircularQueue.................................................................................................... 128
7.3.4.
Streaming........................................................................................................... 132
7.3.5.
StreamRequest ................................................................................................... 136
7.3.6.
LinkmanagerClient ............................................................................................ 138
7.3.7.
LinkManagerServer ........................................................................................... 139
7.3.8.
RTPPacket ......................................................................................................... 139
7.3.9.
StreamManager.................................................................................................. 140
8.
Ergebnisse ............................................................................................................ 141
8.1.
Test der Ressourcenauslastung (single Source Streaming) ................................... 142
8.2.
Entfernungstest im drahtlosen Adhoc-Netzwerk (single Source Streaming)........ 144
8.3.
Entfernungstest mit multiplen Anfragen (single Source Streaming)..................... 146
8.4.
Entfernungstest im 3-stufigen Verteilersystem (single Source Streaming).......... 149
8.5.
Entfernungstest im 3-stufigen Verteilersystem (multi Source Streaming)............ 151
9.
Zusammenfassung ............................................................................................... 154
10.
Ausblick ................................................................................................................ 156
11.
Schlussbemerkung ............................................................................................... 157
12.
Anhang.................................................................................................................. 158
13.
Literaturverzeichnis ............................................................................................ 173
14.
Abkürzungen........................................................................................................ 175
iii
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abbildungsverzeichnis
Abb. 1)
Adhoc-Netzwerk mit 7 Netzwerkknoten ............................................................ 3
Abb. 2)
Beispiel Adhoc Netzwerk im Endnutzerbereich ................................................ 4
Abb. 3)
Y/CR/CB Abtastschemata .................................................................................. 7
Abb. 4)
Grundlagen der Komprimierung von Videodaten (Referenz: [12]) ................... 9
Abb. 5)
Übliche Bildsequenz einer MPEG-GOP .......................................................... 11
Abb. 6)
MPEG1 Audio Enkodier- und Dekodierprozess (Ref: [17] S.490).................. 11
Abb. 7)
MPEG2 AAC-Coder (Ref: [17] S.492) ............................................................ 13
Abb. 8)
Reflektionen in drahtlosen Netzen ................................................................... 17
Abb. 9)
Entwurf des Verteilernetzwerks des Multisource-Streaming-Ansatzes ........... 22
Abb. 10) Architektur der entworfenen Hauptquelle ........................................................ 23
Abb. 11) Architektur der spezifizierten Verteilerquelle ................................................. 27
Abb. 12) Struktur des MPEG1-Videostroms (Ref: [13] S. 136 Figure 8.1) .................... 36
Abb. 13) Slicestruktur eines MPEG1-Frames ................................................................. 37
Abb. 14) Blocknummerierung im MPEG1 Chromaformat 4:2:0 .................................... 37
Abb. 15) Struktur des MPEG1-Systemstroms ................................................................. 38
Abb. 16) MPEG1-System Pack-Header .......................................................................... 38
Abb. 17) MPEG1-System-Header ................................................................................... 39
Abb. 18) MPEG1-Packetheader ...................................................................................... 39
Abb. 19) Kompatibilität zw. MPEG1 und MPEG2 Video (Referenz: [14] S.183) ......... 41
Abb. 20) Struktur einer MPEG2-Videosequenz (Referenz: [14] S.183) ......................... 42
Abb. 21) Dekodierung einer SNR-skalierbar codierten MPEG2-Videosequenz (Ref:
[16] S.107) ........................................................................................................ 44
Abb. 22) Picture temporal scalable extension.................................................................. 45
Abb. 23) Temporal Scalability......................................................................................... 46
Abb. 24) Data Partitioning (Ref: [16]S. 119) .................................................................. 46
Abb. 25) Struktur eines zu MPEG1 kompatiblen MPEG2 Audioframes ........................ 48
Abb. 26) Struktur des MPEG2 Packetized Elementary Stream (Referenz: [14] S. 223) 49
Abb. 27) MPEG2 PES-Pack (Ref: [14] S. 224)............................................................... 50
Abb. 28) MPEG2-Transportstrom (Ref: [14] S. 225)...................................................... 51
v
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 29) MPEG2-Transportstrompaket Header-Struktur (Ref: [14] S. 225) .................. 51
Abb. 30) Multisource-Streaming eines skaliertbar codierten MPEG2-Mediastroms...... 55
Abb. 31) Multisource-Streaming von nummerierten PES-Paketen................................. 56
Abb. 32) Objekt- und Szenenbeschreibung einer MPEG4-Sequenz (Ref: [17] S.85)..... 59
Abb. 33) MPEG4-Deskriptoren-Framework ................................................................... 60
Abb. 34) OCI-Metadaten für ein MPEG4-Objekt (Bsp: Zeitdefinition für das
Erscheinen eines Objektes in einer Szene) (Ref: [17] S.99)............................. 61
Abb. 35) OCI Events (Ref: [17]) ..................................................................................... 62
Abb. 36) Zusammenarbeit zwischen MPEG4-System und DMIF (Ref: [17] S. 230)..... 66
Abb. 37) Hierarchische Struktur des MPEG4-Videostroms (Ref: [17] S.298) ............... 67
Abb. 38) Visual Object Sequence / Visual Object........................................................... 68
Abb. 39) MPEG4-GOV-Header ...................................................................................... 68
Abb. 40) MPEG4 Makroblockarten................................................................................. 69
Abb. 41) Gray Level Shape Coding (Ref: [17] S.324) .................................................... 71
Abb. 42) Skalierung der Basisschichtinformationen auf das Sampling Grid des
Erweiterungslayers (Ref: [17] S.334) ............................................................... 72
Abb. 43) räumlich skalierbare Kodierung in MPEG4 (Ref: [17] S.333)......................... 73
Abb. 44) zeitlich skalierbare Kodierung in MPEG4 (Ref: [17] S.337) ........................... 74
Abb. 45) SNR Fine Granularity Scalability (FGS) (Ref: [17] S.341) ............................. 75
Abb. 46) Selektion eines Elementarstroms eines Objekts bestimmter Qualität (Ref:
[17] S.76) .......................................................................................................... 77
Abb. 47) Aufbau eines MPEG4 Videopakets.................................................................. 78
Abb. 48) Beispiel Paketbasierte Resynchronisation ........................................................ 78
Abb. 49) Videopaket im Data Partitioning Modus für DCT-Werte von I-VOP’s.......... 79
Abb. 50) Videopaket im Data Partitioning Modus für Bewegungsvektoren und
Texturdaten von P-VOP’s ................................................................................ 79
Abb. 51) Datenwiederherstellung mit RVLC .................................................................. 80
Abb. 52) Aufbau eines MPEG4-Videopakets mit HEC .................................................. 80
Abb. 53) Blockdiagram - Error-Protection-Tool [17] S.479 .......................................... 83
Abb. 54) RTP-Header (Referenz: [1] S.13) ..................................................................... 92
Abb. 55) RTCP-Paket-Header (Referenz: [1]) ................................................................ 95
Abb. 56) Payload des Sendereport-Pakets (Referenz: [1]) .............................................. 96
vi
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 57) Payload eines RR-Pakets (Referenz: [1]) ......................................................... 96
Abb. 58) MPEGable Broadcaster (Referenz: [27])........................................................ 102
Abb. 59) Architektur der implementierten Hauptquelle ................................................ 107
Abb. 60) Architektur der implementierten Verteilerquelle............................................ 109
Abb. 61) Grundgerüst der Implementierung des Verteilerservers „MultisourceHq“ .... 112
Abb. 62) Initialisierung von Threads für jede eintreffende Clientanfrage..................... 114
Abb. 63) Zeitablaufdiagramm für einen Service-Request ............................................. 115
Abb. 64) Kommunikationsprozess zur Abschätzung der Verbindungsqualität............. 116
Abb. 65) Anforderung der Konfigurationsinformationen.............................................. 117
Abb. 66) Anforderung der Elementarströme ................................................................. 118
Abb. 67) Grundgerüst der Implementierung der Verteilerquelle „Multisource“........... 119
Abb. 68) Auslesen der Datei „serverlist“ und Anlegen des ServerType-Feldes ........... 120
Abb. 69) Definition eines „ServerType“-Objektes........................................................ 121
Abb. 70) Definition eines „StreamType“-Objektes ....................................................... 121
Abb. 71) Beispiel einer „serviceList“ ............................................................................ 121
Abb. 72) Auswahl der Diensterbringer.......................................................................... 123
Abb. 73) Ermittlung eines gemeinsamen Startzeitpunkts für den Anforderungsprozess
der Elementarströme....................................................................................... 124
Abb. 74) Puffer- Asynchronität erster Fall .................................................................... 125
Abb. 75) Puffer - Asynchronität zweiter Fall ................................................................ 125
Abb. 76) Ringpuffer....................................................................................................... 128
Abb. 77) Korrekt gefüllter Ringpuffer........................................................................... 130
Abb. 78) Ringpuffer teilweise überschrieben, mit „Fehlerlücke“ durch Transportverlust
der Elemente 18-21......................................................................................... 130
Abb. 79) Ringpuffer mit Lesezeiger für Streaming zu einem entfernten Client ........... 133
Abb. 80) Ringpuffer mit Lesezeiger für lokales Streaming........................................... 133
Abb. 81) Geschwindigkeitskorrektur im Auslesevorgang............................................. 134
Abb. 82) Netzwerktopologie im Versuchsaufbau 1: Multiple Anfragen....................... 142
Abb. 83) Messergebnis Versuch 1 ................................................................................. 143
Abb. 84) Netwerktopologie im Versuchsaufbau 2: Entfernungstest ............................. 144
Abb. 85) Netzwerktopologie im Versuchsaufbau 3:
Entfernungstest/Kapazitätsauslastung ............................................................ 146
vii
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 86) Messergebniss Ressourcenauslastung VQ1 Versuch 3 .................................. 147
Abb. 87) Netzwerktopologie Versuch 4: erweiterter Entfernungstest........................... 149
Abb. 88) Messergebnis Ressourcenauslastung VQ1 Versuch4..................................... 150
Abb. 89) Netzwerktopologie Versuch5: multi Source Streaming ................................. 151
Abb. 90) Messergebnis Ressourcenauslastung VQ1 Versuch5..................................... 153
Tabellenverzeichnis
Tabelle 1:
Eigenschaften der MPEG1-Audio-Layer .................................................... 12
Tabelle 2:
Übersicht über geforderte visuelle Auflösungen (in Pixel) ......................... 20
Tabelle 3:
SNR-Skalierbarkeit durch Chroma Simulcast Referenz: [16] S.109 .......... 44
Tabelle 4:
Referenzen für zeitlich skalierte P-Frames des MPEG2-Standards
Referenz: [16] S. 113.................................................................................. 45
Tabelle 5:
Referenzen für zeitlich skalierte B-Frames des MPEG2-Standards
Referenz: [16] S. 114.................................................................................. 45
Tabelle 6:
Möglichkeiten der hybriden Skalierbarkeit in MPEG2............................... 47
Tabelle 7:
Zuordnungsbeispiel EP-Klasse <-> ESC..................................................... 84
Tabelle 8:
Fehlersicherungsmaßnahmen für EP-Klassen............................................. 84
Tabelle 9:
Messergebniss Entfernungstest (single Source) ........................................ 145
Tabelle 10:
Messergebnis Entfernungstest mit multiplen Anfragen (single Source)... 146
Tabelle 11:
Messergebnis 3-stufiger Entfernungstest (single Source) ......................... 149
Tabelle 12:
Messergebnis 3-stufiger Entfernungstest (multi Source) .......................... 152
viii
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
1. Einleitung
Der multimediale Informationsaustausch spielt bei aktuellen und zukünftigen
Kommunikationsprozessen eine immer größere Rolle. Fortschritte in der Video- und
Audiokodierung machen Multimediaübertragungen über einen großen Bereich
verschiedener Netzwerke möglich. Eine enorme Varianz bereits heute existierender,
kompakter, mobiler Endgeräte und ein ergiebiger Forschungsaufwand in der drahtlosen
Netzwerktechnik, lassen die Vision der überall verfügbaren, mobilen, multimedialen
Kommunikation immer greifbarer werden.
Die zu vermittelnden Datenmengen steigen jedoch mit dem Wunsch der Nutzer, nach
neuen multimedialen, mobilen Diensten, wie z.B. Videokonferenzen, Live Streaming oder
Video on Demand immer weiter an.
Mit den aktuellen mobilen Netzwerktechniken WLAN und UMTS stehen
Übertragungskanäle mit Kapazitäten zur Verfügung, die für die drahtlose Übertragung
multimedialer Inhalte ausreichend sind.
Die Probleme für die Verteilung von Multimediadaten verschieben sich deshalb immer
weiter von den Netzwerkkapazitäten, auf die Serversysteme der Diensterbringer und die
Heterogenität der Endgeräte.
Die Anforderungen an zukünftige mobile Kommunikationssysteme bestehen darin,
multimediale Informationen einfach und effizient zwischen verschiedenen mobilen
Endgeräten austauschen zu können.
Die Nutzung der Kommunikationsdienste ist nicht vorhersehbar. Die benötigten
Kapazitäten können deshalb kaum abgeschätzt werden. Durch eine Überdimensionierung
der
dienstanbietenden
Serversysteme
entstehen
überhöhte
Kosten.
Die
Unterdimensionierung der Systeme führt zu fehlenden Kapazitäten für die
Diensterbringung. Deshalb sollte kein zentraler Diensterbringer mit festgelegten
Kapazitäten eingesetzt werden. Ebenso ist das Angebot von Informationen in
verschiedenen Qualitätsstufen keine effiziente Lösung, um alle Endgerätetypen versorgen
zu können.
Es muss eine bessere Form der Dienstbereitstellung, der Informationsstruktur und der
Informationsverteilung entwickelt werden.
1
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
1.1. Ziel dieser Arbeit
Es soll ein Konzept entstehen, das einen neuen Ansatz für die Verteilung multimedialer
Daten in hochdynamischen Netzwerken beschreibt.
Die Grundidee der Arbeit besteht darin, ein Kodierverfahren zu verwenden, das eine
Multimediasequenz bereits im Kodierprozess so skalierbar strukturieren kann, sodass sie
flexibel an alle Endgerätetypen anpassbar ist und aus mehreren unabhängig verteilbaren
Datenströmen besteht. Der Dienstnutzer kann die verteilten Datenströme von mehreren,
verschiedenen Quellen anfordern und zu einer darstellbaren Multimediasequenz
zusammenführen. Die Datenströme sind derart aufgebaut, dass eine erhöhte
Fehlerrobustheit für eine Übertragung über verlustbehaftete Kanäle gewährleistet werden
kann.
Mit diesem „Multisource-Streaming-Ansatz“ soll ein Lösungsvorschlag entstehen, durch
den ein effizientes multimediales Dienstangebot für heterogene Endgeräte bereitgestellt
werden kann und gleichzeitig eine kooperative Lastverteilung bei der Dienstbereitstellung
zwischen den Teilnehmern des Netzwerks erfolgt.
Dieses Konzept wird nach dem Entwurf, der Spezifikation und der Überprüfung auf
Realisierbarkeit prototypisch implementiert.
1.2. Aufbau dieser Arbeit
Im Verlauf dieser Arbeit werden die Grundlagen der heutigen dynamischen Netzwerke
dargestellt. Es werden kurze Ausführungen über die Eigenschaften multimedialer
Informationen gemacht. Nach diesen Vorbetrachtungen folgt die Anforderungsanalyse für
den neuen, zu entwickelnden Multimedia-Streaming-Mechanismus. Diese Analyse bildet
die Grundlage für den Entwurf und die Spezifikation des Systems. Der Kern der Arbeit
beschäftigt sich mit der Untersuchung aktueller, verfügbarer Kodierverfahren. Es folgt eine
Analyse einsetzbarer Netzwerkprotokolle und Komponenten für das zu entwickelnde
System. Nach der Auswahl der geeigneten Plattform wird eine prototypische
Implementierung des neuen Multimedia-Streaming-Mechanismus vorgenommen.
2
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
2. Vorbetrachtungen
In diesem Kapitel werden Techniken beschrieben, die die Grundlage dieser Arbeit bilden.
Hier soll dem Leser ein Grundverständis für die Problematik und über die verwendeten
Verfahren der Netzwerktechnik vermittelt werden. Weiterhin erläutert dieses Kapitel die
grundlegenden Eigenschaften multimedialer Daten.
2.1. Netzwerktechnik
In der Netzwerktechnik werden zwei grundlegende Netzwerktypen unterschieden, die
Infrastruktur-Netzwerke und die dynamischen Netzwerke.
Infrastruktur-Netzwerke besitzen eine fest definierte Architektur. Dem Aufbau eines
Infrastruktur-Netzwerkes geht immer eine umfassende Planungsphase voraus. In dieser
Phase wird die Struktur des Netzwerkes festgelegt. Nach dem Aufbau des InfrastrukturNetzwerkes sind Änderungen an der Grundstruktur sehr aufwendig und kostenintensiv.
Dynamische Netzwerke hingegen besitzen keine feste Struktur.
Die Architektur eines solchen Netzwerkes passt sich kontinuierlich an die
Umgebungssituation an. Eine Planungsphase für diesen Netzwerktyp existiert nicht. Diese
Arbeit beschäftigt sich mit einer spezialisierten Art dieses dynamischen Netzwerktyps, den
Adhoc-Netzwerken. Im folgenden Abschnitt wird ein Überblick über diese
Vernetzungstechnik gegeben.
2.1.1. AdHoc-Netzwerk
Adhoc-Netzwerke sind sich über die Zeit verändernde, spontane Zusammenschlüsse von
meist heterogenen Netzwerkknoten, ohne zugrundeliegende Infrastruktur und zentralisierte
Administration.
Abb. 1) Adhoc-Netzwerk mit 7 Netzwerkknoten
3
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Abb. 1) stellt beispielhaft die Architektur eines Adhoc-Netzwerkes dar. Die
Kommunikation zwischen den Netzwerkknoten basiert auf drahtlosen Standards, wie zum
Beispiel WLAN oder Bluetooth. Jeder Netzwerkknoten kann spontan einem AdhocNetzwerk beitreten und kann dieses auch genauso spontan wieder verlassen. Jeder
Netzwerkknoten bietet allen anderen Netzwerkknoten des Adhoc-Netzwerkes seine lokal
verfügbaren Dienste an. Das zentralisierte, starre Client-Server-Prinzip wird somit durch
ein flexibles, verteiltes Dienstangebot ersetzt.
Adhoc-Netzwerke werden dann eingesetzt, wenn keine Kommunikationsinfrastruktur
verfügbar ist und sehr schnell eine Kommunikation zwischen heterogenen Netzwerkknoten
ermöglicht werden soll. In Gebieten, in denen durch Naturkatastrophen die gesamte
Infrastruktur zerstört wurde, ist die Möglichkeit, innerhalb eines Adhoc-Netzwerkes über
Audio- und Video-Livestreams kommunizieren zu können, sehr interessant und überaus
wichtig. Auch das Militär ist natürlich an den Diensten interessiert, die sehr einfach und
schnell über Adhoc-Netze angeboten werden können.
In der Wirtschaft finden Adhoc-Netzwerke bei Konferenzen, Meetings, Vorlesungen und
Präsentationen Anwendung.
Im Endnutzerbereich können z.B. einzelne Multimediageräte über ein Adhoc-Netzwerk zu
einem intelligenten Multimediacenter zusammengeschlossen werden, wie die folgende
Abbildung zeigt.
Abb. 2) Beispiel Adhoc Netzwerk im Endnutzerbereich
Es gibt also die unterschiedlichsten Einsatzbereiche für Adhoc-Netzwerke.
4
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
2.1.2. Vorteile von dynamischen Netzen gegenüber Netzen mit Infrastruktur
Die Mobilität während des Informationsaustausches ist eine zentrale Anforderung in
aktuellen Kommunikationsprozessen. Der Aufbau einer Infrastruktur erzeugt enorme
Kosten und kann häufig nicht geographisch lückenlos alle Gebiete abdecken.
Eine einmal aufgebaute Infrastruktur ist mit neuen Techniken und Ideen nicht flexibel
erweiterbar. Die Kosten der Entwicklung und der Installation müssen sich erst
amortisieren, bevor neue Techniken in Form einer neu entwickelten Infrastruktur
eingesetzt werden. Infrastrukturen hemmen dadurch die Entwicklung.
Dynamische AdHoc-Netzwerke sind sehr flexibel auch in schwierigen geographischen
Gebieten einsetzbar. Die verfügbaren Ressourcen können besser genutzt werden. Neue
Dienste sind leicht durch neue Netzwerkknoten in das dynamische Netzwerk integrierbar.
Die Gefahr eines Totalausfalls aller Dienstangebote wird auf ein Minimum beschränkt.
Eine echte Aufgabenverteilung und Parallelisierung führt zu einer schnelleren und
effizienteren Problemlösung. Verteilte Informationen sind wieder verwendbar und werden
nicht nach einem Kommunikationsprozess wertlos.
Um alle diese Vorteile nutzbar zu machen, ist ein erhöhter Entwicklungs- und
Forschungsaufwand auf dem Gebiet der dynamischen Netzwerke erforderlich.
2.2. Multimediale Daten
Multimediale Daten bestehen aus visuellen und auditiven Elementen. Die Speicherung und
die Verteilung dieser Elemente erfolgt heute hauptsächlich digital. Um den Verteilungsund Speicherungsprozess effizient zu gestalten, sind mehrere Verarbeitungsschritte mit den
multimedialen Elementen erforderlich. Dieser Abschnitt gibt einen Überblick über die
Eigenschaften dieser Elemente und die notwendigen Verarbeitungsschritte.
2.2.1. Digitalisierung analoger Signale
Kontinuierliche Signale, wie z.B. analoge Audio- und Videosequenzen müssen für die
digitale Speicherung bzw. Übertragung zunächst digitalisiert werden. Hierzu werden die
analogen Signalströme zeit- und wertquantisiert. Damit das Originalsignal aus den
Abtastwerten rekonstruiert werden kann, wird an die Zeitquantisierung die Anforderung
des Shannon Theorems gestellt. Das Abtasttheorem von Shannon besagt, dass bei der
Abtastung eines analogen Signals für eine spätere vollständige Rekonstruktion des Signals,
die Abtastfrequenz (d. h. die Anzahl der Abtastungen / Zeiteinheit) mindestens doppelt so
hoch sein muss, wie die höchste im Originalsignal enthaltene Frequenz. Auch die
Wertquantisierung ist nicht beliebig wählbar. Je grober die „Auflösung“, d.h. je weniger
Quantisierungstufen benutzt werden, umso größer ist der Quantisierungsfehler und umso
ungenauer wird die Rekonstruktion der Amplitudenwerte des analogen Originalsignals. Je
5
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
schlechter die Rekonstruktion des Originalsignales gelingt, und umso geringer wird der
Abstand zwischen Rauschsignal und Nutzsignal (SNR).
2.2.2. Eigenschaften digitalisierter Videosignale
Man unterscheidet folgende Arten von analogen Videosignalen:
•
Primärvalenzen: z.B. RGB
•
Luminanz mit Farbdifferenzkomponenten z.B. Y/Cr/Cb
•
Luminanz mit geträgertem Chrominanzsignal z.B Y/C
•
Zusammengesetztes Videosignal z.B FBAS
Die Eigenschaften dieser Videosignaltypen werden in den folgenden Abschnitten kurz
vorgestellt.
2.2.2.1. RGB
Die Erzeugung eines RGB-Signals wird durch drei Photosensoren (Rot, Grün, Blau)
erreicht. Mit Hilfe dieser drei Farben lassen sich durch Mischen alle anderen Farben eines
definierten, standardisierten Farbraumes erzeugen. Diese drei Farbsignale werden räumlich
getrennt als RGB-Signal übertragen.
2.2.2.2. Y/Cr/Cb
Das RGB-Signal wird in ein Helligkeitssignal (Luminanz
Farbdifferenzsignale Cr (R-Y) und Cb (B-Y) umgewandelt.
Y)
und
in
die
Das Helligkeitssignal besteht dabei aus definierten Anteilen der RGB-Grundfarben:
Y=0,3*R+0.59G+0.11B.
Diese Trennung der Helligkeitsinformation von der Farbinformation wurde vorgenommen,
um zum früher am meisten verbreiteten Schwarz/Weiss-Fernsehen kompatibel zu sein.
Durch Untersuchungen wurde herausgefunden, dass das Helligkeitssignal für den
Menschen die meisten Informationen liefert, während die Farbdifferenzsignale eine
untergeordnete Rolle spielen. Somit ist eine Unterabtastung der Farbdifferenzsignale in
gewissen Grenzen möglich, ohne dass für den Menschen sichtbare Qualitätsverluste
entstehen. Das ist für eine erste Komprimierungsmöglichkeit nutzbar.
In aktuellen Standards werden unterschiedliche Abtastraten der Farbdifferenzsignale
definiert. Eine Darstellung der gebräuchlichsten Abtastschemata kann man der Abb. 3)
entnehmen.
6
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 3) Y/CR/CB Abtastschemata
Die Abtastrate für die Digitalisierung der drei Informationskomponenten für PAL wurde
folgendermaßen standardisiert:
•
Cr: 3/2 * 625 * (576/4)*1/s = 3,375 MHz
•
Cb: 3/2 * 625 * (576/4)*1/s = 3,375 MHz
•
Luminanz: 4 * 3.375 MHz = 13,5 MHz
Bei einer Wertequantisierung von 8 bit werden folgende Datenraten zur Übertragung von
digitalisierten unkomprimierten Y/Cr/Cb Signalen des PAL-Standards notwendig:
•
4:4:4 => 13.5*1000000/s*8bit*3 = 324 Mbit/s
•
4:2:2 => (13.5 + 2*2*3.375)*1000000/s*8bit = 216 Mbit/s
•
4:1:1 => (13.5 + 2*3.375)*1000000/s*8bit = 162 Mbit/s
•
4:2:0 => (13.5 + 2*3.375)*1000000/s*8bit = 162 Mbit/s
2.2.2.3. FBAS
Mit dem FBAS-Signal werden Luminanz und Chrominanz (Farbdifferenzsignale) additiv
im Frequenzmultiplex auf einem Übertragungsmedium gemeinsam übertragen.
Die Farbdifferenzsignale werden auf einen Farbhilfsträger aufmoduliert. Die Frequenz für
den Farbhilfsträger wurde auf 4,433 MHz festgelegt.
Für die Digitalisierung eines analogen FBAS-Signales ist die Abtastfrequenz das Vierfache
der Farbhilfsträgerfrequenz, somit 17,734475 MHz.
Bei einer Wertquantisierung von 8 bit ist für die Übertragung eines digitalen
unkomprimierten FBAS-Signals eine Übertragungsrate von >141,88 Mbit/s erforderlich.
7
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
2.2.2.4. HDTV
Die Auflösung von 625:576 ist für heutige Anforderungen an die Qualität einer visuellen
Darstellung nicht mehr ausreichend. Je größer die Auflösung, umso schärfer ist das Bild.
Der HDTV Standard fordert im 1080i – Modus zum Beispiel eine Auflösung von
1920:1080. Um einen unkomprimierten Videostrom dieser Auflösung zu übertragen, ist bei
einer Bildwiederholrate von 25 Halbbildern/s eine Übertragungsrate von >1,2 Gbit/s
erforderlich.
2.2.3. Eigenschaften digitalisierter Audiosignale
Für die Digitalisierung von analogen Audiosignalen werden hauptsächlich drei Verfahren
eingesetzt. Bei der Pulse Code Modulation (PCM) wird jeder Abtastwert quantisiert und
als Integer dargestellt. Durch die übliche Abtastrate von 44,1 kHz und die Quantisierung
von 16 bit ist eine Übertragungsrate von 705,6 kBit/s für einen Audiokanal erforderlich.
Um die große Datenmenge zu verringern, wurde ein weiteres Verfahren, die Differential
Pulse Code Modulation (DPCM), entwickelt. Bei DPCM werden nur die Differenzen
aufeinander folgender Abtastwerte Pulse Code moduliert, sodass bei gleicher Qualität eine
bedeutend geringere Datenmenge gegenüber der PCM entsteht. Die Adaptive Differential
Pulse Code Modulation (ADPCM) bezieht zusätzlich die Signalcharakteristik in die Pulse
Code Modulation mit ein, wodurch bei gleich bleibender Datenmenge eine
Qualitätssteigerung erreicht werden kann.
2.2.4. Notwendigkeit einer Komprimierung digitalisierter multimedialer Elemente
Die große Datenmenge, die durch unkomprimierte Mediaströme (Audio und Video)
entsteht, stellt enorme Anforderungen an die Speicherkapazität der Endgeräte und die
Transportkapazität der Netzwerke.
Spätestens am Beispiel von HDTV und PCM ist ersichtlich, dass die Daten von Video- und
Audioströmen komprimiert werden müssen, um eine effiziente Speicherung oder
Übertragung dieser Mediasequenzen gewährleisten zu können.
8
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
2.2.5. Grundlagen der Komprimierung von Video- und Audiodaten
Die prinzipiellen Grundlagen der Videokodierung sind bei den meisten Verfahren sehr
ähnlich. Sie basieren auf der Diskreten Cosinus Transformation (DCT). Die folgende
Grafik stellt den Ablauf des DCT-Kodiervorganges für visuelle Daten dar.
Abb. 4) Grundlagen der Komprimierung von Videodaten (Referenz: [12])
Jedes Eingangsbild der Videosequenz wird in Blöcke von 8 x 8 Bildpunkten unterteilt.
Wenn man von einer 8-bit Wertquantisierung ausgeht, dann enthält jeder dieser Blöcke
eine Datenmenge von 512 bit. Alle Blöcke werden im zweiten Schritt mittels DCT von der
Bildebene in die Frequenzebene transformiert. Als Ergebnis entsteht jeweils wieder ein 8 x
8-Block, der durch 64 Koeffizienten definiert ist. Der Wert des linken oberen Elements der
Matrix ist der Gleichanteil (DC-Wert) - der mittlere Helligkeits- oder Farbanteil - des
Bildausschnittes. Die anderen, von Null verschiedenen AC-Koeffizienten, konzentrieren
sich um den Gleichanteil und stellen die Ortsfrequenzen in horizontaler und vertikaler
Richtung dar. Diese Transformation führt zu einer Dekorrelation des Eingangssignales. Im
dritten Schritt werden die einzelnen Koeffizienten, entsprechend einer definierten
Quantisierungsmatrix, quantisiert. Je nach der Stärke der Quantisierung erhalten weitere
AC-Koeffizienten den Wert Null. Durch die Quantisierung gehen Bildinformationen
verloren, was sich vor allem bei feinen Details im Bild bemerkbar macht. Da jeder Block
getrennt kodiert wird, kann es bei hohen Quantisierungsfaktoren zu sichtbaren
Blockartefakten kommen. Nach der Quantisierung werden die Koeffizienten in einer
bestimmten Reihenfolge (Zig-Zag-Scanning) aus dem Block ausgelesen und somit
serialisiert. Der Scannprozess erfolgt deshalb in diesem Zick-Zack-Muster, um die häufig
vorkommenden niederfrequenten Anteile des Bildes zuerst kodieren zu können. Das
Codewort EOB (End of Block) kennzeichnet, dass alle Koeffizienten, die einen Wert
ungleich Null enthalten, ausgelesen wurden. Damit erspart man sich die Kodierung und
9
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Übertragung der nachfolgenden Nullen. Der resultierende Datenstrom wird durch eine
variable Längenkodierung entropiekodiert. Häufig vorkommenden Werten werden kurze
Codeworte zugeordnet und selten auftretende Werte werden auf lange Codeworte
abgebildet. Im statistischen Mittel findet somit eine Reduktion der Datenrate statt. Die
Datenmenge des Blockes aus Abb. 4) konnte insgesamt von 512 bit auf 26 bit reduziert
werden.
Die Effizienz der Videokodierung kann gesteigert werden, indem man die in aufeinander
folgenden Bildern auftretenden Redundanzen verringert. Das wird erreicht, indem das
gesendete Bild zunächst in einen Bildspeicher geschrieben wird. Für das nachfolgende Bild
werden dann damit die Differenzen aller Bildpunkte ermittelt und nur diese übertragen. Bei
Videosequenzen treten auch starke Veränderungen zwischen aufeinander folgenden
Bildern auf. Diese Veränderungen führen bei einer Differenzbildung zu hohen Datenraten.
Daher wird eine Bewegungsabschätzung durchgeführt, bei der jedem Block ein
Bewegungsvektor zugeordnet wird. Im Bild erfolgt danach eine Bewegungskompensation.
Dabei werden alle Blöcke, um die im Vektor angegebene Größe, verschoben. Man erhält
somit ein abgespeichertes Bild, das besser an das neue, zu übertragende Bild angepasst ist.
Bei der Differenzbildung dieser Bilder entstehen weniger Daten. Zusätzlich zu den
Differenzdaten müssen aber auch die Bewegungsvektoren zum Empfänger übertragen
werden.
Von der „Moving Picture Expert Group“ wurden unterschiedliche Arten der zeitlichen
Prädiktion definiert:
Intraframe Picture (I-Frame)
Ein intrakodiertes „Intraframe Picture“ wird ohne Bewegungskompensation kodiert. Für
die Komprimierung werden nur Informationen, die innerhalb (intra-) des Bildes liegen,
benutzt. Dieser Bildtyp kann unabhängig dekodiert werden. Es sind keine Referenzen auf
vorangehende oder nachfolgende Bilder vorhanden.
Predictive Picture (P-Frame)
In interkodierten „Predictive Picture“ sind nur die Differenzen zwischen (inter-) dem
aktuellen Bild und einem zeitlich zurückliegenden Bild enthalten. Das muss nicht das
zeitlich benachbarte Bild sein, sondern kann auch weiter zurückliegen. Die Menge der zu
kodierenden Daten wird enorm gesenkt.
Bidirektional Predictive Picture (B-Frame)
Interkodierte „Bidirektional Predictive Picture“ besitzen nicht nur Referenzen auf ein
zeitlich zurückliegendes Bild, sondern auch auf ein zukünftiges Bild. Nur Bildinhalte die
zwischen diesen drei Bildern unterschiedlich sind werden kodiert. B-Frames beinhalten
somit noch weniger Daten als P-Frames. Zwei Bewegungsvektoren werden für jeden
Makroblock eines B-Frames generiert. Ein Bewegungsvektor verweist auf einen passenden
10
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Bildausschnitt des vorherigen Bildes (Forward Vector), ein zweiter referenziert einen
passenden Bildausschnitt des nächsten Bildes (Backward Vector) der Videosequenz.
Ein MPEG-Videodatenstrom besteht immer aus einer Sequenz dieser drei verschiedenen
Bildtypen, die in Gruppen zusammengefasst werden („Group of Picture“).
Eine solche Bildfolge ist wie in Abb. 5) dargestellt aufgebaut.
Abb. 5) Übliche Bildsequenz einer MPEG-GOP
I- und P- Bilder sind Stützbilder, da sie als Referenz für eine Bewegungskompensation /
Bewegungsschätzung genutzt werden können. B-Bilder können nicht zur Prädiktion
weiterer Bilder verwendet werden.
Für die Komprimierung und Kodierung von Audiosignalen werden weit verbreitet die
MPEG-Standards eingesetzt. Im MPEG-Audiostandard sind die zwei grundlegenden
Kodierverfahren MPEG und MPEG-AAC unterscheidbar.
Das ältere MPEG-Kodierverfahren unterstützt drei „Layer“ (MPEG Layer1, MPEG
Layer2, MPEG Layer3). Die Komplexität der Encoder und Decoder, die zusätzliche
Verzögerung durch den Kodier- und Dekodierprozess und die Kodiereffizienz steigen vom
Layer1 zum Layer3 an.
Der in der folgenden Abbildung dargestellte Kodier- und Dekodierprozess ist für alle
Layer gleich.
Abb. 6) MPEG1 Audio Enkodier- und Dekodierprozess (Ref: [17] S.490)
11
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Der Kompressionsalgorithmus basiert auf der Aufteilung des Audiofrequenzbereichs in 32
Spektralkomponenten (Subbänder). Dazu werden so genannte Subband-Filterbänke
eingesetzt. In jedem Subband werden 12 Frequenzabtastwerte aufgenommen. Die
Abtastwerte werden mit einer Rate von 44kHz oder 48kHz vom analogen Originalsignal
erzeugt. Anschließend werden die Frequenzbereiche dezimiert und die Abtastwerte
quantisiert. Die Dezimierung und Quantisierung erfolgt über ein psychoakustisches
Modell. Diesem Modell liegen die Eigenschaften des menschlichen Gehörs zugrunde.
Frequenzen die vom menschlichen Gehör nicht wahrgenommen werden können, sollten im
komprimierten Audiosignal nicht mehr vorhanden sein. Die so bearbeiteten Signale
werden als Bitstrom zum Decoder übertragen bzw. in definierten Dateiformaten
gespeichert.
Der MPEG-Layer2 erreicht eine bessere Komprimierung, indem die Quantisierung der
Abtastwerte der einzelnen Frequenzen jedes Subbandes besser an die Eigenschaften des
menschlichen Gehörs angepasst ist. Signalredundanzen werden besser herausgefiltert.
MPEG-Layer3 ist das bekannteste und am weitesten verbreitete Kompressionsverfahren
für Audiosignale. Es verwendet eine hybride Subband- und Transformationskodierung. Bei
dieser hybriden Kodierung werden die Signale in den Frequenzbereich transformiert (z.B.
DCT, FFT). Danach erfolgt eine Frequenzbandaufteilung durch definierte Filterbänke. Die
Frequenzauflösung kann den verschiedenen Frequenzbändern flexibel zugewiesen werden.
Zusätzlich finden im MPEG-Layer3 eine Analyse der Audiosignale durch Synthese, eine
verbesserte Pre-Echo-Kontrolle und eine Quantisierung mit Entropiekodierung statt. Somit
konnte die Kodiereffizienz bei gleich bleibender Qualität der Audiosignale gegenüber dem
Layer 2 nochmals gesteigert werden.
Die folgende Tabelle zeigt die Charakteristiken der einzelnen Layer auf:
MPEG
Audiokodierung
Layer1
Layer2
Layer3
Ungefähre Bitrate
pro Kanal
192 kbit/s
128 kbit/s
64 kbit/s
Kompressionsfaktor
4
8
12
Realistische
Verzögerung
<50 ms
10 ms
150 ms
Minimale
Verzögerung
19 ms
35 ms
58 ms
Tabelle 1: Eigenschaften der MPEG1-Audio-Layer
Die neue Kodier-Technik „MPEG Advanced Audio Coding“ (MPEG-AAC) wurde
hauptsächlich für mehrkanalige Audiowiedergabe entwickelt.
MPEG-AAC unterstützt 48 Hauptaudiokanäle, 16 Audiokanäle für niedrige Frequenzen,
16 Kanäle für multilinguale Audiotracks und 16 Datenkanäle. Für jeden Kanal wurde eine
maximale Datenrate von 64Kbit/s definiert. Im AAC-Standard werden die Profile Main
Profile, Low Complexity Profile und Scalable Sampling Rate Profile abgegrenzt. Das Main
Profile ist optimal nutzbar, wenn keine Grenzen an Rechen- und Speicherkapazität für
Kodierung, Transport, Dekodierung und Speicherung von Audiodaten gesetzt werden.
12
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Das LC-Profile ist in Umgebungen mit geringen Rechenleistungen und geringen
Speicherkapazitäten einsetzbar. Das Scalable Sampling Rate Profile unterstützt skalierbare
Decoder. Die skalierbaren Decoder sind grundlegend dafür gedacht, die Komplexität des
Dekodiervorganges einzugrenzen.
Der AAC-Standard wurde zwar für MPEG2 entwickelt, jedoch sind in den heutigen
MPEG2-Datenströmen selten AAC-kodierte Audioströme enthalten. Erst im MPEG4Standard kommt AAC eine größere Bedeutung zu.
AAC-Coder
Der MPEG2-AAC-Encoder besteht, wie in Abb.
Funktionsmodulen, so genannten Coding Tools.
7) dargestellt, aus mehreren
Abb. 7) MPEG2 AAC-Coder (Ref: [17] S.492)
Das Gain Control Modul wird nur im SSR-Profil genutzt. Hier wird die Dynamik des
eingehenden Audiosignals über Gain-Detektoren und Gain-Modifizierer komprimiert. Der
Frequenzbereich wird in vier Frequenzbänder gleicher Bandbreite zerlegt. Die
13
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Frequenzbänder enthalten Abtastwerte, die mit Abtastraten von 8kHz bis 96kHz vom
analogen Originalsignal gesampelt wurden. Aus den vorverarbeiteten Signalen werden für
jedes Frequenzband, durch eine MDCT-Filterbank, 256 spektrale Koeffizienten erzeugt,
sodass insgesamt 1024 Koeffizienten für jeden Audioframe entstehen. Das Temporal Noise
Shaping -Tool wird nur im LC-Profile eingesetzt und ersetzt in diesem Fall die
Funktionalität des Gain Control Moduls. Es erlaubt, dass Informationen früherer
Audioframes als Vorhersagewerte für den aktuell zu kodierenden Audioframe genutzt
werden können. Nach der Transformation der Audiosignale werden die resultierenden,
spektralen Koeffizienten quantisiert. Skalierungsfaktoren definieren dabei eine variable
Quantisierungsauflösung.
Die
Skalierungsfaktoren
sind
entsprechend
dem
psychoakustischen Modell an die Eigenschaften des menschlichen Gehörs angepasst.
Somit soll Quantisierungsrauschen für alle Frequenzen unter die Wahrnehmungsschwelle
gedrückt werden. Dieser Vorgang wird Noise-Shaping genannt. Nach der Quantisierung
der spektralen Koeffizienten werden die Werte mit Huffman-Code-Tabellen
entropiekodiert und in den Audiobitstrom gemultiplext.
Für die Kodierung von Stereo- oder Multikanal-Audio bei kleinen Bitraten, werden im
MPEG2-AAC-Standard Joint Coding Techniken eingesetzt. Anstatt alle Kanäle einzeln zu
kodieren, werden sie gemeinsam kodiert und zu einem Bitstrom zusammengefasst.
MPEG2-AAC unterscheidet die zwei Techniken: M/S-Stereo-Coding und Intensity-StereoCoding.
Bei M/S-Stereo-Coding werden nicht die Signale des rechten und des linken Kanals
unabhängig kodiert, sondern die Summen- (Middle) und Differenzsignale (Side) der
Kanäle.
Intensity-Stereo-Coding basiert auf dem Prinzip, in dem Spektralwerte mehrerer Kanäle
gemeinsam benutzt werden können. Zusätzlich sind nur noch Positionsinformationen
notwendig, die angeben, zu welcher Zeit die Spektralwerte im jeweiligen Kanal gültig
sind. Somit werden im linken Kanal Spektralwerte übertragen und im rechten Kanal
Positionswerte.
Im Unterschied zu den älteren MPEG-Audio-Standards unterscheidet MPEG2-AAC
zwischen einer Transport- und einer Kompressionsschicht. Die Transportschicht
unterstützt Funktionen für die Synchronisation, Signalisierung und Paketierung von den
Daten der Kompressionsschicht. Resynchronisationspunkte im Strom ermöglichen dem
Decoder im Fehlerfall eine schnelle Resynchronisation auf den Datenstrom. Die feste
Struktur aufeinander folgender Header früherer Standards, wurde durch eine Struktur
ersetzt, in der variable Distanzen, in Abhängigkeit zur aktuellen Bitrate, zwischen den
Headern existieren. Der AAC-Bitstrom ist modular aufgebaut. Definierte syntaktische
Elemente beschreiben einzelne Subbitströme die aus dem Gesamtbitstrom extrahiert und
unabhängig dekodiert werden können.
14
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
2.2.6. Grundlagen für eine skalierbare Kodierung multimedialer Daten
Die Skalierbarkeit von Multimediaströmen ist für die Verteilung in hochdynamischen
Netzen und für heterogene Endgeräte mit unterschiedlichen Anforderungen unerlässlich.
Für die Bereitstellung einer Multimediasequenz in verschiedenen Anforderungsstufen
existieren drei verschiedene Technologien.
Bei der ersten Möglichkeit werden viele unterschiedlich kodierte Multimediaproduktionen
mit verschiedenen Anforderungen an Endgeräte und Netzwerke bereitgestellt. Diese
Technologie ist sehr ineffizient und fordert eine enorme senderseitige Speicherkapazität.
Der zweite Ansatz definiert einen Transcoder, der einen Multimediastrom umkodiert,
sodass der Strom an die verfügbaren Ressourcen angepasst wird. Hierbei wird zwar
Speicherkapazität eingespart, die Kosten werden jedoch auf hohe Anforderungen an die
Rechenleistung verlagert.
Die effiziente Alternative ist die skalierbare Kodierung. Die Realisierung der skalierbaren
Kodierung wird durch die Aufteilung kodierter Informationen in verschiedene Schichten
ermöglicht. Grundsätzlich wird nun zwischen einem Basisdatenstrom und einem oder
mehreren Erweiterungsdatenströmen unterschieden. Der Basisdatenstrom stellt die
Sequenz in einer definierten minimalen Qualitätsstufe dar. Die Erweiterungsdatenströme
erhöhen die Qualität der Sequenz schrittweise, in dem sie erweiterte Daten zu den
Basisdaten liefern. Somit entsteht eine Qualitäts-Hierarchie für die Sequenz. Aus dieser
Hierarchie kann sich der Decoder des Endgeräts die Datenströme der Qualitätsstufe
herauslösen, sodass die Sequenz mit den verfügbaren Ressourcen dargestellt werden kann.
15
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
3. Anforderungsanalyse
In diesem Kapitel werden die Anforderungen an das zu entwickelnde System analysiert.
Dabei wird die Problematik in die drei Teilgebiete Netzwerk, Multimediadaten und
Endgeräte untergliedert. Die Teilgebiete werden getrennt analysiert. Für jedes der Gebiete
werden die grundlegenden Anforderungen herausgearbeitet, die letztendlich
zusammengefasst die Gesamtanforderungen an das System ergeben.
3.1. Analyse der speziellen Eigenschaften der Teilgebiete
Bevor konkrete Anforderungen der Teilgebiete an das Gesamtsystem ermittelt werden
können, müssen die grundlegenden Eigenschaften des Netzwerks, der Multimediadaten
und der Endgeräte analysiert werden.
3.1.1. Netzwerk
Ein Adhoc-Netzwerk besitzt eine enorme Dynamik bezüglich der Anzahl, der
Erreichbarkeit und der Lokalität der Teilnehmer. Die verfügbaren Ressourcen können
somit nicht als feste und kalkulierbare Größe betrachtet werden. Es existiert keine zentrale
Instanz, die Administrationsaufgaben, Ressourcenverwaltung oder eine zentralisierte
Ressourcenbereitstellung übernimmt. Das bedeutet, dass alle Funktionalitäten und
Ressourcen im gesamten Netzwerk auf verschiedenen Netzwerkknoten verteilt sind. Die
Verfügbarkeit von Diensten und Ressourcen muss im Netzwerk durch spezielle
Mechanismen bekannt gemacht werden.
Die Transportkanäle, über die der Informations- und Datenaustausch erfolgt, sind aufgrund
des Transportmediums „Luft“ stark verlustbehaftet. Nicht nur durch das störanfällige
Übertragungsmedium, sondern auch durch die Mobilität der Endgeräte treten
Schwankungen und Asymmetrien bei der Verbindungsqualität zwischen Uplink- und
Downlink-Strecke auf. Die Übertragungskapazitäten und Übertragungsverzögerungen
können zwischen den Teilnehmern stark differieren und sich stochastisch verändern. Die
Ursachen für die Unsicherheit der drahtlosen Übertragung sind unter anderem Reflektion,
Abschattung und Überlagerung von Sendesignalen. Ein Beispiel für eine Reflektion von
Sendesignalen wird in der Abb. 8) gezeigt.
16
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 8) Reflektionen in drahtlosen Netzen
Die grundlegenden Fehler während der Übertragung sind deshalb Informationsverlust,
Informationsverdopplung, Verlust der Informationsordnung und Jitter.
Das Netzwerk unterstützt nur direkte Punkt-zu-Punkt-Verbindungen, ohne „Multihop“bzw. Routingfunktionalitäten. Die Reichweite für die Verteilung der Informationen wäre
ohne die Realisierung einer Wiederverwendbarkeit von Daten stark eingeschränkt.
3.1.2. Multimediadaten
Die zu übertragenden multimedialen Daten besitzen eine fest definierte Struktur und sind
sehr zeitkritisch. Die Elemente einer kodierten Multimediasequenz müssen zu definierten
Zeitpunkten am Decoder vorliegen. Nur so ist eine synchrone Dekodierung und
Wiedergabe abhängiger Elemente realisierbar.
Es können zwei verschiedene Arten der Abhängigkeit zwischen multimedialen Elementen
unterschieden werden. Eine Multimediasequenz besteht meist aus einer Kombination von
Video- und Audioströmen, die synchron wiedergegeben werden müssen und somit eine
Abhängigkeit zueinander besitzen. Aufgrund der Struktur und der Definition können
multimediale Elemente auch innerhalb eines Mediastromes voneinander abhängig sein. In
den meisten Komprimierungsverfahren werden z.B. Informationen bereits dekodierter
Elemente für den Dekodierprozess eines aktuellen Elements verwendet.
Durch diese Abhängigkeiten haben Fehler während des Verteilungsprozesses nicht nur
Auswirkungen auf die direkt betroffenen Elemente, sondern auch auf nachfolgende,
abhängige Elemente.
17
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
3.1.3. Endgeräte
Es existieren heute verschiedene Arten mobiler Endgeräte, die multimediale Informationen
verarbeiten können. Sie besitzen unterschiedliche Speicherkapazitäten, heterogene
Rechenleistungen und Netzanbindungen mit begrenzten Geschwindigkeiten bzw.
Übertragungskapazitäten, verschiedene Darstellungsmöglichkeiten und auch eng begrenzte
Energiereserven. Die wichtigsten Endgeräteklassen sind Handy, Smart Phone, Pocket PC,
PDA, Tablett PC, Subnotebook, Laptop und mobile Multimediaplayer. Damit die
verfügbaren Ressourcen überhaupt eingeschätzt werden können ist eine umfassende
Recherche über die Eigenschaften dieser Endgeräteklassen erforderlich.
Die im Anhang A angegebene Tabelle gibt einen Eindruck über die Varianz der
Geräteeigenschaften aller genannten Arten von Endgeräteklassen. Im Besonderen werden
die Prozessorleistungen, die Displayeigenschaften, die Speicherkapazitäten und die
Multimediafähigkeiten der Klassen verglichen.
3.2. Konkrete Anforderungen der Teilgebiete an das System
Nach der Analyse der Teilgebiete können konkrete Anforderungen des Netzwerks, der
Multimediadaten und der Endgeräte an das zu entwerfende Gesamtsystem gestellt werden.
3.2.1. Netzwerk
Aufgrund der Dynamik des Netzwerkes ist es für jeden Netzwerkknoten notwendig,
kontinuierlich die Ressourcenverfügbarkeit und Übertragungskanalgüte zu den bekannten
Nachbarn zu überprüfen. Neue verfügbare Ressourcen müssen vom Teilnehmer
klassifiziert und im Netzwerk bekannt gegeben werden.
Für die Einschätzung der dynamischen Verbindungseigenschaften werden fortlaufend
Informationen benötigt. Ein geeignetes Steuer- und Transportkontrollprotokoll ist
erforderlich, dass die Netzwerkknoten mit diesen notwendigen Parameterwerten versorgt.
Neben der Übermittlung der Multimediaelemente müssen auch die Zeitinformationen aller
Elemente den Decoder erreichen. Hier muss also ein geeignetes Transportprotokoll
gefunden werden, das Daten und ihre Zeitrelevanzen miteinander verknüpft und
gemeinsam zum Empfänger überträgt.
Es muss für einen zeitkorrekten Versand aller Multimediaelemente gesorgt werden, sodass
diese den Empfänger rechtzeitig erreichen. Rechtzeitig bedeutet in diesem Fall, dass die
kodierten Daten bereits vor ihrem Dekodierzeitpunkt beim Empfänger vorliegen.
Um den Verteilungsradius zu erhöhen sollen die Netzwerkknoten in der Lage sein,
empfangene Multimediainformationen darzustellen und gleichzeitig weiteren Endgeräten
18
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
zur Verfügung zu stellen. Jeder Netzwerkknoten tritt somit als Client und gleichzeitig als
Server auf (entsprechend dem P2P-Ansatz). Die notwendigen Funktionen müssen in jedem
Knoten realisiert werden.
Die Weitervermittlung der Multimediadaten darf keinen Einfluss auf den Empfang von
Daten haben. Somit muss auch kontinuierlich die Kapazität des Uplinks, in Relation zur
geforderten Bandbreite des Downlinks, überprüft werden.
Fehlererkennungs- und Fehlerbehandlungsmechanismen sollen den Schaden minimieren,
der aufgrund erwarteter Verluste auf dem Übertragungsweg entsteht. Hier ist es wichtig,
ein ausgewogenes Verhältnis zwischen Fehlerkorrektur durch redundante
Datenübertragung und Fehlerverschleierung zu finden.
Auftretende zeitliche Störung, wie z.B. Jitter und Übertragungsverzögerungen, können zu
zeitlichen Verschiebungen zwischen abhängigen Elementen und somit zum
Synchronisationsverlust führen. Die zeitlichen Störungen müssen also mit geeigneten
Mechanismen ausgeglichen werden.
Da auch die Ordnung der Daten während des Übertragungsprozesses gestört werden kann,
sollten die eintreffenden Daten anhand ausgewählter eindeutiger Parameter sortiert werden.
3.2.2. Multimediadaten
Die Verifikation bestehender Kodierungsstandards für multimediale Inhalte, in Bezug auf
die spezielle Problematik, ist eine der wichtigsten Grundlagen für die Entwicklung des
Systems.
Es muss ein Kodierverfahren gewählt werden, dass eine Multimediasequenz in unabhängig
verteilbare Datenströme zerlegen kann.
Die Multimediasequenz muss leicht an die Übertragungskapazität, und an die speziellen
Eigenschaften jedes Endgeräts angepasst werden können.
Die heute geläufigste Lösung für die Anpassung der Datenströme an die Güte des
Übertragungskanals bzw. die Endgeräteeigenschaften, ist die Transkodierung der
multimedialen Informationen an Verteilerknoten. Diese Lösung ist für Netze ohne
Infrastruktur und ohne leistungsstarke Verteilerknoten nicht realisierbar, da die
Netzwerkknoten nicht über die notwendigen Rechenkapazitäten verfügen.
Der Kodier-/Dekodiervorgang kann für die Daten deshalb genau einmal durchgeführt
werden. Eine der wichtigsten Anforderungen an das Kodierverfahren ist somit die
Möglichkeit der zeitlichen, räumlichen und SNR-skalierbaren Kodierung.
Der kodierte Datenstrom muss aufgrund der unsicheren Transportkanäle sehr fehlertolerant
und fehlerrobust sein. Der Datenstrom muss eine definierte Struktur besitzen, sodass
Fehler leicht erkannt werden können.
19
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
In einer Transportdateneinheit dürfen nur vollständig kodierbare, multimediale Elemente
enthalten sein. Somit existieren keine Abhängigkeiten zwischen Informationen
aufeinanderfolgender Transportdateneinheiten.
Die Kodierung von Multimediamaterial bleibt leistungsstarken Netzwerkknoten (z.B.
Laptop) vorbehalten.
Der Dekodiervorgang darf nur eine geringe Rechenkapazität fordern.
Bei der Auswahl eines geeigneten Kodierverfahrens muss darauf geachtet werden, dass das
Verfahren standardisiert ist, da nur so eine weit reichende Akzeptanz für das zu
entwickelnde System zu erwarten ist.
3.2.3. Endgeräte
Aufgrund der enormen Varianz der Eigenschaften der Endgeräteklassen, nehmen die
Endgeräte einen großen Einfluss auf die Wahl eines geeigneten Kodierverfahrens.
Um den Darstellungsmöglichkeiten aller Endgeräte gerecht zu werden, müssen folgende
standardisierte Videoauflösungen bereitgestellt werden:
Parameter
Horizontale
Auflösung
Vertikale Auflösung
Sub-QCIF
QCIF
CIF
4CIF
16CIF
128
96
176
144
352
288
704
576
1408
1152
Tabelle 2: Übersicht über geforderte visuelle Auflösungen (in Pixel)
Die wichtigste Anforderung der Endgräte an eine kodierte Multimediasequenz ist deshalb
die räumliche Skalierbarkeit.
Zusätzlich ist darauf zu achten, dass die Rechenkapazitäten der Endgeräte beim
Dekodiervorgang ausreichend sind.
Die Darstellung auditiver Informationen ist durch die Endgeräte einkanalig (mono),
zweikanalig (stereo) oder mehrkanalig (z.B. 5.1) möglich. Für die Entwicklung des
Systems soll jedoch die 2-kanalige Wiedergabe ausreichend sein.
Die Speicherkapazitäten der Endgeräte definieren eine feste Schranke für die Speicherung
multimedialer Inhalte. Diese Schranke hat damit eine direkte Auswirkung auf die
Bereitstellungsmöglichkeit von Multimediasequenzanteilen eines Netzwerkknotens für
nachfolgende Teilnehmer. Die Schranke muss so definiert werden, dass keine
Beeinträchtigungen für das bereitstellende Endgerät auftreten.
20
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
4. Entwurf
Der Entwurf beschreibt die grundlegende Netzwerkstruktur des Systems, die Aufgaben der
Netzwerkknoten und den Verteilungsprozess der multimedialen Daten.
Voraussetzung für den Entwurf ist ein Kodierverfahren, das skalierbar kodierte
Datenströme einer Multimediasequenz erzeugen kann.
4.1. Netzwerkstruktur
Als Grundlage dient ein WLAN-Netzwerk im Adhoc-Modus. Damit steht ein dynamischer
Netzwerktyp mit den beschriebenen Anforderungen zur Verfügung. Über den eingesetzten
WLAN-Standard soll keine spezielle Aussage getroffen werden. Der Systementwurf wird
allgemeingültig für alle aktuellen und zukünftigen WLAN-Standards, die den AdhocModus unterstützen konzipiert.
Eine Erweiterung des Konzepts auf andere dynamische Netzwerktypen (z.B. Bluetooth)
sollte einfach realisierbar sein.
4.2. Netzwerkknoten
Grundlegend werden zwei Typen von Netzwerkknoten unterschieden.
Eine
Hauptquelle
stellt
als
Ursprungsknoten
neue,
skalierbar
kodierte
Multimediainformationen im Netzwerk bereit. Die Multimediainformationen werden als
Livestream neu erzeugt, oder sie werden von einem Speicher zur Verfügung gestellt.
Der zweite Netzwerkknotentyp enthält keine Funktionalitäten, um neue Medien zu
erstellen. Netzwerkknoten dieser Art nutzen einerseits bereitgestellte, multimediale Inhalte,
und sie stellen diese Daten andererseits nachfolgenden Netzwerkknoten zur Verfügung.
Sie können somit gleichzeitig als Dienstnutzer und als Diensterbringer auftreten. Diese
Knoten werden als Verteilerquellen bezeichnet.
Netzwerkknoten können als Hauptquelle und/oder als Verteilerquelle auftreten.
4.3. Verteilung
Die Verteilung der Informationen wird in zwei Abschnitte gegliedert.
Im ersten Abschnitt werden die Multimediadaten von der Hauptquelle erzeugt und zu den
ersten, empfangenden Netzwerkknoten (Verteilerquelle der ersten Stufe) transportiert.
Diese Verteilung erfolgt mit den klassischen Single-Source-Streaming-Mechanismen.
21
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Verteilerquellen nutzen die Informationen für eine lokale Darstellung und geben sie im
zweiten Verteilungsabschnitt an nachfolgende Verteilerquellen weiter. Da die
Multimediainformationen skalierbar kodiert wurden, bestehen sie aus mehreren,
unabhängig transportierbaren Datenströmen. Einzelne Datenströme können von
Verteilerquellen der zweiten Verteilungsstufe bei mehreren unterschiedlichen
Verteilerquellen des ersten Verteilungsabschnitts angefordert werden. Im zweiten
Verteilungsabschnitt wird der klassische Single-Source-Streaming-Mechanismus zu einem
neuen Multisource-Streaming-Ansatz erweitert. Diese Art der Verteilung ermöglicht
vollkommen neue Strategien für Fehlerkorrekturmechanismen und eine bedeutend
effizientere Ausnutzung der verfügbaren Kanalkapazitäten. Erst mit diesem Mechanismus
können die im Abschnitt 3 gestellten Anforderungen an den Verteilungsdienst für
Multimediainformationen erfüllt werden.
Die folgende Skizze stellt den Verteilungsverlauf grafisch dar:
Abb. 9) Entwurf des Verteilernetzwerks des Multisource-Streaming-Ansatzes
22
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
5. Spezifikation
In diesem Kapitel werden die Architekturen und die Komponenten der Hauptquelle und
der Verteilerquelle näher dargestellt. Für den Verteilungsvorgang werden die Aufgaben der
einzusetzenden Kommunikations- und Transportprotokolle spezifiziert.
5.1. Hauptquelle
Wie bereits im Entwurf beschrieben, hat die Hauptquelle die Aufgabe, skalierbar kodierte
Multimediasequenzen
im
Netzwerk
als
Ursprungsknoten
bereitzustellen.
Multimediasequenzen werden von der Hauptquelle entweder in Form eines Livestreams
neu erzeugt oder von einem Speichermedium zur Verfügung gestellt. Die Bereitstellung
der Multimediadaten am Stream-Server muss somit über zwei Wege gewährleistet werden.
Für die Bereitstellung der multimedialen Daten über einen Livestream werden die
Komponenten Aufnahmegerät(e), Encoder und Stream-Server benötigt.
Sollen die Daten vom lokalen Speicher der Hauptquelle verfügbar gemacht werden, so
muss zusätzlich zum lokalen Speicher ein Transformator eingesetzt werden.
Da die Verteilung der multimedialen Informationen über ein hochdynamisches, drahtloses
Netzwerk erfolgt, sind Fehlerschutzmechanismen bzw. Zufügen von Redundanz
erforderlich.
Abb. 10) Architektur der entworfenen Hauptquelle
Der Server ist letztendlich für die Verteilung der Multimediadaten verantwortlich.
23
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Abb. 10) stellt die grundlegende Architektur und die Komponenten der Hauptquelle
dar.
5.1.1. Aufnahmegeräte
Für die Erzeugung eines Livestreams wird mindestens ein Aufnahmegerät benötigt, das die
realen, audiovisuellen Objekte auf digitale, zunächst unkomprimierte Signale abbildet.
Aufnahmegeräte sind meistens digitale Kameras und Mikrofone. Es können natürlich auch
analoge Aufnahmegeräte verwendet werden. Der Einsatz analoger Technik erfordert
jedoch zusätzlich einen nachgeschalteten Analog-Digital-Wandler.
5.1.2. Encoder
Die Übertragung unkomprimierter Daten erfordert Ressourcen, die durch ein AdhocNetzwerk heute nicht bereitgestellt werden können. Deshalb ist es notwendig die
multimedialen Informationen zu komprimieren (siehe Abschnitt 2.2). Die
Datenkompression wird durch einen Encoder vorgenommen. Die Kodierung der
multimedialen Informationen erfolgt dabei skalierbar. Eine skalierbar kodierte
Multimediasequenz besteht aus mehreren unabhängig transportierbaren Datenströmen. Die
empfängerseitige Wiedergabeeinheit kann die Multimediasequenz, angepasst an die
verfügbaren Ressourcen, aus den Datenströmen zusammensetzen und darstellen. Die
Anpassung ist einfach möglich, indem eine Teilmenge der unabhängigen Datenströme der
originalen Multimediasequenz für den Dekodiervorgang benutzt wird.
Die Funktionalität des Encoders ist vom ausgewählten Kodierverfahren abhängig.
5.1.3. Transformator
Wenn skalierbar kodierte multimediale Daten durch einen lokalen Speicher der
Hauptquelle bereitgestellt werden, so müssen sie für den Streamvorgang vorbereitet
werden. Die Daten liegen nicht direkt auf dem Speicher, sondern sind meistens innerhalb
definierter Containerformate (Files) abgelegt. Der Transformator hat die Aufgabe, die
Daten aus den Containerformaten auszulesen und für den Stream-Vorgang in ein
definiertes Stream-Format zu überführen. Die Transformationsfunktion ist vom
Containerformat der gespeicherten Daten und vom Format der Transporteinheiten (z.B.
UDP-, TCP-, RTP-Pakete) für die Datenübertragung abhängig. Transformatoren für
verschiedene Transportprotokolle und Fileformate sind als sog. Hinting-Tools verfügbar.
24
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
5.1.4. Absicherung vor Übertragungsfehlern
Die komprimierten bzw. transformierten multimedialen Daten werden durch
Fehlerschutzmechanismen und Zufügen von Redundanz für die Übertragung im
hochdynamischen, verlustbehafteten, drahtlosen Netzwerk vorbereitet. Der Empfänger
kann durch diese zusätzlichen Informationen Fehler erkennen und gegebenenfalls
korrigieren. Die Güte für die Fehlererkennung bzw. die Korrekturfähigkeit ist vom
eingesetzten Fehlerschutzmechanismus abhängig.
Die Absicherung der Daten wird für den gesamten Verteilungsvorgang nur einmalig durch
die Hauptquelle vorgenommen. Verteilerquellen können keine zusätzlichen
Schutzmaßnahmen ergreifen.
5.1.5. Server
Der Server der Hauptquelle kann in die drei Komponenten Steuerprotokoll-Server, StreamServer und Linkmanager unterteilt werden.
Durch den Stream-Server der Hauptquelle werden die komprimierten Multimediadaten
einmalig mit den wichtigen Zeitinformationen zu Transportdateneinheiten verknüpft und
mit Fehlerschutzinformationen versehen. Die Transportdateneinheiten sind mit einem
eindeutigen, fortlaufenden Identifikator (z.B. Sequenznummer) gekennzeichnet. Die
Zeitrelevanzen und die Identifikatoren sind während des Verteilungsvorganges durch
Verteilerquellen nicht veränderbar. Nur so ist die Synchronisation abhängiger
multimedialer Elemente auch bei mehrfacher Verwendung und Verteilung der Daten
möglich.
Auf welche Art die Transportdateneinheiten in die Transportpakete verpackt werden
bestimmt das eingesetzte Transportprotokoll. Günstig ist hier, für jede kleinste, unabhängig
dekodierbare Einheit einer Multimediasequenz genau ein Transportpaket zu erzeugen. So
führt ein Paketverlust immer nur zum Verlust einer kleinsten Multimediaeinheit.
Fehlerkorrektur- bzw. Fehlerverschleierungstechniken können den Paketverlust auf einen
minimalen Darstellungsfehler reduzieren.
Der Steuerprotokoll-Server nimmt asynchron eintreffende Clientanfragen entgegen. Er ist
für die Beschreibung bzw. die Bekanntmachung der verfügbaren Multimediasequenzen der
Hauptquelle verantwortlich. Steuerbefehle für den Stream-Vorgang werden vom
Steuerprotokoll-Server an den Stream-Server weitergegeben.
Der Linkmanager überwacht kontinuierlich die Kanalkapazität. Er entscheidet, in
Abhängigkeit zu den aktuell verfügbaren Ressourcen, ob neue Clientanforderungen vom
Stream-Server bedient werden können, ohne bereits laufende Streamvorgänge zu stören.
25
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
5.1.6. Schnittstellen
Die Schnittstellen der Hauptquelle können in interne und externe Schnittstellen gegliedert
werden. Die internen Schnittstellen beschreiben die Transportbeziehungen zwischen den
Komponenten in der Hauptquelle. Die externen Schnittstellen definieren den
Kommunikations- und Transportprozess zwischen der Hauptquelle und ihrer Umwelt.
Folgende interne Schnittstellen müssen in der Hauptquelle definiert werden:
•
Schnittstelle zwischen den Produzenten der multimedialen Rohdaten und dem
Encoder
•
Schnittstelle zwischen dem lokalen Speicher und dem Transformator
•
Schnittstelle zwischen Transformator und Fehlerabsicherung
•
Schnittstelle zwischen Encoder und Fehlerabsicherung
•
Schnittstelle zwischen Fehlerabsicherung und Stream-Server
Folgende externe Schnittstellen sind in der Hauptquelle erforderlich:
•
Schnittstelle zwischen Steuerprotokoll-Client und Steuerprotokoll-Server
•
Schnittstelle zwischen Stream-Client und Stream-Server
•
Schnittstelle zwischen Server-Linkmanager und Client-Linkmanager
Das Format der Schnittstellen ist von den einzusetzenden Kompontenten der Hauptquelle
abhängig. Eine Spezifikation der Schnittstellen kann somit erst nach der Auswahl der
Komponenten erfolgen.
26
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
5.2. Verteilerquelle
Die Verteilerquelle lässt sich in die Komponenten Client, Server, Puffer,
Wiedergabeeinheit und Managereinheiten einteilen. Die Architektur soll in der
nachfolgenden Grafik verdeutlicht werden. Die Informationsflüsse zwischen den
Komponenten werden bei der Vorstellung der Komponenten beschrieben.
Abb. 11) Architektur der spezifizierten Verteilerquelle
27
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
5.2.1. Wiedergabeeinheit
Die Wiedergabeeinheit der Verteilerquelle hat die Aufgabe, die eintreffenden Datenströme
zu synchronisieren, zu dekodieren und entsprechend ihrer zeitlichen Abhängigkeiten in
einer gemeinsamen Präsentation darzustellen. Der Wiedergabeeinheit müssen alle
Informationen über die Lokalität der multimedialen Datenströme bekannt sein. Bereits vor
der Anfrage nach Datenströmen sind die maximalen Ressourcenanforderungen für den
Dekodiervorgang, die Präsentationskomposition und die Darstellung der multimedialen
Informationen bekannt. Diese Ressourcenanforderungen werden mit den verfügbaren
lokalen Kapazitäten verglichen. Die wichtigsten Kapazitäten sind Rechengeschwindigkeit,
Speicherplatz und Darstellungsmittel (z.B. Auflösung des Displays). Nachdem der
Abgleich erfolgreich war, werden von der Wiedergabeeinheit Datenströme angefordert.
Diese Anfragen führen zu einem Kommunikationsprozess mit der Steuerprotokolleinheit
der Clientkomponente. Die eintreffenden Datenströme werden von der Clientkomponente
an den Puffer übergeben. Ab einem definierten Pufferfüllstand werden die Datenströme
aus dem Puffer ausgelesen und durch einen lokalen Streamprozess an die
Wiedergabeeinheit weitergegeben.
5.2.2. Client
Der Client lässt sich in die drei Funktionsabschnitte Steuerprotokoll-Client, Stream-Client
und Linkmanager unterteilen.
Der Steuerprotokoll-Client hat die Aufgabe, Datenstromanfragen von der
Wiedergabeeinheit entgegenzunehmen, in die Steuerprotokollsyntax zu transformieren und
Kommunikationsprozesse zu mehreren Komplementärstellen (Steuerprotokoll-Server) zu
starten. Vorausgesetzt wird, dass dem Steuerprotokoll-Client alle erreichbaren
Kommunikationspartner bekannt sind. Über den Kommunikationsprozess wird geprüft,
welcher Server als Diensterbringer verfügbar ist.
Hier wird ermittelt, welche Server die angeforderten Daten liefern können. Sind die
diensterbringenden Kandidaten festgelegt, wird vom Linkmanager die Kanalgüte für die
Übertragung der Daten von den jeweiligen Servern zum Client überprüft. Multimediale
Datenströme besitzen unterschiedliche Prioritäten. Der Linkmanager entscheidet welche
Server als Diensterbringer genutzt werden. Im Besonderen bestimmt der Linkmanager
welcher Server welche Datenströme zum Stream-Client übermitteln soll. Datenströme mit
hohen Prioritäten sollten bevorzugt über Kanäle mit einer hohen Kanalgüte transportiert
werden.
Zwischen
den
ausgewählten
Servern
und
dem
Stream-Client
werden
Transportverbindungen aufgebaut. Das einzusetzende Transportprotokoll hat die Aufgabe,
neben den multimedialen Informationen die Zeitrelevanzen der einzelnen Medienelemente
28
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
zu übertragen. Treffen die Datenströme am Stream-Client ein, so werden sie an den
Bereitstellungspuffer übergeben.
Während der Datenübertragung überprüft der Linkmanager kontinuierlich die Güte der
Transportkanäle. Für Daten mit hohen Prioritäten ist es möglich, während der
Transportsession eine redundante Steuerprotokollverbindung zu einem zweiten
Diensterbringer zu erhalten. Der Linkmanager überprüft auch diese Verbindungsqualität
und kann bei kontinuierlicher Verschlechterung einer aktuell genutzten
Transportverbindung eine neue Transportverbindung mit dem zweiten Diensterbringer
aufbauen. Danach wird die Datenübertragung auf die neue Transportverbindung
umgeschaltet. Der Linkmanager steht im ständigen Kontakt mit dem Puffermanagement.
Somit ist eine Flusskontrolle zwischen Stream-Client und Server realisierbar.
Der Stream-Client hat nicht nur die Aufgabe, Daten entgegenzunehmen und zum Puffer
bzw. zur Wiedergabeeinheit weiterzuleiten. Zusätzlich übernimmt er die Fehlererkennung
und Fehlersignalisierung für die eintreffenden Datenpakete.
Die Clientkomponente muss Mechanismen besitzen, um auf die hohe Dynamik des
Netzwerkes reagieren zu können. Mit
Hilfe
des
Steuerund
des
Transportkontrollprotokolls werden die ereignisabhängigen Informationen zwischen den
Kommunikationspartnern ausgetauscht. Den Diensterbringern können keine Informationen
über den korrekten Datenempfang übermittelt werden, da dieser Signalisierungsaufwand
das Netzwerk zu stark belasten würde. Verlässt der Client das Netzwerk bzw. fällt die
Kommunikationsverbindung zu diesem Netzwerkknoten aus, dann muss dieser Zustand
jedoch allen Diensterbringern kenntlich gemacht werden, damit sie die Datenübertragung
zu diesem Netzwerkknoten beenden. Deshalb signalisiert der Client kontinuierlich in
definierten (größeren) Abständen seine Präsenz. Bleiben die Signale beim Diensterbringer
aus, so beendet er den Kommunikationsprozess. Der Ausfall eines Diensterbringers ist für
den Client sehr leicht erkennbar, da er in diesem Fall keine Daten mehr von diesem
Diensterbringer erhält. Hier ist es erforderlich, ein optimales Zeitintervall für den
Umschaltvorgang des Clients vom ausgefallenen Diensterbringer zu einem neuen
Diensterbringer zu ermitteln. Die Wahl des Intervalls ist direkt von der Puffergröße für den
jeweiligen Datenstrom abhängig, da während des Ausbleibens der Daten kein
Pufferleerlauf auftreten darf.
5.2.3. Bereitstellungspuffer
Der Breitstellungspuffer dient zur Speicherung der multimedialen Daten, die von der
Wiedergabeeinheit einmal angefordert wurden. Erst durch diesen Puffer ist es einer
Verteilerquelle möglich, die empfangenen Daten als Diensterbringer zur Verfügung zu
stellen. Der Puffer kann als Pufferfeld angesehen werden. In jedem Feldelement werden
Teile von genau einem Datenstrom abgelegt. Die eintreffenden Transportdateneinheiten
29
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
eines Datenstroms werden anhand eindeutiger Identifikatoren sortiert im entsprechenden
Feldelement abgelegt. Die Speicherung vollständiger Datenströme wird aufgrund der
begrenzten Speichermöglichkeiten der Endgeräte nicht möglich sein und ist auch nicht
erforderlich. Die Daten werden als Rohdatenstrom, in Form vollständiger
Transportdateneinheiten im Puffer abgelegt. So sollen alle durch die Hauptquelle
eingetragenen Zeitrelevanzen der paketierten Medienelemente während des gesamten
Verteilungsprozesses unverändert bleiben. Ebenso kann der Teildatenstrom eines
Pufferfeldes direkt von der Stream-Server-Komponente ausgelesen und weitervermittelt
werden. Lediglich die Sende- und Empfangsadressen der Transportdateneinheiten müssen
von der Serverkomponente geändert werden. Es sind keine zusätzlichen Mechanismen
notwendig, um die Daten für den Weiterleitungsprozess vorzubereiten (z.B. neu zu
paketieren).
5.2.4. Puffermanager
Die Aufgaben des Puffermanagers können in drei Teilgebiete gegliedert werden. Die erste
Teilaufgabe besteht darin, die Füllstände der Pufferfelder zu kontrollieren. Werden
definierte Schwellwerte für einen Füllstand erreicht, so wird vom Puffermanager ein Event
kreiert und an den Linkmanager des Clients übermittelt. Der Linkmanager trifft dem
Ereignis entsprechende Entscheidungen für die Flusskontrolle.
Es können nicht endlos neue Daten im Puffer abgelegt werden, ohne alte Daten aus dem
Puffer zu entfernen. Mit einer Altersgrenze für die gepufferten Daten soll der
Puffermanager im zweiten Aufgabengebiet entscheiden, welche Daten aus dem Puffer
gelöscht werden können. Diese Altersgrenze ist für jedes Pufferfeldelement getrennt zu
ermitteln. Jeder in einem Pufferfeldelement abgelegte Datenstrom besitzt eine eigene
gültige zeitliche Relevanz für eine Mediensequenz. Zum Beispiel sind allgemeine
Beschreibungen (Metainformationen) für die gesamte Präsentationszeit gültig, während
einzelne Video- oder Audioelemente nach ihrem Erscheinen nicht mehr benötigt werden.
Jeder Datenstrom ist eindeutig durch einen Datenstromidentifikator gekennzeichnet. Um
jedoch einen Datenstrom im Pufferfeld zu finden, muss auch die Nummer des
Pufferfeldelements, in dem der Datenstrom abgelegt ist, bekannt sein.
Dazu besitzt der Puffermanager eine Zuordnungstabelle, in der die Relationen zwischen
Pufferfeldelementnummer und Datenstromidentifikator abgelegt sind. Zusätzlich werden in
dieser Tabelle kontinuierlich die Zeitrelevanzen der ältesten Transportdateneinheit und der
neusten Transportdateneinheit, für jeden Datenstrom eingetragen. Somit ist immer bekannt
welcher zeitliche Abschnitt des Datenstroms im Pufferfeldelement vorhanden ist. Mit
dieser Tabelle und durch eine Kommunikationsbeziehung zur Serverkomponente wird die
dritte Aufgabe des Puffermanagers realisiert. Nach einer Inhaltsanfrage des Servers
30
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
übergibt der Puffermanager alle Tabelleninformationen über die aktuell im Pufferfeld
enthaltenen Datenstromteile an den Server.
Der Server entscheidet nun, welche Datenstromteile vom Puffer gelesen werden sollen.
Zum Auslesen eines Datenstroms greift der Server einfach auf den Puffer mit der
Pufferfeldnummer zu, die dem Datenstrom entspricht.
5.2.5. Server
Der Server ist das Komplement des Clients. Auch er lässt sich in drei Funktionsabschnitte
Stream-Server, Steuerprotokoll-Server und Linkmanager unterteilen.
Der Steuerprotokoll-Server erwartet asynchron eintreffende Clientanfragen. Auf eine
Beschreibungsanfrage antwortet der Steuerprotokoll-Server mit Informationen über alle
Datenstromteile, die aktuell durch den Server streambar sind.
Die Datenstromteile werden durch den Datenstromidentifikator und die Zeitmarken der
ältesten und jüngsten Transportdateneinheit beschrieben.
Die Informationen über die gepufferten Datenstromteile erhält der Server durch eine
Kommunikationsbeziehung zum Puffermanager.
Der Linkmanager des Servers überprüft jeweils für die gestellten Clientanfragen, ob die
verfügbare Kanalkapazität für den Upstream-Vorgang ausreichend ist. Beim Einsatz eines
WLAN-Netzwerkes ist hier besonders darauf zu achten, dass der Upstream-Vorgang in
keiner Weise den Downstream-Vorgang eines Netzwerkknotens beeinflusst. Die
Linkmanager der Client- und der Serverkomponente müssen dazu kontinuierlich die
verfügbaren bzw. aktuell belegten Kanalkapazitäten untereinander abgleichen. Der
Downstream-Vorgang hat eine höhere Priorität als der Upstream-Vorgang. Von der
Clientkomponente geforderte Kanalkapazitäten haben somit immer Vorrang vor
Kapazitätsanforderungen der Serverkomponente.
Vom Steuerprotokoll-Server wird eine Beschreibung für alle aktuell verfügbaren
Datenstromteile an den Client geliefert.
Der Client entscheidet, welche Datenstromteile vom Stream-Server angefordert werden.
Der Stream-Server nimmt asynchron eintreffende Datenstromanforderungen entgegen. Die
Datenstromanforderung enthält den Datenstromidentifikator und die Zeitmarke für die
erste zu liefernde Transportdateneinheit.
Der Stream-Server muss nun das zum geforderten Datenstrom korrespondierende
Pufferfeldelement und die erste zu übertragende Transportdateneinheit ermitteln. Dazu
wird vom Server eine Anfrage an den Puffermanager gestellt. Der Puffermanager ermittelt
anhand seiner Zuordnungstabelle die zum Datenstromidentifikator korrespondierende
Pufferfeldelementnummer und mit Hilfe der Zeitmarke die Pufferstelle der ersten zu
31
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
übermittelnden Transportdateneinheit. Die Pufferfeldelementnummer und die Pufferstelle
werden vom Puffermanager an den Stream-Server zurückgeliefert. Der Stream-Server liest
die Transportdateneinheiten entsprechend den erhaltenen Informationen aus dem Puffer
aus und übermittelt sie an den Client.
Während des Upstream-Vorgangs überprüft der Linkmanager kontinuierlich die verfügbare
Upstream-Kapazität. Ist die Kapazität nicht mehr ausreichend, so wird der UpstreamVorgang abgebrochen.
Eine weitere Abbruchsituation des Upstream-Vorgangs kann durch die Dynamik des
Server-Netzwerkknotens und des Netzwerkes entstehen, in dem sich der Server aus dem
Netzwerk entfernt bzw. die Kommunikationsverbindung ausfällt.
5.2.6. Schnittstellen
Die Schnittstellen der Verteilerquelle sind in interne und externe Schnittstellen gegliedert.
Die internen Schnittstellen beschreiben die Kommunikations- und Transportbeziehungen
zwischen den Komponenten in der Verteilerquelle. Die externen Schnittstellen definieren
den Kommunikations- und Transportprozess zwischen der Verteilerquelle und ihrer
Umwelt.
Folgende interne Schnittstellen sind erforderlich:
•
Schnittstelle zwischen Client und Wiedergabeeinheit
•
Schnittstelle zwischen Client und Puffer
•
Schnittstelle zwischen Puffermanager und Client-Linkmanager
•
Schnittstelle zwischen Puffermanager und Puffer
•
Schnittstelle zwischen Puffermanager und Server
•
•
Schnittstelle zwischen Server und Puffer
Die internen Schnittstellen werden durch die Funktionalität und die Struktur der
miteinander verbundenen Komponenten definiert.
Folgende externe Schnittstellen sind erforderlich:
•
Schnittstelle zwischen Steuerprotokoll-Client und Steuerprotokoll-Server
•
Schnittstelle zwischen Stream-Client und Stream-Server
•
Die externen Schnittstellen werden durch die einzusetzenden Kommunikations- und
Transportprotokolle bestimmt.
32
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die nähere Spezifikation der Schnittstellen ist erst in der Implementierungsphase möglich,
in der die einzusetzenden Komponenten und Protokolle bekannt sind.
5.3. Datenstruktur
Die Datenstruktur wird durch das Transportprotokoll und das Kodierverfahren bestimmt.
Der Encoder erzeugt unabhängig dekodierbare Dateneinheiten und definiert deren
Zeitrelevanz. Innerhalb einer Transporteinheit können eine oder mehrere vollständige
Dateneinheiten übertragen werden. Eine Fragmentierung der Dateneinheiten während des
Transports ist nicht erlaubt. Die maximale Größe der Transporteinheit entspricht dem Wert
der MTU (Maximum Transfer Unit) des Transportkanals. Zusätzlich werden in jeder
Transporteinheit die Zeitrelevanzen der enthaltenen Dateneinheiten übertragen. Jede
Transporteinheit erhält eine eindeutige Sequenznummer, mit der die Ordnung und die
Vollständigkeit des Transportstromes fortlaufend überprüft werden können.
33
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6. Auswahl der Komponenten für die Implementierung
In diesem Kapitel erfolgt die Auswahl der verfügbaren Techniken und Komponenten, die
in der Implementierung verwendet werden.
Im Besonderen findet eine Untersuchung aktueller Standards zur Kodierung multimedialer
Informationen, eine Untersuchung verfügbarer Transport-, Transportkontroll- und
Steuerprotokolle und eine Analyse gegenwärtiger Hardware- und Softwarekomponenten
für den Kodier-, Verteilungs- und Dekodierprozess statt.
6.1. Untersuchung aktueller Standards zur Kodierung multimedialer
Informationen
Eine der Kernkomponenten dieser Arbeit ist die Untersuchung aktueller Kodierverfahren
für den Einsatz im neuen Multisource-Streaming-Ansatz. Hierbei werden die Standards der
„International Telecommunication Union“ (H.261, H.263) und der „Moving Picture Expert
Group“ (MPEG1, MPEG2 und MPEG4) zur Kodierung multimedialer Daten mit den
Erkenntnissen der Anforderungsanalyse, für die Wahl des geeigneten Kodierverfahrens
verifiziert.
6.1.1. H.261
H.261 ist ein Kodierstandard, der 1990 von der ITU für Videoübertragungen mit geringen
Bandbreiten entwickelt wurde.
Die betrachtete Bandbreite dieses Formats ist ein Vielfaches von 64 KBit/s, was darauf
zurückzuführen ist, dass H.261 ursprünglich für die Videotelefonie in ISDN-Netzen
entwickelt wurde. H.261 basiert auf der bidirektionalen DCT mit unidirektionaler
Bewegungskompensation und eignet sich speziell für die Kodierung in niedrigen
Datenraten bei relativ langsamen Bewegungen. Diese erste Implementierung eines DCTVideocodecs wurde der Ausgangspunkt für die Entwicklung der MPEG-Standards.
Insgesamt unterstützt dieser Standard zwei verschiedene Bildformate (CIF, QCIF).
Die skalierbare Kodierung von multimedialen Daten ist mit H.261 nicht möglich. Deshalb
kann dieses Kodierverfahren nicht in der Implementierung des neuen MultisourceStreaming-Ansatzes verwendet werden.
34
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.2. H.263
Bei H.263 handelt es sich um eine Weiterentwicklung des H.261-Standards, der 1995 von
der ITU veröffentlicht wurde. Mit H.263 wurde das Ziel verfolgt, unterhalb einer Datenrate
von 64 KBit/s eine bessere Darstellungsqualität zu erreichen. Das Kodierverfahren basiert
auf der bidirektionalen DCT und ermöglicht eine verbesserte Bewegungskompensation
gegenüber dem H.261-Standard.
Folgende Funktionserweiterungen wurden implementiert:
•
doppelte Genauigkeit der Bewegungsvektoren
•
bidirektionale Bewegungskompensation
•
zusätzlich wählbare visuelle Auflösungen (SQCIF, 4CIF, 16CIF).
H.263 wurde wie H.261 zur Videoübertragung in ISDN-Netzen entwickelt und ist daher
für geringe Datenraten konzipiert. Die Einführung der bidirektionalen
Bewegungskompensation bietet die Möglichkeit, höhere Kompressionsraten zu erreichen.
Implementierungen des Standards nutzen diese Art der Bewegungskompensation jedoch
nicht aus, da mit diesem Verfahren die Kodierung sehr rechenintensiv wird.
Auch H.263 bietet keine skalierbare Kodierung multimedialer Daten an und ist deshalb
nicht für den Einsatz in der Implementierung des neuen Multisource-Streaming-Ansatzes
geeignet.
6.1.3. Verifikation des MPEG1-Standards
MPEG1 wurde 1991 als erster Standard der „Moving Picture Expert Group“ für die
Kodierung von digitalen multimedialen Sequenzen veröffentlicht. Der Standard ist für die
Kodierung von visuellen Daten mit einer räumlichen Auflösung von 352:288 Pixeln bei 30
Bildern/s bzw. 352:240 Pixeln bei 25 Bildern/s vorgesehen.
MPEG1 wurde zur Speicherung multimedialer Sequenzen auf einer CD-ROM optimiert.
Eine „single Speed“-CD-ROM besitzt eine Transferrate von 1,4 MBit/s.
Entsprechend komprimiert MPEG1 einen zusammengehörenden Video- und Audiostrom
mit einer maximalen Datenrate von 1,4 Mbit/s.
Die Qualität einer MPEG1-Videosequenz ist mit der Qualität einer VHS-Kassette
vergleichbar.
Die Spezifikation des Standards untergliedert sich in drei Teile: MPEG1-Video, MPEG1Audio und MPEG1-System.
35
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.3.1. MPEG1 Video
Ein MPEG1-Videodatenstrom wird funktional, entsprechend der Abb. 12), hierarchisch in
sechs Ebenen unterteilt. Jede Ebene ist definiert strukturiert und besitzt ihren eigenen, klar
abgegrenzten Funktionsumfang.
Abb. 12) Struktur des MPEG1-Videostroms (Ref: [13] S. 136 Figure 8.1)
Die MPEG1-Videosequenz beginnt mit dem Sequenz-Header. Hier werden die Parameter
(Bildgröße, Framerate, Bitrate...) definiert, die für den gesamten Datenstrom gültig sind.
Der Sequenz-Header kann optional mehrmals in der Videosequenz enthalten sein. Diese
Wiederholungen werden durch die Funktionen Zufallswiedergabe und Videobearbeitung
gefordert. Auf den Sequenz-Header folgt mindestens eine Group of Picture. Das Ende der
Videosequenz wird mit dem Sequenz End Code signalisiert.
Die Group of Picture (GOP) definiert eine zusammengehörige Bildfolge. Sie erleichtert mit
implementierten Zeitinformationen und Editierparametern die Bearbeitung eines kodierten
Videostroms. Eine Group of Picture besteht aus einem GOP-Header und mindestens einem
Bild. Sie wird im GOP-Layer definiert.
Jedes Bild wird im Picture-Layer durch einen Picture-Header eingeleitet und besteht
mindestens aus einem Slice. Der Picture-Header enthält alle Parameter, die für das
jeweilige Bild eine lokale Gültigkeit besitzen.
Der Slice-Layer beschreibt die unterste Hierarchiestufe, die mit einem Startcode initiiert
wird. Mit diesen Startcodes werden Synchronisationspunkte geschaffen, durch die sich ein
Decoder bei Datenverlusten oder Datenfehlern schnell resynchronisieren kann. Ein Slice
36
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
beschreibt aufeinander folgende Makroblöcke mit einem gleichen mittleren Grauwert.
Jeder Slice besteht aus einem Slice-Header und mindestens einem Makroblock. Der erste
Slice beginnt in der oberen linken Ecke des Bildes und der letzte Slice endet in der unteren
rechten Ecke. In MPEG1 muss das gesamte Bild durch Slice’s gefüllt werden.
Die Abb. 13) zeigt beispielhaft eine Slicefolge eines Bildes.
Makroblöcke sind die Bezugsgrößen für die Bewegungskompensation und die
Bewegungsabschätzung. Die Kodierung der Blöcke wird im Block-Layer definiert. Ein
Makroblock besteht aus einem Makroblock-Header und entsprechend der Abb. 14) aus
sechs DCT-Blöcken. Jeder DCT-Block enthält 8x8 quantisierte und VL-kodierte
Abtastwerte eines Bildausschnitts (siehe Vorbetrachtung). Blöcke sind die
Transformationseinheit der zweidimensionalen Diskreten-Cosinus-Transformation.
Abb. 13) Slicestruktur eines MPEG1-Frames
Abb. 14) Blocknummerierung im MPEG1
Chromaformat 4:2:0
Die Definitionen für die vorgestellten Elemente des MPEG1 Videostroms können in [31]
nachgelesen werden.
6.1.3.2. MPEG1 Audio
In der Vorbetrachtung wurde der MPEG-Audio-Standard bereits vorgestellt. MPEG1
unterstützt das ältere Kodierverfahren mit den Layern 1, 2 und 3.
Weitere Informationen über den MPEG1 Audio Standard erhält man in [32].
37
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.3.3. MPEG1 System
Eine Multimediasequenz besteht normalerweise aus Audio- und Videodaten. Die
multimedialen Daten benötigen Zeitinformationen, damit alle abhängigen Elemente
zeitlich synchron dargestellt werden können. Der MPEG1-System-Part fasst
zusammengehörende Video- und Audioströme in einem Systemdatenstrom zusammen. Die
Daten werden paketiert und in sog. Packs gebündelt. Folgende Abbildung stellt die
Struktur des Systemdatenstroms grafisch dar:
Abb. 15) Struktur des MPEG1-Systemstroms
Jeder Pack besteht aus einem Pack-Header, optional einem System-Header und einer
Sequenz von Packets. Der Pack-Header enthält, wie in der Abb. 16) dargestellt, einen
Zeitstempel, mit dem die Zeitbasis des Kodierprozesses vom Decoder rekonstruiert werden
kann. Die Größe eines Packs wird im Standard nicht festgelegt. Sie ist jedoch meistens an
die Sektorgröße eines Speichermediums angepasst.
Abb. 16) MPEG1-System Pack-Header
Der System-Header enthält zusätzliche Informationen über die Eigenschaften der im
Systemdatenstrom enthaltenen Video- und Audioströme. Die Struktur des Headers
beschreibt die folgende Abbildung.
38
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 17) MPEG1-System-Header
Das Packet ist die kleinste atomare Einheit des MPEG1-System-Parts. Es besteht aus
einem Header (siehe Abb. 18)) und einem Datenteil.
Abb. 18) MPEG1-Packetheader
Im Datenteil des Packets werden die kleinsten, einzeln dekodierbaren Elemente (Access
Units) einer Audio- oder Videosequenz übertragen. Eine Access Unit ist z.B. ein Bild einer
Videosequenz oder eine Folge von Samplewerten eines Audiodatenstroms. Um die
synchrone Darstellung abhängiger Video- und Audioelemente sicherzustellen, bekommt
jede Access Unit mindestens einen Zeitstempel. Man unterscheidet zwischen zwei
Zeitinformationen. Die Presentation Timestamp (PTS) beschreibt, wann eine Access Unit
im Wiedergabevorgang dargestellt werden muss. Die Decoding Timestamp (DTS) definiert
den Zeitpunkt, zu dem eine Access Unit für den Dekodiervorgang verfügbar sein muss.
Die funktionale Beschreibung der Headerelemente und erweiterte Informationen über den
MPEG1-System-Part erhält der Leser in [13] und in [30].
6.1.3.4. Einsatz von MPEG1 im spezifizierten Multisource-Streaming-Ansatz
Eine skalierbare Videokodierung und Audiokodierung ist in MPEG1 nicht vorgesehen und
auch nicht möglich. Eine unabhängige Verteilung eines Audiodatenstroms, getrennt vom
zugehörigen Videodatenstrom ist denkbar, wenn die Mediaströme jeweils in eigenständige
Systemdatenströme verpackt werden. Die notwendigen Synchronisationsinformationen
sind im Systemdatenstrom (Packetheader) integriert. Die Aufteilung der multimedialen
Daten in einen einzelnen Video- und einen einzelnen Audiodatenstrom ist für die
Forderung nach Skalierbarkeit der Multimediasequenz jedoch nicht ausreichend.
Fehlerbehandlung, bzw. Fehlerkorrekturmechanismen sind kein Teil des MPEG1Standards. Fehlerschutz muss auf der Anwendungsebene der Endgeräte bereitgestellt
39
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
werden. Aufgrund der fest definierten Struktur einer MPEG1-Videosequenz können Fehler
jedoch leicht erkannt werden. Ein MPEG1-Decoder erwartet während des
Dekodiervorganges immer eine definierte Bitfolge. Durch die Slice-Struktur der
Videosequenz bzw. die definierten Startcodes stehen viele Synchronisationspunkte zur
Verfügung, mit denen sich der Decoder im Fehlerfall schnell auf den Datenstrom
resynchronisieren kann. Eine flexible Anpassung der Multimediasequenz an
Übertragungskanäle und Endgeräte wird nicht unterstützt. Der Multisource-StreamingAnsatz über hochdynamische Netzwerke mit stark variierenden Endgeräten ist mit
MPEG1-kodierten Sequenzen nicht realisierbar.
Die Entwicklung von MPEG2 begann ab 1991 durch die CCITT (ITU-T). Für MPEG1
wurden, aufgrund der relativ geringen standardisierten Video-Auflösung, die Grenzen
erreicht, um die Bildqualität weiter zu verbessern. Höhere Auflösungen für digitales
Fernsehen, die Unterstützung von Interlaced Video, die Verteilung von
Multimediasequenzen über drahtgebundene Netzwerke, sowie erste Skalierbarkeitsansätze
in der Kodierung waren die Zielstellungen für die MPEG2-Entwicklung. Aufgrund der
höheren unterstützten Video-Auflösung ist MPEG2 hauptsächlich für den Einsatz in
Breitbandnetzen spezifiziert und benötigt leistungsfähige Endgeräte für die Dekodierung.
Als Erweiterung bzw. Verbesserung des MPEG2-Standards gegenüber dem MPEG1Standard sind zu nennen:
•
Verteilung von Multimediaströmen über Netzwerke
•
Genauigkeit des DC-Wertes ist steuerbar
•
variable Quantisierung mit kontinuierlicher Anpassung der Übertragungsrate an
die Qualität des Übertragungsmediums
•
höhere Auflösung (352x288 - 1920x1152) für Videosequenzen und damit
Unterstützung höherer Datenraten und größerer Empfangspuffer
•
verbesserte Fehlerrobustheit, Möglichkeit der Fehlerverschleierung
•
Übertragung von zusätzlichen Informationen innerhalb des Systemstroms
(Copyright, Display-Charakteristiken, ein Offset ermöglicht die Vorschau eines
Bildes in geringerer Auflösung)
•
innerhalb eines Systemstroms kann eine größere Anzahl von Video- und
Audioströmen gemultiplext werden, die nicht zwingend eine gemeinsame
Zeitbasis besitzen müssen
40
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
•
vier verschiedene Skalierungsmöglichkeiten zur Anpassung von Videoströmen an
die Güte unterschiedlicher Übertragungssysteme und die Kapazitäten heterogener
Endgeräte
•
Unterstützung mehrkanaliger Audiokodierung
Mit den Erweiterungen stieg die Komplexität für die Implementierung von MPEG2 an. Die
gesamte Syntax des MPEG2-Standards zu implementieren, ist für die meisten
Anwendungen nicht sinnvoll. Daher wurde in MPEG2 das Konzept der Profile und Level
eingeführt. Profile und Level definieren abgegrenzte Abschnitte des MPEG2-Standards.
Jedes Profil stellt modular eine bestimmte Funktionalität zur Verfügung. Ein Level legt
spezifische Wertebereiche für die Parameter eines Streams fest, z.B. Bildgröße, Framerate,
Bitrate usw. Im MPEG2-Standard werden fünf verschiedene Profile abgrenzt (Simple
Profile, Main Profile, SNR scalable Profile, Spatial scalable Profile, High Profile). Im
Anhang B ist ein Ausschnitt aus dem MPEG2-Standard, als Überblick über die Profile und
Level dargestellt.
Für den Multisource-Streaming-Ansatz sind die Profile SNR, Spatial, und High besonders
interessant. Sie bieten die Möglichkeit an, örtliche und zeitliche Skalierbarkeit für einen
Videostrom zu realisieren. Deshalb ist die Analyse dieser Profile tiefgründig erforderlich.
Da das Main-Profile jedoch die Grundlage für die skalierbaren Profile ist, wird zunächst
darauf näher eingegangen.
6.1.4.1. MPEG2 (Main-Profile) - Video
Die Syntax und die Struktur einer Videosequenz, gemäß dem Main-Profile des MPEG2Standards, entspricht grundlegend dem MPEG1-Ansatz. So soll die Abwärtskompatibilität
von MPEG2 zu MPEG1 sichergestellt werden.
Abb. 19) Kompatibilität zw. MPEG1 und MPEG2 Video (Referenz: [14] S.183)
Auch die MPEG2-Videosequenz wird in sechs Hierarchiestufen aufgeteilt. Der SequenzLayer ist die oberste Hierarchiestufe und beginnt mit dem Sequenz-Header. Hier werden,
wie in der MPEG1-Struktur, die Parameter definiert, die für die gesamte Bildsequenz bis
zum nächsten Sequenz-Header gültig sind. Nach dem Sequenz-Header kann entweder eine
MPEG1-konforme Videosequenz folgen (siehe Abb. 19), oder aber der Beginn einer
MPEG2-Videosequenz durch eine Sequenz Extention signalisiert werden. Nach der
Sequenz Extention folgt optional eine Group of Picture (GOP) oder direkt ein Bild (IVerfasser: Holger Kärst
41
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Frame, P-Frame). In einer MPEG2-Videosequenz muss ein Bild nicht unbedingt einer
Group of Picture angehören. Das Ende der Sequenz wird durch den Sequenz End Code
signalisiert.
Eine durch den GOP-Header signalisierte Group of Picture, muss mindestens ein Bild
enthalten. Das erste Bild dieser GOP ist immer ein I-Frame. Nach dem GOP-Header
können optional Nutzerdaten implementiert werden.
Die Bilder einer GOP werden im Picture-Layer definiert und mit einem Picture-Header,
einer optionalen Picture Coding Extension und optionalen Extension And User Data
beschrieben. Jedes Bild besteht aus mehreren Slice’s.
Bei MPEG2 gilt die Einschränkung, dass ein Slice eine Bildzeile (Makroblockreihe) nicht
überschreiten darf. Damit wurde die Fehlerrobustheit von MPEG2-kodierten
Videosequenzen gegenüber Sequenzen des MPEG1-Standards verbessert.
Die Makroblöcke bestehen aus mindestens sechs Blöcken mit jeweils 8x8 Abtastwerten.
Für das Luminanzsignal werden vier 8x8 Blöcke kodiert. Beim Chrominanzsignal
unterscheidet man im MPEG2-Standard drei Chroma-Formate (4:2:0, 4:2:2, 4:4:4).
Während für das Chroma-Format 4:2:0 zwei Blöcke für die Aufnahme der
Chrominanzsignale ausreichen, werden beim 4:2:2 Chroma-Format vier und beim 4:4:4
Chroma-Format sechs Blöcke für die Kodierung der Farbinformationen benötigt.
Die hierarchische Struktur der Videosequenz ist in der folgenden Abbildung grafisch
dargestellt.
Abb. 20) Struktur einer MPEG2-Videosequenz (Referenz: [14] S.183)
42
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.4.2. Skalierbarkeit von Videosequenzen im MPEG2-Standard
Grundsätzlich werden im MPEG2-Standard vier verschiedene Möglichkeiten für eine
skalierbare Kodierung bereitgestellt: Data Partitioning (Datenaufteilung), SNR Scalability
(Qualitätsskalierung), Spatial Scalability (räumliche Skalierung) und Temporal Scalability
(zeitliche Skalierung). Die Kombination verschiedener Skalierungsmöglichkeiten wird mit
hybrider Skalierung bezeichnet.
Spatial Scalability (räumliche Skalierung)
Der MPEG2-Encoder erzeugt aus einer Videosequenz zwei kodierte Bitströme mit
Bildinformationen unterschiedlicher räumlicher Auflösungen. Der Basisstrom enthält
Bildinformationen mit einer kleinen Mindestauflösung. Diese Auflösung wurde durch eine
Unterabtastung der Bildinformationen des Quellvideostroms erzeugt. Der Bitstrom der
Erweiterungsschicht überträgt die Differenz zwischen dem originalen, hoch aufgelösten
Bild und dem in der Basisschicht kodierten, niedrig aufgelösten Bild als
Zusatzinformation.
Beide Datenströme können unabhängig von einander übertragen werden.
Nutzt der Decoder des Empfängers nur die Informationen des Basisstroms, dann wird die
Videosequenz in einer niedrigen Auflösung wiedergegeben. Die gemeinsame Dekodierung
der Basis- und der Erweiterungsströme erlaubt die Wiedergabe der Videosequenz in der
originalen Auflösung.
Die Bewegungskompensation erfolgt in beiden Hierarchiestufen. In der
Erweiterungsschicht werden die Differenzen zwischen aufeinanderfolgenden Bildern für
die Bewegungskompensation genutzt. Zusätzliche Informationen erhält der Decoder durch
räumliche Prädiktionen aus Bildern der Basisschicht.
SNR Scalability
SNR-skalierbare Kodierung erzeugt aus einem Quellvideostrom zwei Bitströme mit der
gleichen räumlichen Auflösung, jedoch mit unterschiedlichen visuellen Qualitäten. Dazu
wurde eine Strategie entwickelt, mit der die DCT-Koeffizienten der Basisschicht durch
zusätzliche Informationen der Erweiterungsschicht verfeinert werden können. Die
Quantisierungsfehler, die beim Kodierprozess des Basisdatenstromes entstehen, werden als
Zusatzinformation im Erweiterungsstrom kodiert und transportiert. Die Quantisierung des
Videomaterials für die Basisschicht erfolgt entsprechend den Quantisierungstabellen des
Main-Profiles. Für die Berechnung der entstandenen Quantisierungsfehler wird das
quantisierte Bild requantisiert und vom Originalbild subtrahiert.
Die Bewegungskompensation wird nur in der Basisschicht vorgenommen.
Der Decoder des Empfängers requantisiert den Bitstrom der Basisschicht. Erhält der
Decoder die zusätzlichen Informationen des Erweiterungsdatenstroms, so kann er den
Quantisierungsfehler der DCT-Werte aus der Basisschicht verkleinern und damit die
43
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Bildqualität erhöhen. Die Dekodierung des Bitstroms der Basisschicht ist auch ohne die
Informationen der Erweiterungsschicht möglich, jedoch mit einer schlechteren
resultierenden Bildqualität.
Der Dekodiervorgang wird in der folgenden Abbildung dargestellt.
QFS [n]
Variable
Length
Decoding
Coded
Data
QF [v][ u ]
Inverse
Scan
F'' lower [v][ u]
Inverse
Quantisation
Arithmetic
Lower Layer
QFS [n]
Enhancement Layer
Coded
Data
Variable
Length
Decoding
Σ
QF [v][ u ]
Inverse
Scan
Inverse
Quantisation
Arithmetic
F'' [ v][u]
F'' enhance [v ][u]
Framestore
Memory
F' [v][u]
Saturation
F[v ][u]
Mismatch
Control
Inverse
DCT
Motion
Compensation
f[y ][ x]
Decoded
Pels
d [y][ x ]
Abb. 21) Dekodierung einer SNR-skalierbar codierten MPEG2-Videosequenz (Ref: [16] S.107)
Das Verfahren Chroma Simulcast beschreibt die zweite Möglichkeit für eine SNRskalierbare Kodierung. Hierbei kann ein 4:2:0 Chroma-Format des Basisstromes durch
zusätzliche Informationen des Erweiterungsstromes in ein 4:2:2 Chroma-Format verbessert
werden. Die Chrominanzinformationen (DC-, AC-Werte) der Basisschicht werden durch
neue Informationen aus der Erweiterungsschicht ersetzt, die eine höhere Auflösung haben.
Es wird vorausgesetzt, dass korrespondierende Bilder beider Schichten die gleiche
Zeitrelevanz besitzen (PTS und DTS Werte der Access Units beider Schichten müssen im
Systemdatenstrom identisch sein). Die Möglichkeiten des Einsatzes von Chroma Simulcast
zeigt die folgende Tabelle.
chroma_format
(lower layer)
4:2:0
4:2:0
4:2:0
4:2:2
4:2:2
4:4:4
chroma_format
(enhancement layer)
4:2:0
4:2:2
4:4:4
4:2:2
4:4:4
4:4:4
chroma_simulcast
0
1
1
0
1
0
Tabelle 3: SNR-Skalierbarkeit durch Chroma Simulcast Referenz: [16] S.109
44
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Temporal Scalability
Die zeitliche Skalierung wird in den Profilen SNR und High eingesetzt. Der Encoder
erzeugt aus einem Quellvideostrom zwei Datenströme mit unterschiedlichen
Bildwiederholraten.
Der Basisstrom überträgt die Videosequenz in einer definierten, niedrigen
Bildwiederholrate. Der Erweiterungsstrom enthält zusätzliche Bilder. Werden Basis- und
Erweiterungsstrom beim Empfänger zeitlich remultiplext, so entsteht die Videosequenz mit
der vollen Bildwiederholrate.
Für P- und B-Frames sind dabei Referenzen auf vorangehende bzw. rückwärtige Bilder
innerhalb und zwischen den Datenströmen erforderlich.
Diese Referenzen werden mit dem folgenden dargestellten Erweiterungsheader kodiert.
Abb. 22) Picture temporal scalable extension
Folgende Referenzen von P- bzw. B-Frames sind möglich:
Referenzen für P-Frames:
reference_select_code
00
01
10
11
forward prediction reference
gerade kodiertes Bild aus der
Erweiterungsschicht
gerade kodiertes Bild aus der Basisschicht
Nächster Frame der Basisschicht in Display
Order
verboten (entspricht I-Pict.)
Tabelle 4: Referenzen für zeitlich skalierte P-Frames des MPEG2-Standards Referenz: [16] S. 113
Referenzen für B-Frames:
reference forward prediction
select_code reference
backward prediction reference
00
verboten
verboten
01
gerade kodiertes Bild aus
der Erweiterungsschicht
gerade kodiertes Bild der
Basisschicht in Display Order
gerade kodiertes Bild aus
der Erweiterungsschicht
gerade kodiertes Bild der
Basisschicht in Display
Order
nächstes kodiertes Bild der
10
11
nächstes kodiertes Bild der
Tabelle 5: Referenzen für zeitlich skalierte B-Frames des MPEG2-Standards Referenz: [16] S. 114
45
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Im Erweiterungsstrom können I-, P- oder B-Frames übertragen werden, wobei sich hier BFrames wie P-Frames verhalten, da Verweise auf rückwärtige Bilder im
Erweiterungsstrom nicht erlaubt sind. Durch diese Einschränkung wird verhindert, dass
Bilder des Erweiterungsstroms umsortiert werden müssen.
Die Abb. 23) stellt die zeitliche Skalierung einer visuellen Mediasequenz dar.
Abb. 23) Temporal Scalability
Data Partitioning
Die Daten eines Videostromes werden mit Data Partitioning, entsprechend der Abb. 24),
in zwei Partitionen aufgeteilt. Der im Slice-Header optional angegebene Priority
Breakpoint kennzeichnet, welche Elemente des Stroms in die Partition 0 (Basisstrom mit
hoher Priorität) und welche Elemente in die Partition 1 (Erweiterungsstrom mit niedriger
Priorität) eingeordnet werden. Ist der Priority Breakpoint während der Partitionierung
veränderbar, so können die Datenraten der beiden Partitionen flexibel an die Qualität eines
Übertragungskanals angepasst werden. Für eine Fehlerkorrekturmöglichkeit werden
Sequence-, GOP- und Picture-Header, sowie der Sequence End Code redundant in beiden
Partitionen übertragen. Data Partitioning ist bisher keinem MPEG2-Profil zugeordnet.
Quant
Scale
DC
coeff
1
DCT
DCT
DCT
coeff 1 coeff 2 coeff 3
EOB
DC
coeff
Quant
Scale
DC
coeff
DCT
coeff 1
DC
coeff
DCT
coeff 1
2
DCT
coeff 1
EOB
Partition 0
4
3
DCT
DCT
coeff 2 coeff 3
EOB
EOB
Partition 1
Abb. 24) Data Partitioning (Ref: [16]S. 119)
46
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Hybrid Scalability
Die hybride Skalierung beschreibt den kombinierten Einsatz zweier verschiedener Typen
der Skalierbarkeit. Hierbei entstehen drei hierarchisch aufeinander aufbauende Schichten.
Man unterscheidet folgende drei Varianten für den kombinierten Einsatz verschiedener
Skalierungsmechanismen:
Basisschicht
Erweiterungschicht 1
Erweiterungschicht 2
Basisdatenstrom
Spatial or
Temporal
Scalability
SNR Scalability
Basisdatenstrom
SNR Scalability
Spatial or
Temporal
Scalability
Basisdatenstrom
Spatial or
Temporal
Scalability
Spatial or
Temporal
Scalability
Tabelle 6: Möglichkeiten der hybriden Skalierbarkeit in MPEG2
6.1.4.3. MPEG2 Audio
Der MPEG2-Audio-Standard unterstützt zwei grundlegend verschiedene Kodierverfahren.
Das Erste ist eine abwärtskompatible Erweiterung des MPEG1-Audio-Standards. Die
Grundlagen der drei MPEG1-Layer (siehe Vorbetrachtungen) wurden in den MPEG2Standard übernommen. Im Wesentlichen wurde der Audio-Standard um funktionale
Elemente, wie die Unterstützung von Mehrsprachigkeit und Surround Sound erweitert.
MPEG2 unterstützt nun 5 vollwertige Audiokanäle, die für Surround Sound (links vorne,
links hinten, rechts vorne, rechts hinten und Mitte) oder für multilinguale Soundtracks
genutzt werden können. Außerdem sind zwei Erweiterungskanäle für Audiosignale mit
niedrigen Frequenzen (15-120Hz) verfügbar. In MPEG2 ist es auch möglich, die halbe
Abtastrate für die Erzeugung der Abtastwerte der Audiofrequenzen zu benutzen.
Sampleraten von 16 KHz, 22,05 KHz und 24 KHz sind zusätzlich zu den MPEG1Abtastraten von 44 KHz und 48KHz in jedem Layer erlaubt.
Um zum MPEG1-Standard konform zu bleiben, wurde die grundlegende Struktur des
Audioframes beibehalten. Über Multichannel Extension können die zusätzlichen
Audiokanäle des MPEG2-Audio-Standards in dem Audioframe implementiert werden.
47
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Der Audioframe hat die folgende Struktur:
Abb. 25) Struktur eines zu MPEG1 kompatiblen MPEG2 Audioframes
Der zweite Abschnitt des MPEG2-Audio-Standards definiert das neue MPEGKodierverfahren Advanced Audio Coding (AAC), das bereits in den Vorbetrachtungen
erläutert wurde.
6.1.4.4. MPEG2 System
In einen MPEG2-Systemstrom werden mehrere Audio- und Videoströme zu einem
kontinuierlichen Bitstrom gemultiplext. Jeder elementare Audio- bzw. Videostrom stellt
selbst einen kontinuierlichen Bitstrom aus Bildern oder Audiosegmenten dar. Aufgrund der
variablen Lauflängenkodierung benötigen einzelne Bilder unterschiedliche Transportzeiten
für die Übertragung. Deshalb werden elementare Ströme paketorientiert innerhalb eines
Packetized Elementary Stream (PES) übertragen. Ein PES-Paket ist, wie in der Abb. 26)
dargestellt aufgebaut.
48
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 26) Struktur des MPEG2 Packetized Elementary Stream (Referenz: [14] S. 223)
Das PES-Paket wird über einen einheitlichen Packet Start Code initiiert.
Die Stream-ID identifiziert den Typ und die eindeutige Nummer eines elementaren Videooder Audiostroms innerhalb des Systemdatenstroms.
Über das Headerfeld PES Priority des optionalen PES Headers ist es möglich, jedem PESPaket eine Priorität zuzuordnen. Man unterscheidet zwischen zwei Prioritätsstufen. Die
PES-Pakete mit wichtigen Informationen erhalten die hohe Priorität 1. Pakete mit weniger
wichtigen Daten werden mit der Priorität 0 gekennzeichnet. So können z.B. I-Frames bei
der Übertragung gegenüber P- oder B-Frames bevorzugt behandelt werden.
In einem PES-Paket werden die, aus MPEG1 bekannten, Zeitinformationen Presentation
Timestamp (PTS) und Decoding Timestamp (DTS) übertragen. Aufgrund dieser
Zeitinformationen können die elementaren Video- und Audioströme synchronisiert
werden.
Optional können die Daten eines PES-Pakets durch eine 16 Bit Cyclic Redundancy Check
Sequenz abgesichert werden. Die Fehlerüberprüfung erfolgt über das Generatorpolynom
x16 + x12 + x 5 + 1 . Das aktuelle PES-Paket enthält immer die CRC-Sequenz über die Daten
des vorherigen PES-Pakets. Die Pakete sind somit abhängig von einander und müssen in
der korrekten Reihenfolge beim Empfänger eintreffen bzw. sortiert werden.
Der Program Packet Sequenz Counter ist ein optionaler Zähler, der für jedes PES-Paket
eines Programmstroms oder für jedes Paket eines einzelnen Programms eines
49
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Transportstroms inkrementiert wird. Ist der maximale Wert (256) des Zählers erreicht, so
beginnt der Zähler wieder bei Null.
Ein oder mehrere PES-Pakete können in einen PES-Pack integriert werden.
Abb. 27) MPEG2 PES-Pack (Ref: [14] S. 224)
Der PES-Pack beginnt mit einem Pack-Header, in dem ein Synchronisationsmuster und
eine Zeitinformation enthalten sind. Die Zeitinformation stellt eine gemeinsame Zeitbasis
für alle PES-Pakete des Packs dar. Die Pack-Struktur ist in der Abb. 27) dargestellt.
Da MPEG2 nicht nur für die digitale Speicherung von multimedialen Daten entwickelt
wurde, sondern auch für den Transport von Multimediaströmen über Netzwerke, werden
unterschiedliche Anforderungen an die Synchronisation und die Robustheit gegenüber
Fehlern gestellt. Um diesen Anforderungen gerecht zu werden, unterstützt MPEG2 zwei
verschiedene Datenströme, den Programmstrom (PS) und den Transportstrom (TS). Für
beide Ströme sind die PES-Pakete die grundlegenden Datenelemente.
Transportsstrom
Der Transportstrom besteht aus mehreren, von einander unabhängigen Programmen. Diese
Programme haben untereinander keine gemeinsame Zeitbasis. Sie bestehen jeweils aus
einem elementaren PES-Paketstrom und können von unterschiedlichen Quellen stammen.
Ein Programm enthält einen oder mehrere Video- und Audioströme mit einer
gemeinsamen Zeitbasis. Damit sich der Decoder auf die Zeitbasis des jeweils zu
dekodierenden Programms synchronisieren kann, muss für jedes Programm eine
unabhängige Taktinformation, die Program Clock Reference (PCR) übertragen werden.
Die Abb. 28) beschreibt die Struktur des Transportstroms.
50
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 28) MPEG2-Transportstrom (Ref: [14] S. 225)
PES-Pakete unterschiedlicher Elementarströme werden innerhalb der Pakete eines
Transportstromes übertragen. Die Transportstrompakete besitzen eine feste Länge von 188
Byte und sind in einen Header- und in einen Payloadabschnitt unterteilt.
Abb. 29) MPEG2-Transportstrompaket Header-Struktur (Ref: [14] S. 225)
Aus Effizienzgründen besteht ein Transportstrom-Paket-Header aus einem kleinen BasisHeader und Erweiterungsfeldern (siehe Abb. 29). 4
Der Basis-Header beginnt mit dem Synchronisationsbyte 0x47, mit dem ein Demultiplexer
den Anfang eines Paketes erkennen kann. Es folgen drei Bit für eine einfache
Fehlererkennung, sowie die Möglichkeit, Pakete zwei verschiedenen Prioritäten zuordnen
zu können. Der Packet Identification Code (PID) dient zur Adressierung der
unterschiedlichen Programme bzw. zur Identifizierung einer im Transportstrom
enthaltenen Program Association Table (PAT => PID=0). Die PAT wird in definierten
Intervallen übertragen und ist eine Übersicht über alle im Transportstrom enthaltenen
Programme. Die restlichen Bits ermöglichen dem Multiplexer die PES-Paketströme der
51
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
verschiedenen Programme statistisch zu multiplexen. Somit können definierte mittlere
Datenraten für ein Programm realisiert werden. Im PCR-Erweiterungsheader wird die
Zeitbasis eines Programms kodiert. Hierzu ist ein 48 Bit großes PCR-Feld vorgesehen.
Der Transportstrom ist unabhängig von der eigentlichen Übertragungsstrecke. Die
Übertragung kann in verlustreichen und gestörten Umgebungen erfolgen. Durch die relativ
kleinen Pakete konstanter Länge kann man auf Übertragungsfehler schnell reagieren.
Fehlerhafte Transportstrom-Pakete werden über ein gesetztes Transport Error Flag
signalisiert. Dieses Flag muss durch Mechanismen außerhalb des MPEG2-Standards
aktiviert werden.
Programmstrom
Der Programmstrom entspricht im Wesentlichen einem MPEG1-Systemstrom. Er stellt die
Abwärtskompatibilität von MPEG2 zu MPEG1 bereit. In einem PS ist genau ein
Programm enthalten. Dieses Programm beinhaltet einen oder meist mehrere elementare
Video- und Audioströme, die eine gemeinsame Zeitbasis besitzen, die System Clock
Reference (SCR). Die Pakete eines Programmstroms sind variabel bis zu 64 kbyte lang.
Die mittlere Länge eines PS-Paketes beträgt ca. 1 kbyte bis 2 kbyte. Das Einsatzgebiet
eines Programmstroms ist die digitale Speicherung von Multimediadaten. Dabei wird eine
relativ störfreie Umgebung vorausgesetzt.
Fehlererkennungsmechanismen und Fehlerbehandlung sind deshalb nicht vorhanden.
6.1.4.5. Fehlererkennung in MPEG2
Der MPEG2-Standard definiert zwei Möglichkeiten, um Fehler in einem MPEG2Transportdatenstrom zu erkennen.
Im Packet-Header des MPEG2-Transportstroms kann ein fehlerhaftes Transportpaket
durch ein Paritätsbit, das Error Flag, signalisiert werden. Der Verlust eines Paketes führt
zwangsläufig zur Störung des Dekodierprozesses, meist zur Beeinträchtigung der
Synchronisation. Aufgrund der Slicestruktur ist es einem Decoder jedoch möglich, sich
nach einem aufgetretenen Fehler schnell zu resynchronisieren. Bitfehler verursachen somit
meist nur Bildfehler, die auf kleine Flächen beschränkt sind.
MPEG2-Decoder erwarten aufgrund der fest definierten MPEG2-Syntaxstruktur immer
definierte zeitlich aufeinander folgende Codewörter im Datenstrom (Startcode ->
Erweiterungscode ->...). Sollte ein unerwartetes oder unbekanntes Codewort vom Decoder
empfangen werden, so wird das gerade dekodierte Element (Block, Makroblock, Slice,
Picture...) als fehlerhaft erkannt.
52
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.4.6. Fehlerbehandlung in MPEG2
Der MPEG2-Standard definiert keine Mechanismen, um Fehler im Datenstrom korrigieren
zu können. MPEG2-Decoder unterstützen jedoch verschiedene Techniken, um die
aufgetretenen Fehler zu verschleiern.
Der Decoder nutzt dazu die fehlerfreien Informationen, um abschätzen zu können, welche
Inhalte anstelle verlorener oder fehlerhafter Daten angezeigt werden sollen. Dabei wird
immer die Annahme zugrunde gelegt, dass die Bildcharakteristiken zwischen adjazenten
Blöcken sehr ähnlich sind. Deshalb werden Abschätzungen für fehlerhafte oder verlorene
Blöcke mit Hilfe von Nachbarfeldern oder Nachbarbildern durchgeführt.
Temporal Predictive Concealment
In der einfachsten Variante wird ein verlorener oder fehlerhafter Makroblock mit einem
Makroblock der gleichen Position aus dem vorherigen Bild ersetzt. Das funktioniert mit
ähnlichen benachbarten Bildern gut. In Videosequenzen mit schnellen Bewegungen ist
diese Methode jedoch nicht einsetzbar, da die Bildinformationen zwischen den
benachbarten Bildern stark verschoben sein können. In diesem Fall werden zusätzlich die
Bewegungsvektoren des zerstörten oder verlorenen Blocks durch die Bewegungsvektoren
benachbarter Bilder abgeschätzt. Sind die benachbarten Bilder jedoch I-Frames, so
besitzen diese keine Bewegungsvektoren. Es gibt hier die Möglichkeit Concealment
Motion Vectors innerhalb von I-Frames zu übertragen.
Spatial Predictive Concealment
Für den Inhalt eines zerstörten oder verlorenen Makroblocks werden interpolierte Werte
der benachbarten Makroblöcke eines Bildes eingesetzt. Diese Verschleierungstechnik ist
vorteilhaft wenn schnelle Bewegungsabläufe in den Videosequenzen enthalten sind, bzw.
ein Szenenwechsel während des Verlustes stattfindet. Bei der Interpolation werden meist
nur der DC-Koeffizient und der unterste AC-Koeffizient einbezogen, da die Mittelung von
sehr feinen Details in schnell bewegten Bildern nicht sinnvoll ist.
Skalierbare Videokodierung und Fehlerverschleierung
Durch die Skalierung einer Videosequenz entstehen zwei oder drei Bitströme, die
unabhängig von einander übertragen werden können. Die Basisschicht enthält die
wichtigsten Informationen und sollte deshalb mit einer höheren Priorität, einer größeren
Redundanz und mit besseren Fehlererkennungsmechanismen über den besten verfügbaren
Kanal übertragen werden. Der korrekte Empfang dieses Bitstroms ist deshalb sehr
wahrscheinlich. Die Bitströme der Erweiterungsschichten übertragen lediglich zusätzliche
Informationen für eine Qualitätsverbesserung der Videosequenz, sodass diese Datenströme
über gestörtere Kanäle übertragen werden können. Die auftretenden Übertragungsfehler
sind mit den Informationen der Basisschicht durch die Techniken Spatial Predictive
Concealment oder Temporal Predictive Concealment sehr gut verschleierbar.
53
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Spatial Localisation
Ist ein Übertragungsfehler aufgetreten, so soll die Resynchronisation des Decoders so
schnell wie möglich erfolgen. Die Resynchronisation ist immer dann möglich, wenn ein
gültiger Startcode erreicht wird, der den Beginn einer Sequenz, einer GOP, eines Bildes
oder eines Slice signalisiert. Je mehr Synchronisationspunkte in einer Videosequenz
auftreten, umso kleiner ist der Fehler und desto besser lässt er sich verschleiern.
Der Slice ist die kleinste Synchronisationseinheit einer Videosequenz. Die Slicegröße
bestimmt somit direkt die Anzahl der Synchronisationspunkte und die Zeit, die der
Decoder für eine Resynchronisation benötigt.
Die grundlegende Methode, räumliche Eingrenzungen von Fehlern zu ermöglichen, ist die
Verringerung der Anzahl der Makroblöcke in einem Slice. Der Vorteil der
Fehlereingrenzung wird jedoch durch einen größeren Overhead und mit einem Verlust der
Kodiereffizienz von ca. 3% bis 12% bezahlt. Durch diesen Effizienzverlust ist die
Bildqualität um 1dB geringer. Diese Qualitätseinbuße kann jedoch vernachlässigt werden,
da die sonst notwendigen Interpolationen oder Ersetzungen von Makroblöcken über
ausgedehnte Bildflächen größere Fehler verursachen.
Temporal Localisation
B- und P-Frames besitzen Referenzen auf vorherige oder folgende Bilder. Die
referenzierten Bilder können durch Übertragungsfehler inkorrekt sein. Die fehlerhaften
Bildanteile werden durch die Verweise auf die inkorrekten Bilder über mehrere B- und PFrames weiterpropagiert. Erst bei dem Verweis auf ein korrektes intrakodiertes Bild wird
der Fehler kompensiert. Werden in kürzeren Abständen intrakodierte Bilder übertragen,
dann kann ein Fehler schnell annulliert werden. Da bei der Kodierung von I-Frames jedoch
große Datenmengen entstehen, sind diese Bilder bei der Übertragung sehr fehleranfällig.
Deshalb unterstützen einige Decoder eine partielle Intrakodierung von I-Frames. Dabei
wird eine konstante Anzahl von Slice’s eines Bildes intrakodiert (Intra Slice’s), die
restlichen Bildanteile werden interkodiert. Die Anzahl der intrakodierten Slice’s wird so
gewählt, dass ein Update des Bildes zu jedem P-Frame eines Streams erfolgt.
Zusammenfassung (Fehlerverschleierung, Fehlerlokalisation)
Alle genannten Techniken sind nicht getrennt für die Verdeckung aller Fehler optimal
einsetzbar. Deshalb werden oft Kombinationen verschiedener Verdeckungsmechanismen
eingesetzt. Die optimalen Einsatzmöglichkeiten für die genannten Fehlerverschleierungstechniken werden tabellarisch im Anhang C dargestellt.
54
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die wichtigsten Anforderungen an einen Videocodec, um für verteiltes MultisourceStreaming in hochdynamischen Netzen einsetzbar zu sein, sind Fehlerrobustheit,
Fehlerkorrigierbarkeit, Verteilbarkeit und Skalierbarkeit.
Eine MPEG2-kodierte Videosequenz ist durch viele Synchronisationspunkte (Startcodes)
auch bei stochastischen Informationsverlusten sehr robust. Es ist möglich, kleinere
Verluste durch Interpolation bereits bekannter Informationen zu verschleiern. Gehen
jedoch ganze Bilder oder Group of Picture verloren, sind zwangsläufig sichtbare Fehler die
Folge (Bildruckeln). Im MPEG2-Standard sind keine Fehlerkorrekturmechanismen
vorgesehen. Für die gesicherte Verteilung von MPEG2-Datenströmen sind somit
zusätzliche externe Mechanismen notwendig, z.B. Forward Error Correction, ARQ, Reed
Solomon Kodierung.
Verteiltes Multisource-Streaming ist in MPEG2 über zwei Ansätze möglich, die in Abb.
30) und Abb. 31) dargestellt werden. Die skalierbaren Profile SNR, SPATIAL und HIGH
erzeugen aus einer Videosequenz einen Basisdatenstrom, sowie ein oder zwei
Erweiterungsdatenströme. Diese Datenströme werden unabhängig von einander
transportiert. Der Empfänger kann somit den Basis- und die Erweiterungsdatenströme von
unterschiedlichen Quellen empfangen. Die Übertragungseigenschaften dürfen zwischen
den Datenströmen differieren.
Der Basisdatenstrom beinhaltet die wichtigsten Informationen einer Videosequenz. Er
kann vom Empfänger sogar unabhängig von den Erweiterungsdatenströmen dekodiert
werden. Deshalb werden für den Transport dieses Datenstroms härtere Forderungen an die
Störsicherheit und die maximale Fehlerrate gestellt. Die Erweiterungsdatenströme liefern
zusätzliche Informationen an den Empfänger und verbessern so die Qualität der
Videosequenz.
Abb. 30) Multisource-Streaming eines skaliertbar codierten MPEG2-Mediastroms
Durch die skalierbare Kodierung kann eine Multimediasequenz an verschiedene
Anforderungen angepasst werden. Dennoch sind für skalierbar kodierte MPEG2Verfasser: Holger Kärst
55
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Datenströme erhebliche Bandbreiten (min. 1,856 Mbit/s) erforderlich, die die Kapazitäten
heutiger Netzanbindungen (Modem, ISDN, GPRS, HSCSD, UMTS) übersteigen. MPEG2
wurde hauptsächlich für die Komprimierung von Videosequenzen in TV-Qualität
entwickelt. Die Auflösungen von MPEG2-Videosequenzen (min. 352:288) sind für
aktuelle Displays mobiler Netzwerkknoten meist zu hoch und nicht erforderlich.
Auch PES-Pakete einer Videosequenz können von unterschiedlichen Quellen an einen
Empfänger übertragen werden. Die PES-Pakete müssen eindeutig identifizierbar und auch
getrennt anforderbar sein. Im MPEG2-Standard sind eindeutige Kennzeichnungen von
PES-Paketen nicht vorgesehen. Ein zusätzlicher Zähler kann jedoch im PES-Paket-Header
als Erweiterung implementiert werden. Der maximale Wertebereich dieses Zählers von 0
bis 21024 reicht aus, um alle PES-Pakete einer Mediasequenz eindeutig nummerieren zu
können. Jedes PES-Paket wird durch eine CRC-Sequenz für den Transport über das
verlustbehaftete Netzwerk gesichert. Die gesicherten und gekennzeichneten Pakete werden
von der jeweiligen Quelle innerhalb eines Transportstroms an den Empfänger übertragen.
Der Empfänger muss durch einen Vorverarbeitungsprozess Transportstrompakete zu PESPaketen zusammensetzen und die PES-Pakete über ihre eindeutige Nummer sortieren.
Abb. 31) Multisource-Streaming von nummerierten PES-Paketen
Dieser zweite Verteilungsansatz erfüllt jedoch die Anforderungen nach Anpassbarkeit
einer Multimediasequenz an heterogene Endgeräte nicht.
Das MPEG2-Audiokodierverfahren enthält keine Funktionalitäten, um Audiosignale
skalierbar zu kodieren. Multisource-Streaming kann also für MPEG2-Audiosequenzen
nicht eingesetzt werden.
Obwohl der MPEG2-Standard den Multisource-Streaming-Ansatz für Systemdatenströme
unterstützt, sind die kodierten Videosequenzen, aufgrund der fehlenden Unterstützung für
kleine Auflösungen, nicht für die Verteilung in hochdynamischen mobilen Netzen
geeignet. Die Breite der Anforderungen der einsetzbaren Endgerätetypen wird von MPEG2
nicht vollständig unterstützt.
56
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Ursprünglich konzentrierte sich die Moving Picture Expert Group, bei der 1993
beginnenden Entwicklung von MPEG4, auf die Übertragung audiovisueller Daten bei sehr
niedrigen Bitraten. Während des Standardisierungsprozesses änderte und erweiterte sich
das Entwicklungsziel erheblich.
Noch stärker als bei MPEG2 hat sich im MPEG4-Standard der Schwerpunkt von den
Kompressionsaspekten auf die Systemarchitektur verlagert. MPEG4 bietet nun auch
Komponenten für die Verteilung von Multimediainformationen an, bei deren Entwurf
Dienstgüte und Skalierbarkeit eingeflossen sind. Interoperabilitäten bei der Verteilung
multimedialer Daten zwischen verschiedenen Netzwerken, wie z.B. ADSL, GSM, UMTS
u.a. werden ermöglicht. Für den Anwender soll es idealer Weise keinen Unterschied
machen, ob eine multimediale Anwendung einen drahtlosen Netzzugang, eine
Telefonleitung oder einen anderen Netzwerkanschluss verwendet.
Das Konzept der Profile und Level wurde von MPEG2 aufgegriffen. Es dient dazu,
verschiedene Anwendungen mit einem Standard optimal zu unterstützen. Dem Entwickler
steht es frei, die Komponenten unterschiedlicher Profile und Level beliebig zu
kombinieren. MPEG4 wendet sich dabei an drei Gruppen potentieller Anwender: Autoren,
Endanwender und Netzwerkdienstleister.
Der MPEG4-Standard existiert aktuell in zwei Versionen. Als die Spezifikationen für
MPEG4 1997 verabschiedet werden sollte, waren zu viele bedeutende Optionen noch nicht
ausgereift. In der MPEG4-Version 2 wurden einige dieser Optionen nachträglich definiert
und in den Standard aufgenommen. An den MPEG4-Versionen 3 und 4 wird noch
gearbeitet.
6.1.5.1. MPEG4-Architektur
MPEG4 definiert einen völlig anderen Ansatz, multimediale Daten zu beschreiben.
Objekte stellen, als zentrale Abstraktion, bestimmte Komponenten eines multimedialen
Elements dar.
Eine Multimediasequenz wird im MPEG4-Standard als Szene gedeutet, die aus mehreren
Objekten besteht und in einer hierarchischen Baumstruktur organisiert ist. Die Blätter
dieser Hierarchie bestehen aus Primitiven wie z.B. Standbildern (Hintergrund),
Videoobjekten und Audioobjekten.
Diese Art der Aufteilung der Gesamtinformation in Teilinformationen bietet hervorragende
Voraussetzungen für eine skalierbare Kodierung von Multimediasequenzen.
57
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Durch das Objektparadigma ergeben sich fünf Aufgaben, die den funktionellen Umfang
des MPEG4-Standards ausmachen:
•
Repräsentation von auditiven, visuellen oder audiovisuellen Daten als
Medienobjekte
•
Beschreibung der gemeinsamen Darstellung dieser Objekte als Kompositionen in
audiovisuellen Szenen
•
Multiplexen und Synchronisieren der Daten, die diese Objekte beschreiben, sodass
sie über getrennte Kanäle übertragen werden können
•
Interaktion mit der audiovisuellen Szene
•
hybride Kodierung von synthetischen (Animationen, synthetische Klänge) und
natürlichen Medienelementen
Vier elementare Einheiten werden für eine MPEG4-kodierte Multimediasequenz definiert.
Medienobjekte (Audiovisual Objects) repräsentieren die auditiven, visuellen oder
audiovisuellen Daten als zentrale Abstraktion. Sie bestehen aus natürlichen oder
synthetischen Inhalten.
Elementarströme (Elementary Streams) sind unabhänig transportierbare und verteilbare
Datenströme, die die multimedialen Elemente eines Medienobjekts enthalten. Einem
Medienobjekt können mehrere Elementarströme zugeordnet sein (z.B. ein
Audioelementarstrom und ein Videoelementarstrom).
Ein Objekt-Deskriptor-Framework ordnet die Elementarströme eindeutig Medienobjekten
zu. Es bietet zusätzliche Methoden zur Realisierung von hierarchischen Objektbeziehungen
und erlaubt die Assoziation von Metainformationen zu Objekten.
Access Units stellen die kleinste semantische Einheit von audiovisuellen Informationen
dar. Durch eine AU wird ein Elementarstrom zu einem bestimmten Zeitpunkt beschrieben.
Access Units sind zum Beispiel einzelne Bilder oder Audiosamples.
58
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die nachfolgende Grafik gibt einen Überblick über den Einsatz des DeskriptorenFrameworks, durch dass ein Audioobjekt und ein skalierbar kodiertes Videoobjekt in der
Szene definiert sind.
Abb. 32) Objekt- und Szenenbeschreibung einer MPEG4-Sequenz (Ref: [17] S.85)
Der MPEG4-Standard besteht aus 21 Teilen. Für diese Arbeit sind die Parts MPEG4System, MPEG4-Visual, MPEG4-Audio und MPEG4-DMIF besonders interessant.
59
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.5.2. MPEG4-System (Part 1)
MPEG4-System beschreibt die grundlegende Architektur für die Zusammensetzung, die
Synchronisation und die Verteilung einer Multimediasequenz. Hier wird die syntaktische
und strukturelle Definition von Beschreibungsinformationen für eine MPEG4-Szene und
die MPEG4-Objekte durch ein Deskriptor-Framework (siehe Abb. 33) festgelegt. Auch
die Definition der Datenstruktur für die Verteilung der audiovisuellen Elemente, die
Anbindung an verschiedene Netzwerktypen und der Kommunikationsprozess zwischen
MPEG4-Komponenten ist ein Teil von MPEG4-System. Der Systempart unterscheidet die
funktional abgegrenzten Schichten Compression-Layer, Synchronisation-Layer und
Delivery-Layer. Durch diese Schichtenarchitektur wird der Kodierprozess vom
Verteilungs- bzw. Speicherungsprozess für multimediale Daten getrennt.
Compression-Layer
In der Kompressionsschicht werden digitale, multimediale Rohdaten, gemäß den
standardisierten MPEG4-(De)Kodierprozessen, kodiert bzw. dekodiert. Der CompressionLayer legt bereits die Struktur der MPEG4-Szene fest und definiert die audiovisuellen
Objekte. Die zeitlichen Relevanzen der Objekte, ihre Platzierung in der Szene und die
Verknüpfung der Objekte mit den kodierten multimedialen Daten erfolgt durch eine
Hierarchie von Deskriptoren (Deskriptor-Framework). Der hierarchische Aufbau des
Frameworks ist in der folgenden Grafik dargestellt:
Abb. 33) MPEG4-Deskriptoren-Framework
Die oberste Ebene wird durch den Szenen-Deskriptor gebildet. Der Szenen-Deskriptor
beschreibt, durch einen gerichteten azyklischen Graphen, die Anordnung aller Objekte
innerhalb einer MPEG4-Szene. Eine Szene ist ein abgeschlossener Objektraum, der
mindestens ein Objekt enthält. Jedes Objekt wird durch einen Objekt-Deskriptor definiert.
Ein Objekt-Deskriptor enthält objektspezifische Informationen, die in weiteren
60
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Subdeskriptoren strukturiert sind. Die Informationen sind entweder direkt im ObjektDeskriptor verfügbar, oder der OD enthält einen Verweis (URL) auf eine
Objektbeschreibung, die auf einem entfernten Server liegen kann. Ein solcher Verweis ist
sinnvoll, wenn die Objekte einer Szene auf mehreren Streamingservern verteilt sind. Über
URL’s ist es somit möglich eine MPEG4-Szene aus vielen örtlich verteilten Objekten
zusammenzustellen. Jeder Objekt-Deskriptor kann innerhalb einer Szene durch eine
eindeutige OD-ID identifiziert werden.
Der Client sollte Informationen über die Komplexität des Dekodierprozesses für die
gesamte Szene einer MPEG4-Sequenz besitzen, um entscheiden zu können, ob die eigenen
Ressourcen für die Dekodierung ausreichend sind. Aus diesem Grund wurde ein ODDerivat, der Initiale Objekt-Deskriptor (IOD), entwickelt. Der IOD enthält neben den
Informationen eines regulären OD, Angaben zu Profilen und Leveln für die Objekte der
MPEG4-Sequenz. Er wird vor dem Transport der Objektdaten an den Client übermittelt.
Die Komplexität für die Dekodierung der Objekte kann somit über das Profil und das
Level vorab ermittelt werden. Man unterscheidet zwischen Profilen und Level für die
Szene, für auditive, visuelle und synthetische Elemente und für den Objekt-Deskriptor
selbst.
Die Subdeskriptoren des Objekt-Deskriptors setzen sich aus Elementarstrom-Deskriptoren
(ESD), Object Content Information Deskriptoren (OCI), dem IPMP-Deskriptor und dem
Extension-Deskriptor zusammen.
Ganze Sets von OCI-Deskriptoren definieren inhaltliche Beschreibungen von Objekten in
Form von Metadaten. Solche Metadaten können zum Beispiel Schlüsselwörter für
Suchmaschinen oder Angaben über die Sprache eines audiovisuellen Objektes sein, den
Inhalt des Objektes in ein Genre einordnen, oder sie definieren zu welchem Zeitpunkt ein
Objekt in einer Szene erscheinen soll.
Abb. 34) OCI-Metadaten für ein MPEG4-Objekt (Bsp: Zeitdefinition für das Erscheinen eines Objektes in einer Szene) (Ref: [17]
S.99)
61
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Mittels IPMP-Deskriptoren können einem Objekt Authorisierungsinformationen
zugeordnet werden. Alle Elementarströme eines OD unterliegen den statischen Meta- bzw.
Authorisierungsinformationen der OCI- und IPMP-Deskriptoren. Wenn sich die Metadaten
eines OCI-Deskriptors dynamisch ändern, dann wird ein unabhängiger OCIElementarstrom implementiert (siehe Abb. 35). Innerhalb eines OCI-Elementarstroms
definieren OCI-Ereignisnachrichten, über welchen Zeitraum die Metadaten für die
Elementarströme gültig sind.
Abb. 35) OCI Events (Ref: [17])
Elementarströme werden im OD durch Elementarstrom-Deskriptoren (ESD) definiert. Ein
Elementarstrom-Deskriptor enthält alle Informationen, um einen Elementarstrom zu
identifizieren, ihn zu beschreiben, zu lokalisieren, seine Priorität festzulegen und zu
definieren, welche Ressourcen für die Dekodierung der Daten des Stroms bereitzustellen
sind. Auch der Elementarstrom-Deskriptor enthält weitere Subdeskriptoren.
Der Decoder-Config-Deskriptor definiert Initialisierungsinformationen für den Decoder
des Elementarstroms. Er klassifiziert einen Elementarstrom etwa in Video, Audio und
Szenenbeschreibung. Zusätzlich werden Informationen über die Kodierung des Stroms
(JPEG, MPEG1, MPEG2, MPEG4, MP3, AAC), über die geforderte Puffergröße für den
Decoderpuffer, sowie die maximale und die durchschnittliche Bitrate des Stroms
62
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
übermittelt. Ein Upstream Flag signalisiert, dass ein Rückkanal vom Client zum Server
unterstützt wird.
Informationen über Ressourcenanforderungen und Prioritäten eines Elementarstroms
werden durch einen QoS-Deskriptor innerhalb eines Elementarstrom-Deskriptors
übertragen. Durch QoS-Qualifier lassen sich bis zu 256 verschiedene QoS-Beschreibungen
definieren. Vordefinierte Beschreibungen sind zum Beispiel:
•
maximale Ende-zu-Ende-Verzögerung für den Elementarstrom (in Millisekunden)
•
erlaubte Verlustwahrscheinlichkeit für eine Access Unit
•
maximale Anzahl für den Verlust aufeinander folgender Access Units
•
maximale Größe für eine Access Unit
Der Sync-Layer-Config-Deskriptor beschreibt, mit welcher Auflösung die
Zeitinformationen der Access Units des Elementarstroms erzeugt wurden und in welchem
Wertebereich die Zeitstempel definiert sind.
Mit Hilfe des Registration Deskriptors können Datenströme als Elementarstrom übertragen
werden, die nicht gemäß dem MPEG4-Standard kodiert sind.
Synchronisation-Layer (SL)
Bevor Elementarströme transportiert werden können, müssen die enthaltenen Daten
paketiert werden. Der Synchronisation-Layer ist für diese Transformation zuständig.
Ein paketierter Elementarstrom wird SL-packetized-Stream genannt. Jedes SL-Paket
besteht aus einem Datenteil und einem Paket-Header. Innerhalb des Datenteils eines
Paketes wird meist genau eine Access Unit übertragen. Access Units können aber auch auf
mehrere aufeinander folgende SL-Pakete verteilt werden.
Der Paket-Header ist konfigurierbar. Es werden nur die notwendigsten Header-Elemente
implementiert. Die Konfiguration des SL-Paket-Headers erfolgt gemäß den Informationen
des SL-Configuration-Deskriptors des Elementarstroms. Der Verlust eines SL-Paketes ist
durch eine im Header enthaltene Sequenznummer leicht erkennbar. Eine fortlaufende AUSequenznummer erlaubt zusätzlich, dass verlorene oder beschädigte Access Units schnell
erkannt werden können.
Die koordinierte Präsentation von Objekten wird durch die Szenenbeschreibung im
Compression-Layer vorgeben. Es ist jedoch auch eine klare Zeitdefinition für die
multimedialen Datenelemente der Objekte notwendig, um eine synchrone Darstellung
zeitlich abhängiger Elementarströme realisieren zu können. Die Definition dieser
Zeitinformation und die Synchronisation zeitlich abhängiger Elementarströme ist die
zweite Aufgabe des Synchronisation-Layers.
63
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die SL-Pakete erhalten deshalb im zweiten Verarbeitungsschritt Informationen für ihre
zeitliche Gültigkeit.
Im Zeitmodel von MPEG4 wird definiert, dass Zeitangaben innerhalb einer MPEG4Sequenz relativ sind und sich immer auf einen Referenzpunkt beziehen. Diese relativen
Zeitangaben (Timestamps) werden immer an die kleinsten Einheiten einer MPEG4Sequenz, die Access Unit’s, angehangen. Man unterscheidet zwei Arten von Timestamps:
Die Decoding-Timestamp (DTS) indiziert den Zeitpunkt, zu dem die Access Unit
vollständig beim Empfänger vorliegen muss und somit als Einheit dekodiert werden kann.
Die Composition-Timestamp (CTS) definiert den Zeitpunkt, zu dem die Access Unit für
die Integration bzw. Komposition in eine Präsentationsumgebung verfügbar sein muss. Die
CTS entspricht somit der Presentation-Timestamp des MPEG2-Standards. Sind die
Zeitmarken von Access Units verschiedener Elementarströme gleich, so werden die
Einheiten gemeinsam zur gleichen Zeit dekodiert bzw. in einer Präsentation verknüpft.
Eine zusätzliche Zeitmarke ist notwendig, wenn eine Szene aus Objekten besteht, die von
verschiedenen Encodern kodiert wurden. In diesem Fall können die Taktraten der Encoder
verschieden sein. Für Equipment aus dem Endkundenbereich ist es realistisch, wenn sich
die Taktraten der Encoder um ca. 0,1% unterscheiden. Wird eine Stunde einer
Multimediasequenz wiedergegeben, die aus einer Komposition der Ströme solcher
verschiedener Encoder besteht, so kann über diesen Zeitraum eine Differenz von 3,6 s
zwischen den Mediaströmen entstehen. Die Object Clock Referenz (OCR) soll dieses
Problem beheben. In die OCR-Zeitmarke wird die Systemzeit des Senders zum dem
Zeitpunkt eingetragen, zu dem der Sender die OCR-Marke im Stream platziert und sie
aussendet. Der Empfänger kann über die diskreten OCR-Werte, die fortlaufend im Strom
enthalten sind, die Geschwindigkeit der Zeitbasis des jeweiligen Encoders abschätzen. Hat
der Empfänger die Zeitbasis für jeden Encoder einer MPEG4-Sequenz ermittelt, so kann er
die Zeitmarken aller Ströme auf eine gemeinsame Zeitbasis durch eine affine
Transformation referenzieren.
Die Konfiguration der Zeitmarken CTS und DTS ist im SL-Paket-Header sehr flexibel
möglich. Die Zeitmarkenlänge und die zeitliche „Auflösung“ (Taktrate) der Zeitmarken
sind in einem großen Wertebereich definierbar, damit Applikationen mit geringer Bitrate
genauso wie Applikationen mit hoher Bitrate effizient unterstützt werden können.
Zusammenfassend ist zu bemerken, dass das Zeitverhalten und die Synchronisation von
Elementarströmen über den Zeitmarken-Mechanismus beschrieben werden, der durch
MPEG2 bereits bekannt ist. Der Mechanismus wurde erweitert, sodass innerhalb einer
Präsentation Objekte auf verschiedenen zeitlichen Grundlagen basieren können.
SL-paketierte-Ströme werden übertragen, in dem sie die Dienste eines TransportprotokollStack’s nutzen. Das Ziel bei der Entwicklung des MPEG4-Standards war es,
64
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Elementarströme über verschiedene Transportprotokolle gleichermaßen übertragen zu
können. Diese Aufgabe wird durch den Delivery-Layer erfüllt.
Delivery Layer
Im Gegensatz zum MPEG2-Standard entschied sich die Motion Picture Expert Group, für
MPEG4 kein eigenes Transport-Multiplex-Protokoll zu entwickeln, sondern eine klare
Schnittstelle zwischen der kodierten MPEG4-Sequenz und der Transportschicht zu
definieren. Somit sollte eine MPEG4-Sequenz flexibel durch verschiedene Transportmittel
übertragen werden können. In der Realität sind einige Anpassungen der MPEG4-Ströme an
existierende Transportprotokolle notwendig. Diese Anpassungen sind jedoch für die
MPEG4-kodierten Datenströme und das jeweilige Transportprotokoll durch das Delivery
Multimedia Integration Framework (DMIF) transparent. Einem MPEG4-Player bleibt
durch DMIF verborgen, ob die abzuspielende Sequenz von einer lokalen Datei entstammt,
oder von einem Server durch ein Netzwerk vermittelt wird. Der homogene Zugriff auf
Datei- oder Transportfunktionalitäten für eine MPEG4-Anwendung wird durch das
Delivery Application Interface (DAI) bereitgestellt. Das DA-Interface ist zu einem Service
Access Point des ISO/OSI-Referenzmodells äquivalent. Es stellt der Anwendung über
Primitive verschiedene Dienste des DMIF-Layers zur Verfügung. Man unterscheidet
zwischen Service-, Channel-, QoS Monitor-, User Command- und Data-Primitiven.
Service-Primitive erzeugen neue Dienste, die auf einer URL basieren, oder sie zerstören
ältere Dienste die nicht mehr benötigt werden.
Channel-Primitive generieren neue Kanäle, basierend auf Identifikationsnummern, die von
der Anwendung definiert werden, oder sie zerstören Kanäle die nicht mehr benötigt
werden.
QoS-Monitor-Primitive kontrollieren und initialisieren QoS-Monitor-Funktionen für einen
Kanal. Somit ist es möglich QoS-Statistiken für einen Kanal zu erzeugen und zu
beobachten.
User-Command-Primitive übertragen Kommandos wie Play oder Pause für die Steuerung
des Streamprozesses.
Data-Primitive enthalten die aktuell zu übertragenden Mediadaten.
Die Primitive stellen Signaturen von der Applikation zum DMIF-Layer und vom DMIFLayer zur Applikation bereit. Sie besitzen IN- und OUT-Parameter. Anforderungen an eine
Primitive werden durch IN-Parameter signalisiert, auf die die Primitive asynchron mit
OUT-Parametern reagiert.
Die Signaturen bzw. die Parameter der DAI-Primitive müssen für die Übertragung an
einen entfernten Kommunikationspartner, an das jeweilige Transportprotokoll angepasst
werden. Dazu wurde im MPEG4-DMIF-Part eine zweite DMIF-Schnittstelle, das DMIF
Network Interface (DNI), entwickelt. Über diese Schnittstelle werden die DAI-Parameter
65
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
in transportprotokollspezifische Parameter übersetzt und umgekehrt. Die zweite Aufgabe
des DN-Interface besteht darin, alle Dienstanforderungen, die an einen entfernten
Kommunikationspartner gestellt werden, zu einem Transport-Multiplexer-Datenstrom
(TransMux) in einer Netzwerk-Session zusammenzufassen. Spezifische Instanzen eines
Transport-Multiplexers entsprechen so genannten TransMux-Kanälen. Die Kanäle sind
jeweils für einen Transportmechanismus (UDP, TCP, MPEG2-TS...) spezifiziert.
Die einzelnen gemultiplexteten DMIF-Elemente sind eindeutig identifizierbar. Die
Netzwerk-Session ist durch eine Network-Session-ID gekennzeichnet. Jedes DMIFElement wird einem TransMux-Datenstrom in einer Netzwerk-Session durch ein
TransMux Association Tag (TAT) zugeordnet. Die Identifikation eines DMIF-Elements zu
einem Kanal innerhalb des TransMux-Datenstroms erfolgt über ein Channel Association
Tag (CAT).
Das optionale MPEG4-Tool FlexMux multiplext verschiedene SL-paketierte Ströme zu
einem Datenstrom.
Das „Delivery Multimedia Integration Framework“ kann man mit dem File-TransferProtocol vergleichen. Bei beiden Mechanismen werden zunächst Sitzungen eröffnet. Im
Fall von FTP fordert die Applikationsschicht bestimmte Daten an, die vom FTP-Dienst bei
der entsprechenden Quelle heruntergeladen werden. Im DMIF-Ansatz ist das ähnlich. Eine
Auswahl von Elementarströmen wird von der Anwendungsschicht angefordert. Der DMIFLayer erzeugt nun entsprechende Kanäle, um die Elementarströme von der Quelle
entgegenzunehmen und zum Empfänger zu übertragen.
Die Zusammenarbeit von MPEG4-System (Part 1) und MPEG4-DMIF (Part 6) ist in der
folgenden Skizze ersichtlich:
Abb. 36) Zusammenarbeit zwischen MPEG4-System und DMIF (Ref: [17] S. 230)
66
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Funktionalität von DMIF kann am Beispiel eines TCP/IP-Netzwerks im Anhang E
nachvollzogen werden.
6.1.5.3. MPEG4-Visual (Part 2): Natural Video Coding
MPEG4-Visual unterstützt die Kodierung natürlicher visueller Mediasequenzen in einer
großen Vielfalt standardisierter Auflösungen. MPEG4-kodierte Videosequenzen sind
deshalb in verschiedenen Einsatzgebieten zu finden, beispielsweise in der mobilen
Videotelefonie oder in der TV- und HDTV-Produktion. Im Besonderen werden die in der
Anforderungsanalyse geforderten Auflösungen Sub-QCIF, QCIF, CIF, 4CIF und 16CIF
unterstützt.
Im MPEG4-Standard ist eine Videosequenz, wie auch bei den Vorgängern MPEG1 und
MPEG2, hierarchisch strukturiert (siehe Abb. 37).
Abb. 37) Hierarchische Struktur des MPEG4-Videostroms (Ref: [17] S.298)
Jede MPEG4-Szene besteht aus einer Visual Object Sequenz mit einem oder mehreren
visuellen Objekten (VO).
Die VO-Sequenz beginnt, wie in Abb. 38) dargestellt, mit einem VO-Sequence-Header.
Mit diesem Header werden Informationen über das Profil und das Level der visuellen
Objekte der Sequenz übertragen. Der Decoder kann sich somit leicht auf die Komplexität
des Dekodiervorganges für diese Objekte einstellen. Die VO-Sequenz endet nach
mindestens einem visuellen Objekt mit dem VO-Sequenz-End-Code.
67
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 38) Visual Object Sequence / Visual Object
Visuelle Objekte unterstützen im Falle der skalierbaren Videokodierung verschiedene
Video-Object-Layer (VOL). Jeder Layer definiert eine bestimmte räumliche oder zeitliche
Auflösung einer Video-Object-Plane-Sequenz und kann mit unterschiedlichen Prioritäten
versehen werden. Erweiterte Informationen des Video-Object-Layer’s werden über den
VOL-Header übertragen, der mit einem VOL-Startcode beginnt. Die letzten vier Bit des
Start Codes adressieren jeden VOL eindeutig in einer Video-Sequenz.
Video-Object-Plane’s (VOP) bilden die unterste Hierarchieebene einer MPEG4-kodierten
Videosequenz. Sie stellen somit die kleinsten Einheiten der Sequenz dar. Die VideoObject-Plane wird mit einem VOP-Header initialisiert. Eine VOP ist ein Teil eines VideoObjektes zu einem bestimmten Zeitpunkt. Die VOP lässt sich also mit einem einzelnen
Bild vergleichen, während ein visuelles Objekt vergleichbar mit einer Bildsequenz ist.
Video-Object-Planes können zu einer Group of VOP’s (GOV) geclustert werden. In jeder
GOV sind die in Abb. 39) dargestellten Header-Informationen enthalten, mit denen die
Bearbeitung des MPEG4-Videomaterials vereinfacht wird.
Abb. 39) MPEG4-GOV-Header
Die Kodierung jeder Video-Object-Plane erfolgt blockweise. Dazu wird das kleinste
umschließende Rechteck um eine VOP gebildet, die VOP-Bounding-Box. Diese Box wird
von der Szene extrahiert und repräsentiert die korrespondierende VOP über ihre Texturund Forminformationen. Die Bounding-Box wird in Makroblöcke mit jeweils 16x16
Luminanzabtastwerten geteilt. Es werden drei Makroblockarten unterschieden.
68
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die transparenten Makroblöcke befinden sich vollständig außerhalb der VOP, jedoch
innerhalb der VOP-umschließenden Bouding-Box. Mit diesen Makroblöcken werden keine
Helligkeits- und Farbinformationen, sondern nur Informationen über die Form der VOP
kodiert. Der Decoder erkennt, dass diese Blöcke in der VOP nicht sichtbar sind.
Opaque Makroblöcke befinden sind vollständig innerhalb der VOP. Diese Makroblöcke
werden durch die bekannte hybride Kodierung intra- oder interkodiert. Sie enthalten
Helligkeits- und Farbinformationen, jedoch keine Daten über die Form der VOP.
Boundary Makroblöcke befinden sich an der Grenze der VOP. Für die Berechnung dieser
Blöcke wurden spezielle Tools zur Kodierung von Objekten mit beliebigen Formen
entwickelt. Die Blöcke enthalten Informationen über die Form der VOP sowie Abtastwerte
für Luminanz- und Chrominanzsignale. Die Abb. 40) stellt die Makroblockarten am
Beispiel einer VOP dar.
Abb. 40) MPEG4 Makroblockarten
69
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Grundsätzlich unterscheidet der MPEG4-Standard die Kodierung von rechteckigen
Videoobjekten, sowie die Kodierung von Videoobjekten mit beliebiger Form (Arbitrarily
Shaped Video Objects).
Kodierung rechteckiger VOP
Für die Kodierung von rechteckigen VOP’s werden keine Informationen über die VOPForm benötigt, sodass Shape-Coding bzw. Shape-Decoding nicht benötigt wird. Für diese
Videoobjekte wird ein blockbasierter, bewegungskompensierter, hybrider (De)Coder
eingesetzt. Der (De)Kodierprozess erfolgt mit der DCT, wie sie bereits in der
Vorbetrachtung beschrieben wurde. Der MPEG4-Standard unterscheidet drei VOP-Typen:
intrakodierte VOP’s (I-VOP) und interkodierte VOP’s (P-VOP, B-VOP). Der VOP-Typ
wird im VOP-Header direkt nach dem Startcode angegeben. Intrakodierte VOP’s enthalten
alle DCT-kodierten Werte eines unabhängigen „initialen Objektbildes“. Sie dienen, ähnlich
den I-Frames des MPEG1- und MPEG2-Standards, als Referenz für vorhergehende oder
nachfolgende, bewegungskompensierte VOP’s. In den P-VOP’s sind die Differenzen
zwischen einem referenzierten I-VOP und der aktuellen VOP kodiert. Durch die
Differenzbildung zwischen den beiden VOP’s werden alle redundanten Informationen
herausgefiltert und nicht kodiert. Eine B-VOP besitzt nicht nur eine Referenz auf eine
frühere I- oder P-VOP, sondern zusätzlich eine Referenz auf eine nachfolgende I- oder PVOP.
Die
Differenzinformationen
beider
Referenzen
werden
zu einer
Bewegungsvorhersage interpoliert. Zusätzlich werden Bewegungsvektoren übertragen, die
die Werte für eine räumliche Verschiebung von ähnlichen Informationen zwischen der
aktuellen und der referenzierten VOP enthalten. Nachdem die VOP’s DCT-transformiert
wurden, erfolgt die Quantisierung, Serialisierung und Entropiekodierung der DCTKoeffizienten.
Kodierung beliebig geformter VOP (arbitrarily shaped VOP)
Jede VOP eines beliebig geformten Videoobjektes wird durch seine Helligkeits- und
Farbkomponenten und eine Formkomponente definiert. Die Information über die Form des
Objektes wird durch Alpha-Masken repräsentiert. Eine Alpha-Maske definiert die
verschiedenen Transparenz-Level einer VOP in Form einer Matrix. Die Größe der AlphaMaske entspricht der Größe der VOP-Bounding-Box. Eine Graustufen-Alpha-Maske
beschreibt Transparenzwerte zwischen 0 und 255. Die Null korrespondiert zu einem
vollständig transparenten Pictureelement, die 255 zu einem vollständig sichtbaren
Pictureelement. Eine weitere Variante für die Kodierung von Forminformationen wird
durch die binäre Alpha-Maske bereitgestellt. In dieser Maske sind nur zwei Werte erlaubt
(0 = Transparent, 255 = Sichtbar). Ein Pictureelement gehört nur dann zu einem
Videoobjekt, wenn dessen Alpha-Wert größer als Null ist.
70
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Beide Arten der Alpha-Masken können in MPEG4 genutzt werden. Die Kodierung der
Alpha-Werte erfolgt durch arithmetische Kodierung. Dazu wurden für beide Maskenarten,
jeweils ein Shape Coding Tool entwickelt.
Binary Shape Coding
Das Binary Shape Coding erfolgt blockweise. Die Hauptidee des Binary Shape Coding
basiert auf einem Arithmetik-Encoder. Der Arithmetik-Encoder kodiert einen binären
Alpha-Wert eines Makroblocks in Abhängigkeit von einem Kontext, der aus allen zu
kodierenden Alpha-Werten berechnet wurde. Makroblöcke die Alpha-Werte enthalten
werden Binary Alpha Blocks (BAB’s) genannt. Der Encoder erzeugt Codeworte (ähnlich
zu Huffman Codes) für die binären Werte 0 und 255, abhängig von einer statistischen
Wahrscheinlichkeit. Für jeden möglichen Kontext wird die Wahrscheinlichkeit ermittelt,
indem Gruppen von typischen Alpha-Masken-Sequenzen verwendet werden. Die
Wahrscheinlichkeitswerte, die Teil der MPEG4-Spezifikation sind, werden als Parameter
im Arithmetik-Encoder für die Erzeugung der Codeworte benutzt.
Binary Shape Coding unterscheidet zwischen einem intra-coding-Modus und einem intercoding-Modus. Im inter-coding-Modus erfolgt eine Bewegungskompensation der
Objektform unabhängig von der Bewegungskompensation der Objekttextur.
Gray Level Shape Coding
Im Gray Level Shape Coding werden zunächst binäre Supportmasken generiert. Diese
Supportmasken entsprechen den Binary-Shape-Masken und werden auch entsprechend
dem Binary Shape Coding kodiert. Sie enthalten Informationen über die grobe
Zugehörigkeit von Makroblöcken zu einem Objekt. Ein Wert der Maske ist Null, wenn der
Wert des korrespondierenden Alpha-Wertes Null ist, sonst wird er auf 255 festgelegt. Die
Gray-Level-Alpha-Werte werden als Texturdaten wie normale Luminanzwerte kodiert. Der
Decoder rekonstruiert die Supportmaske und die Gray Level Plane. Jedes Bildelement in
der Gray Level Plane wird auf Null gesetzt, wenn der korrespondierende Wert in der
Supportmaske Null ist. Der Sachverhalt ist in der folgenden Abbildung grafisch dargestellt.
Abb. 41) Gray Level Shape Coding (Ref: [17] S.324)
71
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.5.4. Skalierbare Videokodierung
Der MPEG4-Standard bietet vier Möglichkeiten an, eine Videosequenz skalierbar zu
kodieren: räumliche, zeitliche, objektbasierte und qualitative Skalierung.
Die räumliche und zeitliche skalierbare Kodierung kann mit Arbitrary Shape Coding
kombiniert werden. Die Informationen der Erweiterungsdatenströme gelten somit entweder
für das gesamte Objekt oder nur für einen Teil des Objekts. Die entsprechende Gültigkeit
wird durch ein Enhancement Type Flag im erweiterten Videosequenz-Header signalisiert.
Räumliche Skalierbarkeit
MPEG4 erlaubt die räumliche Skalierung beliebig geformter Objekte. Hierbei wird
zwischen der räumlichen Skalierung der Form und der räumlichen Skalierung der Textur
des Objektes unterschieden. Die räumliche Skalierung der Objektform erfolgt entweder
durch das Spatial Scalability for binary shape-Tool oder die Objektform wird direkt in den
jeweils erforderlichen Auflösungen im Basisstrom und den Erweiterungsströmen
unabhängig kodiert.
Spatial Scalability for binary shape - Tool
Der Basisstrom enthält Forminformationen in einer geringen räumlichen
Mindestauflösung. Diese Informationen werden im Erweiterungsstrom als Basis genutzt.
Der Erweiterungsstrom enthält zusätzliche Alpha-Werte, durch die die räumliche
Auflösung der Objektform erhöht werden kann. Die niedrig aufgelösten Informationen der
Basisschicht werden, entsprechend Abb. 42), zunächst auf die Größe der Infomationen der
Erweiterungsschicht skaliert.
Abb. 42) Skalierung der Basisschichtinformationen auf das Sampling Grid des Erweiterungslayers (Ref: [17] S.334)
72
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
In der Erweiterungsschicht werden nun nur noch die Differenzen zwischen der originalen,
hochaufgelösten Forminformation und der hochgesampelten Basisinformation aus der
Basisschicht kodiert und übertragen.
Die skalierte Kodierung der Texturinformationen erfolgt ähnlich wie im MPEG2-Standard,
jedoch sind die Verweise auf Basisinformationen anders definiert (siehe Abb. 43).
Abb. 43) räumlich skalierbare Kodierung in MPEG4 (Ref: [17] S.333)
Die I-VOP’s der Basisschicht liefern keine Basisinformationen für die
Erweiterungsschicht. Die I-VOP’s der Erweiterungsschicht werden somit genauso
unabhängig (de)kodiert wie die I-VOP’s der Basisschicht.
Die P-VOP’s des Erweiterungsstromes erhalten Informationen durch hochgesampelte PVOP’s des Basisstromes. Bewegungsvektoren für die Bewegungskompensation im
Erweiterungsstrom werden nur von I- oder P-VOP’s des Erweiterungsstromes genutzt. Die
P-VOP’s besitzen somit Ähnlichkeiten mit den räumlich skalierten I-Frames des MPEG2Standards.
B-VOP’s der Erweiterungsschicht nutzen Texturinformationen zukünftiger P-VOP’s des
Basisstromes und Bewegungsvektoren von früheren P-, B- oder I-VOP’s des
Erweiterungsstroms. Sie ähneln somit den räumlich skalierten P-Frames des MPEG2Standards.
Zeitliche Skalierbarkeit
Auch das Prinzip der zeitlichen Skalierbarkeit des MPEG4-Standards ist zum MPEG2Standard meist identisch. Der Basisstrom enthält eine VOP-Sequenz mit einer definierten
minimalen Bildwiederholrate. Verweise auf zusätzliche Bilder, die im Erweiterungsstrom
enthalten sind, können vom Decoder genutzt werden, um die Bildwiederholrate zu erhöhen
(siehe Abb. 44).
73
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 44) zeitlich skalierbare Kodierung in MPEG4 (Ref: [17] S.337)
Die zeitliche Skalierbarkeit ist nicht nur für vollständige visuelle Objekte möglich, sondern
auch für Teile dieser Objekte. Wenn diese zeitlich skalierbar kodierte Region ihre Form
verändert oder sich bewegt, entsteht ein leerer Bereich im Hintergrund. Für diesen Bereich
sind keine Texturinformationen verfügbar. Um dieses „Loch“ zu füllen, ohne das sichtbare
Fehler erkennbar sind, wird ein Padding-Prozess eingesetzt. In diesem Padding-Prozess
werden verschiedene Fälle unterschieden.
Wird der Hintergrund weder von der vorherigen geformten VOP noch von der
nachfolgenden VOP abgedeckt, so wird das entstandene Loch mit den
Texturinformationen von der zeitlich näheren VOP gefüllt.
Sollten sich die aufeinander folgenden VOP’s überschneiden und ein Teil des Objektes von
einer vorherigen VOP abgedeckt werden, der Teil jedoch zum Hintergrund der nächst
folgenden VOP gehören, so sind die Hintergrundwerte dieser nächst folgenden VOP
gültig.
Im entgegengesetzten Fall sind natürlich die Hintergrundinformationen der früheren VOP
gültig.
SNR Fine Granularity Scalability (FGS)
Das MPEG4-FGS-Coding-Tool ermöglicht eine qualitativ skalierbare Kodierung einer
Multimediasequenz. Es deckt einen großen Bereich verschiedener Bitraten für die
Distribution ab. Multiple Schichten erlauben eine große Flexibilität bei der Anpassung
eines Multimediastroms an die verfügbare Bandbreite des Übertragungsmediums. Der
Kodierprozess wird vom Distributionsprozess separiert. Der Encoder produziert einen
Basisdatenstrom und einen oder mehrere Erweiterungsdatenströme. Eine FGS-ServerApplikation passt den Bitstrom an die Charakteristiken des Übertragungskanals und des
Decoders an (z.B. Bitrate oder Rechenkapazität des Decoders).
74
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Amplitudenskalierung des Videosignals erfolgt durch FGS vollkommen anders als im
MPEG2-Standard. Bei MPEG2 wird der Quantisierungsfehler des Basislayers im
Erweiterungslayer kodiert. Die Kodierung des Fehlers erfolgt über die gleichen
Quantisierungsmechanismen und VLC-Tabellen wie im Basislayer. MPEG4-SNR-FGS
kodiert den Quantisierungsfehler der Basisschicht ebenfalls in der Erweiterungsschicht,
jedoch unter Benutzung einer „Bit-Plane“-Repräsentation der DCT-Koeffizienten. Ein
Beispiel einer solchen Repräsentation zeigt die folgende Abbildung.
Abb. 45) SNR Fine Granularity Scalability (FGS) (Ref: [17] S.341)
Die absoluten Werte der DCT-Koeffizienten werden nach ihrer Signifikanz sortiert.
Danach werden die Informationen der sortierten DCT-Koeffizienten bitweise in die BitPlanes einsortiert, beginnend mit dem höchstwertigen Bit (MSB) bis zum niederwertigsten
Bit (LSB). Die Bit-Planes werden gruppiert (MSB-Bit-Plane ... LSB-Bit-Plane) und jeweils
lauflängenkodiert.
In den zu übertragenden Bitstrom werden zuerst die Daten der MSB-Bit-Plane aller
Makroblöcke einer VOP eingetragen, gefolgt von der nächsten signifikanten Bit-Plane, bis
hin zur LSB-Bit-Plane. Somit ist es möglich, die Übertragung des Erweiterungsstroms zu
75
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
jedem beliebigen Zeitpunkt zu stoppen. Alle bis zu diesem Punkt übertragenen Daten
können vom Decoder genutzt werden.
Im Basislayer werden adaptive Quantisierungsmatrizen und Quantisierungsauflösungen
bereitgestellt, um die zu übertragende Datenmenge an das Übertragungsmedium bzw. an
den Decoder anpassen zu können.
In der Erweiterungsschicht unterstützt FGS eine frequenzgewichtete Quantisierung und die
Möglichkeit wichtige Makroblöcke einer VOP bzw. wichtige DCT Werte eines
Makroblocks feiner zu quantisieren als unwichtigere.
Diese selektive Quantisierung einzelner Makroblöcke oder DCT-Werte wird realisiert,
indem die korrespondierenden DCT-Koeffizienten, entsprechend einer Maske, um ein oder
mehrere Bit-Planes nach oben verschoben werden. Die Maske wird vom Encoder an den
Decoder übermittelt. Das Ergebnis ist, dass die relevantesten Makroblöcke bzw. DCTWerte zuerst im Erweiterungsstrom übertragen werden und somit den Decoder mit einer
größeren Wahrscheinlichkeit erreichen.
Es ist möglich die FGS-Bit-Plane-Kodierung mit zeitlicher Skalierbarkeit zu kombinieren.
Referenzen für zeitlich skalierte FGS-VOP’s (FGST-VOP’s) werden nur vom Basislayer
geliefert. Jede kodierte FGST-VOP hat zwei separate Bereiche. Im ersten Teil werden die
Bewegungsvektoren, entsprechend dem MPEG4-Ansatz, für die zeitliche Skalierung
kodiert. Sie werden entweder zusammen mit den im zweiten Teil Bit-Plane-kodierten
Texturdaten, im gleichen Erweiterungsstrom übertragen oder getrennt in einem zweiten
Erweiterungsstrom.
MPEG4-FGS ist nicht für beliebig geformte Objekte, sondern nur für rechteckige Objekte
einsetzbar.
Skalierbarkeit durch Objektrepräsentationen
Das OD-Framework erlaubt, mehrere alternative Objektrepräsentationen des gleichen
Objektes innerhalb einer Objektbeschreibung anzugeben. So kann ein Objekt auf einfache
Weise in verschiedenen Qualitäten kodiert, angeboten und übertragen werden. Die
korrespondierenden Medienströme werden unabhängig von einander als Elementarströme
generiert. Die Elementarstrom-Deskriptoren übertragen für jeden Elementarstrom die
notwendigen Beschreibungsinformationen. Sie werden innerhalb einer Objektbeschreibung
zusammengefasst. Der Client selektiert anhand der QoS-Anforderungen, die von den
Elementarstrom-Deskriptoren angegeben sind, den Elementarstrom aus der
Objektbeschreibung, der am Besten an die eigene Rechen- und Speicherkapazität
angepasst ist. Diesen Elementarstrom fordert der Client nun bei der angegebenen Lokalität
an. Der Ablauf kann in Abb. 46) nachvollzogen werden.
76
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 46) Selektion eines Elementarstroms eines Objekts bestimmter Qualität (Ref: [17] S.76)
6.1.5.5. Fehlerrobuste Quellenkodierung visueller MPEG4-Sequenzen
Fehlerrobuste Quellenkodierung erhöht die Möglichkeit, einen großen Teil eines korrupten
Bitstromes korrekt dekodieren zu können. Je robuster der Code, umso mehr Daten können
von einem fehlerbehafteten Bitstrom dekodiert werden. Eine robuste Dekodierungstechnik
muss in der Lage sein, einen Fehler im Strom zu erkennen, ihn mit der höchstmöglichen
Präzision zu lokalisieren und den Bitstrom direkt nach dem Fehler korrekt zu dekodieren.
MPEG4 stellt fünf verschiedene „Error resilience Tools“ zur Verfügung, um eine
fehlerrobuste Struktur des kodierten Videostroms zu erreichen.
Paketbasierte Resynchronisation
Durch die variable Lauflängenkodierung (VLC) sind komprimierte Daten sehr sensibel
gegenüber Transportfehlern. Die Codewortlängen sind durch VLC implizit angegeben.
Transportfehler führen meist zu einer inkorrekten Anzahl von Bits, die für die VLCDekodierung genutzt werden. Der Decoder verliert die Synchronisation zum Encoder und
die gesamten nachfolgenden Daten des Bitstromes werden unbrauchbar.
Durch im Bitstrom enthaltene Resynchronisationsmarken (siehe Abb. 48) kann sich ein
Decoder wieder mit dem Strom synchronisieren. Diese Marken sind eindeutige
Codewörter (Bitsequenzen) die in kodierten Datenelementen nicht auftreten können. Ein
Übertragungsfehler kann vom Decoder erkannt werden, wenn ungültige VLC-Werte
während der Dekodierung auftreten. Wird ein Fehler erkannt, so verwirft der Decoder alle
Daten bis zur nächsten Resynchronisationsmarke. Die nachfolgenden Daten können wieder
korrekt dekodiert werden. Bei der paketbasierten Resynchronisation werden die Marken
periodisch, nach einer definierten konstanten Anzahl von Bits, in den Bitstrom eingefügt.
Die Bits zwischen zwei Marken entsprechen einem MPEG4-Videopaket. Videopakete
besitzen einen Header und einen Datenteil. Der Header enthält unter anderem die
77
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Resynchronisationsmarke, die Makroblocknummer des ersten Makroblockes, mit der die
räumliche Position des Makroblocks in der VOP festgelegt wird und die
Quantisierungsstufe für diesen Makroblock (siehe Abb. 47). Im Datenteil des Pakets ist
eine bestimmte Anzahl aufeinander folgender, kodierter Makroblöcke enthalten.
Abb. 47) Aufbau eines MPEG4 Videopakets
Jeder Makroblock gehört zu genau einem Videopaket. Die Makroblöcke werden durch die
Paketierung also nicht geteilt, sondern jeweils vollständig durch ein Videopaket
übertragen.
Abb. 48) Beispiel Paketbasierte Resynchronisation
Data Partitioning
Wenn ein Fehler im Bitstrom erkannt wurde und die Resynchronisation auf die nächste
Resynchronisationsmarke erfolgt ist, werden üblicher Weise alle Daten verworfen, die
zwischen diesen Resynchronisationsmarken liegen. Um einen Fehler präziser lokalisieren
zu können, gruppiert Data Partitioning die Bitstromelemente (DC und AC Koeffizienten,
Bewegungsvektoren) nach ihrer Fehlersensitivität. Der gleiche Fehler in verschiedenen
Gruppen kann unterschiedliche Auswirkungen auf die Qualität der dekodierten Sequenz
haben. Die wichtigsten Daten werden im ersten Teil des Videopakets übertragen. Danach
folgen ein eindeutiges Synchronisationswort und die Daten mit niedrigerer Priorität. Durch
das zusätzliche Synchronisationswort im Videopaket ist es möglich, einen Teil der Daten
des Paketes korrekt zu dekodieren, auch wenn im anderen Paketbereich ein
Übertragungsfehler die Daten unbrauchbar gemacht hat. Data Partitioning wird für I- und
78
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
P-VOP’s und für Binary Shape Coding bereitgestellt. Ein Videopaket, das mit Data
Partitioning für die Übertragung von DCT-Koeffizienten einer I-VOP erzeugt wurde, hat
folgenden Aufbau:
Abb. 49) Videopaket im Data Partitioning Modus für DCT-Werte von I-VOP’s
Bei der Paketierung von P-VOP’s in Videopakete werden die Bewegungsvektoren,
entsprechend der Abb.
49), durch ein Synchronisationswort (MM) von den
Texturinformationen getrennt.
Abb. 50) Videopaket im Data Partitioning Modus für Bewegungsvektoren und Texturdaten von P-VOP’s
Reversible Variable Length Coding (RVLC)
Nachdem die Resynchronisation des Decoders auf den Bitstrom erfolgreich abgeschlossen
ist, ermöglichen Recovery Tools, so viele Daten wie möglich zwischen der vorherigen und
der aktuellen Resynchronisationsmarke wieder herzustellen. Eine Datenwiederherstellung
kann durch Reversible Variable Length Coding (RVLC) erfolgen. RVLC ist eine spezielle
VL-Kodierung, mit der Codewörter eindeutig vorwärts, aber auch rückwärts dekodiert
werden können. Wenn ein Fehler in einem vorwärtskodierten Bitstrom erkannt wurde,
sucht der Decoder die nächste Resynchronisationsmarke und dekodiert den Bitstrom
rückwärts, bis wiederum ein Fehler auftritt. Somit werden nicht mehr alle Daten zwischen
zwei Resynchronisationsmarken verworfen, sondern nur noch ein Teil der Daten. Die
Lokalisierung des Fehlers kann bedeutend präziser erfolgen. RVLC wird vom MPEG4Standard nur im Zusammenhang mit Data Partitioning vorgeschlagen. Dort soll es für die
Kodierung/Dekodierung des zweiten Paketabschnitts (AC-Werte, bzw. Texturdaten)
eingesetzt werden. Den Wiederherstellungsprozess durch RVLC gibt die Abb. 51)
grafisch wieder.
79
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 51) Datenwiederherstellung mit RVLC
Header Extension Code
Die wichtigsten Informationen eines MPEG4-Bitstromes sind in den jeweiligen Headern
der MPEG4-Strukturelemente (VOL, VOP, GOV, VO,...) enthalten. Um diese Daten für
die Übertragung gesondert abzusichern, können sie redundant als Kopie im Header
Extension Code (HEC) übertragen werden. Der HEC befindet sich im Header eines
Videopakets direkt nach den Quantisierungsinformationen für den ersten Makroblock
(siehe Abb. 52). Wie oft HEC-Informationen im Bitstrom enthalten sind, wird vom
MPEG4-Standard nicht vorgeschrieben. Zu beachten ist, dass HEC zusätzlichen Overhead
erzeugt und somit die Kodiereffizienz vermindert.
Abb. 52) Aufbau eines MPEG4-Videopakets mit HEC
New Prediction
Ein Übertragungsfehler wirkt sich nicht nur auf die beschädigte VOP, sondern auch auf
alle VOP’s aus, die die beschädigte VOP als zeitliche Referenz nutzen. Der
Übertragungsfehler wird solange von P- und B-VOP’s weiterpropagiert, bis die nächste IVOP dekodiert wird. Im MPEG2-Standard werden für diesen Fall häufiger I-Frames im
Bitstrom übertragen. Dieser Lösungsvorschlag senkt die Kodiereffizienz jedoch erheblich.
Die NEWPRED-Technik des MPEG4-Standards vermindert die Verbreitung von Fehlern,
ohne die Kodiereffizienz zu stark zu beeinflussen. NEWPRED nutzt einen Rückkanal (im
OD definierbar), um den Encoder über ein fehlerhaftes NEWPRED-Segment (eine VOP
oder ein Videopaket) zu informieren. Der Encoder schließt die fehlerhafte VOP bzw. den
fehlerhaften Teil der VOP sofort als zeitliche Referenz für nachfolgende VOP’s aus. Für
jedes NEWPRED-Segment wird vom Decoder eine Nachricht an den Encoder gesendet,
80
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
mit der das Segment als korrekt oder inkorrekt dekodiert signalisiert wird. Da ein
fehlerhaftes Segment nicht mehr als zeitliche Referenz genutzt werden kann, muss ein
älteres Segment als Referenz eingesetzt werden. Die Differenz zwischen dem aktuell
kodierten Segment und dem nun älteren referenzierten Segment ist meist groß. Auch die
Bewegungsvektoren haben größere Werte, sodass insgesamt die kodierte Sequenz ein
höheres Datenvolumen besitzt.
6.1.5.6. MPEG4 Audio (Part 3)
Der MPEG4-Standard definiert vier unterschiedliche Audiocoder, die jeweils an die
Kodierung bestimmter Audiosignaltypen angepasst sind. Die Audiotypen sind natürliche
Sprache, natürliche Audiosignale, synthetische Sprache und synthetische Audiosignale.
Die Coder werden unterschieden in Time/Frequenzy-basierte Coder und NonTime/Frequenzy-basierte Coder. Die T/F-Coder fassen alle Audiocoder zusammen, die
nach dem Paradigma der wahrnehmungsabhängigen Kodierung eine spektrale
Repräsentation des Eingangssignals erzeugen. Hierzu zählen die AAC-Coder von MPEG2
und MPEG4 sowie die TwinVQ-Kodiertechnik von MPEG4. Die Non-T/F-Coder
analysieren und synthetisieren die Audiosignale nach definierten Modellen (z.B.
Sprachmodelle). Die MPEG4-Coder CELP und HVXC, für natürliche oder synthetische
Sprache, gehören zu den Non-T/F-Codern.
Der MPEG4-AAC-Standard entspricht grundlegend dem MPEG2-AAC-Standard. Es
wurden einige Erweiterungen implementiert, um die Kodiereffizienz zu erhöhen,
skalierbare Kodierung von Audiosequenzen zu ermöglichen und neue Funktionen für den
Fehlerschutz und für die Verbesserung der Fehlerrobustheit anzubieten. Die wichtigsten
neuen Module sind Perceptual Noise Substitution, Long Term Prediction, Transform
Domain Weighted Interleave Vector Quantization (TwinVQ), Low Delay AAC, Error
Resilience und Scalable Audio Coding.
Ich werde hier nur auf die für diese Arbeit relevanten Techniken, Scalable Audio Coding
und Error Resilience, eingehen.
Scalable Audio Coding
Mit der skalierbaren Audiokodierung soll ermöglicht werden, die Übertragungsrate
dynamisch an einen Übertragungskanal anzupassen, dessen Charakteristik während des
Kodiervorganges noch nicht bekannt war. Grundsätzlich unterscheidet der MPEG4-AudioStandard zwei Verfahren für die skalierbare Audiokodierung: Large Step Scalable Audio
Coding und Bit Sliced Arithmetic Coding
81
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Large Step Scalable Audio Coding
Dieser Kodiermechanismus basiert auf dem Konzept der hierarchischen eingebetteten
Kodierung, vergleichbar zur qualitativ skalierbaren Kodierung (SNR) von Videoobjekten.
Prinzipiell folgt der Kodiervorgang folgendem Ablauf:
Der Basisdatenstrom kann völlig unabhängig vom Erweiterungsdatenstrom vom Decoder
dekodiert werden. Jeder Erweiterungsdatenstrom verbessert im Dekodiervorgang die
Qualität des rekonstruierten Ausgangssignals. Die Werte der spektralen Koeffizienten der
Erweiterungsdatenströme werden dazu einfach mit den Informationen aus der Basisschicht
summiert.
In der Praxis ist für die Sprachkodierung die Kombination - Encoder der Basisschicht:
CELP, Erweiterungsdatenstrom: AAC - am sinnvollsten. Für die skalierte Kodierung von
Musiksignalen sollte in der Basisschicht TwinVQ und in den Erweiterungsschichten AAC
eingesetzt werden.
Bei der Bitstromstruktur werden für Large Step Scalable Audio Coding exakte
Spezifikationen formuliert:
•
Die syntaktischen Elemente eines Bitstroms sind für alle Schichten des skaliert
kodierten Signals gültig und werden in der Basisschicht übertragen.
•
Die MPEG4-AAC-Syntax unterstützt keine Multikanalsignale. Somit kann nur
Mono- oder Stereomaterial in einem skalierten Bitstrom übertragen werden.
Bit Sliced Arithmetic Coding (BSAC)
BSAC ist die Alternative zu Large Step Scalable Audio Coding. Mit diesem Tool sollen
die Hierarchiestufen zwischen Basis- und Erweiterungsdatenstrom bzw. zwischen den
Erweiterungsdatenströmen feiner granuliert werden. Damit werden Anforderungen erfüllt,
bei
denen
die
Erweiterungsdatenströme
ebenfalls
sehr
beschränkten
Übertragungskapazitäten unterliegen. Die spektralen Koeffizienten der Audiosignale
werden „bit-plane“-kodiert. Die absoluten Werte der Koeffizienten werden dazu bitweise,
entsprechend ihrer Signifikanz, in Slices (Ebenen) aufgeteilt, beginnend mit dem MSB bis
zum LSB. Jede Ebene wird durch einen Arithmetik-Coder entropiekodiert. Der
Basisdatenstrom überträgt die Quantisierungsfaktoren, sowie die ersten Slices der
spektralen Daten (MSB-Ebene). Die Erweiterungsdatenströme enthalten, entsprechend
ihrer Übertragungskapazität, weitere Slices. Der Datenstrom der obersten
Erweiterungsschicht überträgt die spektralen Daten der LSB-Ebene. Je mehr
Erweiterungsdatenströme den Decoder erreichen, umso höher ist die resultierende
Signalqualität des dekodierten Audiosignals.
82
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.1.5.7. Fehlerrobustheit / Fehlerabsicherung auditiver MPEG4-Sequenzen
Im MPEG4-Audio-Standard werden fünf neue codespezifische Tools definiert, die die
Fehlerrobustheit erhöhen und sogar eine Fehlerabsicherung erlauben:
•
Virtual Codebook
•
Reversible Variable Length Coding (RVLC)
•
Huffman Codewort Reordering (HCR) für Advanced Audio Coding
•
Error Resilient Bitstream Reordering
•
Error Protection (EP)
Im „Error Resilient Bitstream Reordering“-Verfahren wird die Information eines
Audioframes in Segmente zerlegt. Die Segmente werden abhängig von ihrer
Fehlersensitivität in verschiedene Fehlerklassen (Error Sensitivity Categories - ESC)
eingeordnet. Die Segmentierung kann mit Datenelementen oder bitweise vorgenommen
werden. Zusätzlich werden die Bits oder Datenelemente nach ihrer Fehlersensitivität
umsortiert. Die fehlerempfindlichsten Daten sollten sich nach der Umsortierung am
Anfang des Frames befinden. Für die unterschiedlichen Fehlerklassen sind jeweils
angepasste Fehlersicherungsmaßnahmen wie FEC, CRC oder ARQ einsetzbar. Diese Idee
entspricht dem Unequal Error Protection (UEP)-Ansatz und wird durch ein Error
Protection Tool (EP) im MPEG4-Audio-Standard bereitgestellt. Die Segmente einer
Fehlerklasse werden zu Error Resilience Frames zusammengefasst und mit dem
Fehlersichungsmechanismus abgesichert, der für die Fehlerklasse definiert wurde.
Das EP-Tool stellt eine Fehlerabsicherung für MPEG4-Audioströme bereit, deren Daten
mit Error Resilient Bitstream Reordering vorverarbeitet wurden (siehe Abb. 53). UEP ist
hier eine effiziente Methode, um die Fehlerrobustheit von Quellcodes zu erhöhen, wobei
den wichtigen Daten höhere Fehlerabsicherungen garantiert werden als den weniger
wichtigen Daten.
Abb. 53) Blockdiagram - Error-Protection-Tool [17] S.479
83
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Der UEP-Encoder erhält Segmente eines Audioframes, die in „Error Sensitivity
Categories“ eingeordnet sind. Das EP-Tool ordnet wiederum eine ESC oder eine
Kombination mehrerer ESCs einer EP-Klasse zu (siehe Tabelle 7: ). Die EP-Klassen
entsprechen Gruppen, denen FEC-Codes und/oder CRC-Codes unterschiedlicher Stärke
zugeordnet werden.
EP-Klasse 1
EP-Klasse 2
EP-Klasse 3
EP-Klasse 4
EP-Klasse 5
EP-Klasse 6
ESC0 Bits beider Frames
ESC1 Bits des ersten Frames
ESC2 Bits des ersten Frames
ESC1 Bits des zweiten Frames
ESC2 Bits des zweiten Frames
ESC3 Bits beider Frames
Tabelle 7: Zuordnungsbeispiel EP-Klasse <-> ESC
Als Beispiel wird folgende Klassentabelle des EP-Tools vorgestellt, in der für jede EPKlasse FEC- und CRC-Absicherungen definiert sind:
Quellcoder Bits
CRC Polynomgrad
FEC Kodierrate
Gesamtanzahl Bits
EP-Klasse
1
44
6
8/16
100
EP-Klasse
2
4
1
8/8
5
EP-Klasse
3
4
1
8/8
5
EP-Klasse
4
4
1
8/8
5
EP-Klasse
5
4
1
8/8
5
EP-Klasse
6
20
0
8/8
20
Tabelle 8: Fehlersicherungsmaßnahmen für EP-Klassen
Der Klasse 1 wird das höchste Gewicht eingeräumt. Übertragungsfehler können durch ein
CRC-Polynom sechsten Grades, also mit einer 6 Bit großen Prüfsequenz, erkannt werden.
Zusätzlich kann eine gewisse Anzahl gekippter Bits eines fehlerhaften Frames der 1.
Klasse mit Hilfe der durch FEC angefügten 8 Bit großen Redundanz korrigiert werden.
Die Klassen 2-5 werden durch ein Paritätsbit abgesichert, für die Klasse 6 sind keine
Sicherungsmaßnahmen vorgesehen.
Der MPEG4-Standard bietet optimale Voraussetzungen für die Implementierung des
spezifizierten Multisource-Streaming-Ansatzes.
Die Schichtenarchitektur des MPEG4-System-Parts trennt den Kodierprozess vom
Verteilungsprozess. Somit können die kodierten multimedialen Daten auch in heterogenen
Netzwerken transportiert werden. Durch die DMIF-Schnittstelle ist die Verteilung
MPEG4-kodierter Sequenzen mit allen aktuellen und auch zukünftigen Netzwerktechniken
möglich.
Multimediale Daten können so skalierbar kodiert werden, dass die gesamte Breite
verfügbarer, multimedialer Endgeräte die vollständige Sequenz oder mindestens eine
Teilmenge der Sequenz dekodieren und wiedergeben kann.
84
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Das Objektparadigma erlaubt effiziente und völlig neue Konzepte für die skalierbare
Kodierung und die unabhängige Verteilung von Elementen einer Multimediasequenz.
Die Trennung der Meta- und Konfigurationsinformationen von den kodierten,
multimedialen Daten bietet weitere Möglichkeiten für den Verteilungsprozess an.
Verbesserte und neue Mechanismen erhöhen die Fehlerrobustheit, die Fehlertolleranz, die
Fehlererkennungs- und Fehlerlokalisierungsmöglichkeiten einer kodierten Sequenz. Sogar
Fehlerschutz durch Datenredundanz wird durch den MPEG4-Standard angeboten. Der
Transport kodierter Multimediasequenzen über verlustbehaftete Transportkanäle wird
somit bereits durch die Quellenkodierung unterstützt.
Für Audiosequenzen bietet der MPEG4-Standard erstmals die Möglichkeit einer
skalierbaren Kodierung an.
Die Kodiereffizienz wurde gegenüber früheren Standards nocheinmal erheblich verbessert,
sodass die zu vermittelnde Datenmenge, bei gleicher oder sogar besserer
Wiedergabequalität, weiter reduziert werden konnte.
Grundlegend werden alle Forderungen der Anforderungsanalyse an das einzusetzende
Kodierverfahren und die resultierende multimediale Datenstruktur durch MPEG4 erfüllt.
Das standardisierte MPEG4-Kodierverfahren wird deshalb für die Integration in die
Implementierung des Multisource-Streaming-Ansatzes ausgewählt.
85
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.2. Untersuchung von Protokollen der Anwendungsschicht
Die Spezifikation des Multisource-Streaming-Ansatzes fordert nicht nur eine
Untersuchung geeigneter Transportprotokolle für die Verteilung der multimedialen Daten.
Bereits auf der Anwendungsebene sind Kommunikationsprozesse notwendig, die den
Informationsaustausch zwischen Server und Client und im Besonderen die Steuerung des
Streamprozesses ermöglichen. Diese notwendigen Kommunikationsprozesse erfordern
eine Analyse verfügbarer Protokolle in der Anwendungsschicht.
6.2.1. Real Time Streaming Protokoll (RTSP)
An dieser Stelle wird nur eine Einführung in das Steuerprotokoll RTSP gegeben, um die
Stellung dieses Protokolls im funktionellen Ablauf der Datenvermittlung darzulegen.
Interessierte erhalten unter [3] nähere Informationen über das Protokoll.
6.2.1.1. Allgemeine Beschreibung
RTSP ist ein Protokoll, das in die Anwendungsschicht des ISO/OSI-Referenzmodells
eingeordnet werden kann. Es kontrolliert die Verteilung von Daten mit
Echtzeitanforderungen, wie z.B. Audio- und Videodaten. Dabei unterstützt es die
Verteilung gespeicherter, audiovisueller Daten sowie die Verteilung von Live-StreamingDaten über verschiedene Transportprotokolle (TCP, UDP, RTP,...). Es ist nicht selbst für
die Verteilung der Daten verantwortlich, sondern tritt als Signalisierungsprotokoll
zwischen dem Stream-Client und dem Stream-Server auf. Der Stream-Server kann über die
definierten Kommandos des RTSP - Protokolls vom Client gesteuert werden.
6.2.1.2. Operationen und Eigenschaften des RTSP-Protokolls
Der RTSP-Server verwaltet eindeutig bezeichnete Sessions. Eine Session beschreibt die
Kommunikationsbeziehung zwischen einem Stream-Client und einem Stream-Server. Eine
RTSP-Session ist nicht an eine bestimmte Transportverbindung gebunden. Der Client kann
während einer Session verschiedene Datentransportverbindungen öffnen und schließen, um
RTSP-Kommandos für diese Session zu senden. Die Session ist zwischen Client und
Server eindeutig über eine Session-ID identifizierbar.
Die Eigenschaften, eines vom Server angebotenen Services, werden in einer
Präsentationsbeschreibung festgehalten. Das Format dieser Beschreibung ist kein Teil des
RTSP-Standards. Hauptsächlich wird hierfür das Stream Discription Protocol (SDP)
verwendet. Die Präsentationsbeschreibung enthält Angaben über die Lokalität und die
Eigenschaften aller zum Service gehörenden Mediaströme (z.B. Audio, Video).
86
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Das RTSP-Protokoll unterstützt folgende Operationen:
•
Informationen über die verfügbaren Services eines Stream-Servers abrufen
Der Client kann eine Präsentationsbeschreibung einer gewünschten
Multimediasequenz über HTTP oder auf einem anderen Weg von einem Server
abrufen. Verwendet die Präsentation Multicast, so enthält die Beschreibung die
Multicast-Adressen und Ports, die für die Übertragung der kontinuierlichen
Medienströme benutzt werden sollen. Wird die Präsentation nur an den Client
übertragen, gibt der Client aus Sicherheitsgründen das Ziel vor.
•
Einladung eines Stream-Servers zu einer Konferenz
Ein Server kann zu einer bestehenden Konferenz „eingeladen“ werden, um Medien
in der Präsentation abzuspielen. Dieser Modus ist nützlich für OnlineLernapplikationen.
•
Hinzufügen von zusätzlichen Medien zu einer existierenden Präsentation
Besonders für Live-Präsentationen ist es nützlich, dass man den Client über neue,
zusätzlich verfügbar gewordene Medien informieren kann.
•
Steuerung eines Stream-Servers
Der Client kann den Streamvorgang mit Hilfe des RTSP-Protokolls starten,
stoppen und zwischenzeitlich anhalten. Der Client kann sogar ein definiertes
Zeitintervall für einen gewünschten Teil des Mediaservice angeben. Der
Streamvorgang beginnt in diesem Fall zum gewählten Startzeitpunkt und endet am
gewünschten Endzeitpunkt des Intervalls.
Zu diesen grundlegenden Funktionen muss die folgende Auswahl weiterer wichtiger
Eigenschaften des Protokolls genannt werden:
•
Erweiterbarkeit: Neue Methoden und Parameter können hinzugefügt werden.
•
Einfach zu interpretieren: RTSP kann mit jedem üblichen HTTP- oder MIMEParser interpretiert werden.
•
Transportprotokollunabhängigkeit: RTSP setzt nicht voraus, dass ein bestimmtes
Datentransportprotokoll - wie etwa UDP, RTP oder TCP - verwendet wird.
•
Multi-Server: Jeder Medienstrom einer Präsentation kann auf einem anderen
Server abgelegt sein. Der RTSP-Client richtet automatisch mehrere Sessions für
die Server ein. Synchronisation wird in der Transportschicht gewährleistet.
•
Transport verhandeln: Der Client kann die Transportmethode mit dem Server
aushandeln, bevor er einen Medienstrom empfängt.
87
Diplomarbeit
•
Inv.Nr.: 2004-11-03/096/IN99/2253
Sicherheit: RTSP nutzt Websicherheitsmechanismen die zum Beispiel über HTTP
zur Verfügung gestellt werden.
6.2.1.3. Protokollablauf / RTSP-Kommandos
Die Präsentationsbeschreibung wird durch eine RTSP-URL identifiziert und ist als Datei
unter dieser URL abgelegt. Ist ein Client an der Multimediasequenz dieser Session
interessiert, dann fordert er über einen Descripe Request die Präsentationsbeschreibung
von dieser URL an.
Innerhalb der Präsentationsbeschreibung wird jeder Mediastrom des Services wiederum
durch eine URL identifiziert, die auf den Stream-Server verweist, der den Mediastrom
bereitstellt. Für jeden Mediastrom kann ein eigenes Transportprotokoll definiert werden. In
der Anfrage für die Präsentationsbeschreibung werden vom Client die Clientadresse und
der Clientport als Ziel für den Server angegeben.
Nachdem die Präsentationsbeschreibung den Client erreicht hat, fordert der Client bei den
entsprechenden URL’s die einzelnen Medienströme an. Das wird durch die Setup-Methode
des RTSP-Protokolls erreicht. Die Setup-Methode führt serverseitig zur Initialisierung des
Übertragungskanals für den angeforderten Mediastrom und den Beginn der RTSP-Session.
Durch eine Serverantwort wird dem Client die zur Session gehörende Session-ID
mitgeteilt.
Mit einem Play-Request des Clients an den Server, beginnt der Server den Medienstrom
über den im Setup initialisierten Kanal an den Client zu übertragen.
Ein Pause-Request des Clients an den Server stoppt den Streamvorgang, ohne die
Ressourcen des Übertragungskanals freizugeben.
Der Teardown Request des Clients an den Server beendet den Streamvorgang bzw. die
RTSP-Session. Alle reservierten Ressourcen werden freigegeben.
6.2.2. Session Description Protocol (SDP)
Hier soll eine Einführung in das Session Description Protocol gegeben werden, wobei der
Zweck und der Umfang von SDP dargelegt wird. Es wird nur auf die grundlegenden
Eigenschaften, Syntaxelemente und die Struktur des Protokolls eingegangen. Erweiterte
Informationen erhält der Leser unter [4].
6.2.2.1. Einsatzgebiet
SDP kann von einem Stream-Server zur Beschreibung der verfügbaren Präsentationen und
der in den Präsentationen enthaltenen Medien verwendet werden. Der Stream-Server liefert
auf eine Serviceanfrage eine Präsentationsbeschreibung (Session Description) für den
88
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Service an den anfragenden Client aus. Die Beschreibung enthält Informationen, mit deren
Hilfe der Client die Medienströme einer Präsentation initialisieren und anfordern kann.
Ebenso sind Parameter für den Datentransport in dieser Beschreibung enthalten. Das
Beschreibungsformat unterliegt dabei strengen Syntax- und Sematikregeln, die durch das
Session Description Protocol vorgegeben werden.
6.2.2.2. Struktur
Eine SDP-Präsentationsbeschreibung besteht aus zwei Teilen. Der erste Teil, die Session
Level Description (SLD), ist für die gesamte Präsentationsbeschreibung gültig und somit
auch für alle Medienströme der Präsentation. Der zweite Part besteht aus ein oder
mehreren Media Level Description (MLD). Jede MLD enthält erweiterte Informationen,
die für genau einen Mediastrom gültig sind.
6.2.2.3. Syntax und Semantik
Die Syntax der Textzeilen ist durch die Verwendung des ISO10646-Zeichensatzes in UTF8-Kodierung (siehe [5]) vorgegeben.
SDP-Feldnamen und Attributnamen nutzen nur den US-ASCII-Teil von UTF-8. Textfelder
und Attributwerte können den vollen ISO 10656-Zeichensatz verwenden.
Die Textform wurde gewählt, um die Portabilität zu erhöhen, eine Reihe verschiedener
Transportmöglichkeiten zu erschließen (z.B. Session-Description über eine MIME E-Mail)
und um die Erzeugung und Verarbeitung mit flexiblen, textbasierten Toolkits (z.B. Tcl/Tk)
zu ermöglichen.
Eine SDP-Präsentationsbeschreibung besteht aus einer Anzahl von Textzeilen der Form
<type>=<value>. Zu beiden Seiten des ‚=’-Zeichens sind Leerzeichen verboten.
Der Feldname (<type>) enthält immer genau ein Zeichen (Groß- und Kleinschreibung wird
unterschieden).
Der Wert eines Feldes (<value>) ist ein strukturierter Text dessen Format vom Feldnamen
abhängt (Groß- und Kleinschreibung wird ebenfalls unterschieden).
Ein Feldwert enthält eine Anzahl von Feldern, die durch einzelne Leerzeichen voneinander
getrennt sind, oder er besteht aus einem freien String.
Die Session Level Description beginnt mit den folgenden drei Zeilen:
89
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
optional folgen die Zeilen:
Die Zeitinformationen für die Gültigkeit der Präsentation werden durch folgende TimeDescription angegeben:
Die Media Level Description ist folgendermaßen aufgebaut:
Besonders
hervorzuheben
ist
die
Möglichkeit,
über
Attribute
die
Beschreibungsmöglichkeiten des Session Description Protocols zu erweitern und an die
eigenen
Beschreibungswünsche
anzupassen.
Hier
können
erweiterte
Konfigurationsangaben für die gesamte Präsentationsbeschreibung oder einzelne
Mediaströme gemacht werden.
Im SDP-Standard sind einige Attribute bereits vorgegeben. Es lassen sich jedoch beliebige
neue Attribute implementieren. Attribute die vom Client nicht erkannt werden können,
werden nicht interpretiert, sondern beim Auslesen übersprungen.
Weitere Informationen über die benutzerdefinierten Attribute der Präsentationsbeschreibung erhält man in der „ISMA-Implementation Specifikation 1.0“ (siehe [43]).
Im Anhang F wird ein Beispiel einer vollständigen SDP-Präsentationsbeschreibung
dargestellt und erläutert.
90
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.3. Untersuchung von Protokollen der Transportschicht
In diesem Abschnitt werden verfügbare Protokolle der Transportschicht mit den
Anforderungen der Spezifikation verifiziert. Im Allgemeinen werden keine Details über
die Funktionsweise oder die syntaktischen Elemente der Protokolle beschrieben. Viel mehr
wird ein Überblick über die grundlegende Idee der Protokolle gegeben.
6.3.1. Transport Control Protocol (TCP)
Das Transport Control Protocol hat sich in drahtgebundenen Netzen hervorragend
etabliert. Es stellt eine sichere, Datenstrom-basierte, Ende-zu-Ende-Verbindung zwischen
Netzwerkknoten zur Verfügung und erlaubt eine effiziente, schnelle Datenübertragung
großer Datenmengen. Eine Flusskontrolle stellt sicher, dass ein Sender selbständig die
optimale Nutzlast für eine gegebene Netzkapazität einstellen kann.
Die Spezifikationen für eine drahtlose Datenübertragung unterscheidet sich jedoch enorm
von den Anforderungen, die aus drahtgebundenen Netzen bekannt sind. Die Fehlerrate
einer drahtgebunden Verbindung ist sehr gering. Fehler entstehen hauptsächlich durch
Überlastung an einem Netzwerkknoten, selten jedoch durch externe Störfaktoren.
In einer drahtlosen Umgebung ist die Fehlerrate bedeutend höher. Übertragungsfehler
entstehen nicht nur durch eine Überlast, sondern stochastisch durch Abschattung,
Echobildung und andere externe physikalische Störgrößen.
Gerade die effizienten Algorithmen der Flusskontrolle von TCP sind deshalb für die
drahtlose Übertragung problematisch.
TCP kann nicht zwischen verschiedenen Fehlerursachen unterscheiden. Für alle
aufgetretenen Verluste wird angenommen, dass sie aus einer Stausituation im
Netzwerkpfad entstanden sind. Auf Grund dieser Annahme ergreifen die TCPMechanismen Gegenmaßnahmen, die für drahtlose Netzwerke völlig falsch sein können.
Die Fehler- und Flusskontrolle bewirkt zudem eine Zeitverzögerung bei der
Datenübertragung, sodass TCP für die Übertragung zeitkritischer Elemente nicht geeignet
ist.
6.3.2. User Datagram Protocol (UDP)
Das User Datagram Protocol ist ein sehr einfaches Transportprotokoll, das mit wenig
Aufwand den Datenaustausch zwischen Netzwerkknoten ermöglicht. Das Protokoll
arbeitet verbindungslos und unzuverlässig. Es übernimmt keine Garantie, dass die
Dateneinheiten ihr Ziel erreichen und in einer bestimmten Reihenfolge ankommen. Die
einfache Funktionsweise des Protokolls erlaubt jedoch eine Datenübertragung mit sehr
geringer zusätzlicher Verarbeitungsverzögerung. Deshalb ist UDP für die Vermittlung
zeitkritischer Daten geeignet. Da UDP selbst keine Flusssteuerung und keine
91
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Fehlerbehandlung bereitstellt, müssen diese Funktionen von den Anwendungen der
Netzwerkknoten selbst übernommen werden.
6.3.3. Realtime Transmission Protocol (RTP)
Das
Realtime
Transmission
Protocol
unterstützt
Ende-zu-EndeNetzwerktransportfunktionen, die hauptsächlich auf die Übertragung von zeitkritischen
Daten, wie Audio- und Videodaten ausgerichtet sind. RTP ist kein „vollständiges“
Transportprotokoll. Es kann nicht als alleiniges Transportprotokoll eingesetzt werden, da
zum Beispiel Angaben über die Sender- und die Empfängeraddressen fehlen.
Typischerweise wird RTP deshalb im Zusammenhang mit UDP eingesetzt, jedoch wird
keine Einschränkung bei der Transportprotokollwahl vorgenommen. RTP bietet selbst
keine Möglichkeiten für Ressourcenreservierungen oder die Bereitstellung von QoS für
Übertragungskanäle an. Es nutzt jedoch die QoS-Dienste unterer Schichten des ISO/OSIReferenzmodells. RTP sichert den Datentransport nicht ab und gibt deshalb keine Garantie
für die Vollständigkeit und die Fehlerlosigkeit von empfangenen Paketsequenzen.
Über ein exklusives Steuerprotokoll, das Realtime Transmission Control Protocol können
jedoch empfängerseitige und senderseitige Abschätzungen der Güte des
Übertragungskanals vorgenommen werden.
6.3.3.1. Syntax
Da RTP für die Übertragung zeitkritischer Informationen sehr geeignet erscheint, soll mit
einer erweiterten Analyse ein tieferer Einblick in die Protokollsyntax gegeben werden.
Die Syntax des Realtime Transmission Protocols ist im RFC 3550 spezifiziert (siehe [1]).
Das Realtime Transmission Protocol unterstützt die Übertragung zeitkritischer Daten mit
Hilfe eines kleinen fixen Headers. Der Header besitzt die folgende Struktur:
Abb. 54) RTP-Header (Referenz: [1] S.13)
92
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die wichtigsten Informationen für den Transport multimedialer Daten sind in den
Headerfeldern Payload-Type, Sequence Number, Timestamp und Synchronization Source
Identifier (SSRC) enthalten.
Die 16 Bit große Sequenznummer erhöht sich für jedes RTP-Datenpaket um eins und
beginnt sicherheitstechnisch mit einem zufälligen Wert. Die Sequenznummer ist für eine
ganze Reihe von wichtigen Mechanismen notwendig. Pakete die durch unterschiedliche
Übertragungswege durch das Netz ungeordnet beim Empfänger eintreffen, können mit
Hilfe der Sequenznummer in die korrekte Ordnung gebracht werden. Paketverluste sind
durch Lücken in der Nummernfolge leicht erkennbar. Somit kann eine Statistik über die
Paketverlustrate geführt werden, mit der ein Indiz für die Abschätzung der Güte des
Übertragungskanals zur Verfügung steht.
Der Zeitstempel (TimeStamp) enthält die Zeitinformation für den Präsentationszeitpunkt
der zu übertragenen multimedialen Dateneinheiten. So kann vom Empfänger bereits auf
der Transportschicht überprüft werden, ob die Informationen des Pakets zeitlich relevant
sind oder das Paket verworfen werden muss. Sehr wichtig ist diese Zeitinformation für die
Synchronisation mehrer zusammengehöriger Datenströme, die unabhängig von einander
über verschiedene Transportwege transportiert wurden. Pakete mit identischem
Zeitstempel beinhalten multimediale Elemente, die zum gleichen Zeitpunkt dargestellt
werden müssen (z.B. Audio- und Video-Elemente). Die Zeitstempel sind relative
Zeitangaben, die sich auf eine bestimmte Zeitbasis beziehen. Diese Zeitbasis muss für alle
zusammengehörenden Elementarströme identisch sein.
Mit Hilfe der kontinuierlichen Zeitstempel kann der Jitterwert, als ein weiterer Faktor zur
Beurteilung der Kanalgüte, berechnet werden. Diese Berechnung ist jedoch nur dann
korrekt, wenn RTP-Pakete mit einer konstanten Senderate übertragen werden.
Das Headerfeld Synchronization Source Identifier (SSRC) identifiziert einen
abgeschlossenen Sequenznummern- und Zeitstempelraum, der innerhalb einer RTPSession eindeutig ist.
Eine RTP-Session besteht aus einem Ende-zu-Ende-Transportweg, der über das Tupel
(Sender:Port, Empfänger:Port) definiert ist. Eine Multimediapräsentation besteht häufig
aus mehreren RTP-Sessions, die jeweils für den Transport eines Datenstromes zuständig
sind. Der SSRC-Identifier ist unabhängig vom Verbindungstupel. Das Tupel kann sich
während der Übertragung ändern. Der SSRC-Wert identifiziert den Medienstrom jedoch
immer noch eindeutig. Wenn sich die Netzwerkadresse des Senders ändert, dann sollte
jedoch auch der SSRC-Wert neu gewählt werden. So können Sendeschleifen verhindert
werden.
Das Feld Contributing Count (CC) sowie ein oder mehrere optional existierende
Contributing Source Identifier (CSRC) des RTP-Headers, sind für das Zusammenführen
(Multiplex) verschiedener Medienströme in einen RTP-Datenstrom notwendig.
93
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Contributing Count gibt dabei die Anzahl der gemultiplexten Medienströme an. Der
CSRC-Identifier identifiziert jeden Medienstrom im RTP-Datenstrom eindeutig. Zunächst
ist für den Multisource-Streaming-Ansatz eine verschachtelte Übertragung von mehreren
Elementarströmen in einem Datenstrom nicht vorgesehen, sodass die optionalen CSRCFelder für die Implementierung nicht benötigt werden.
Über das Extension Flag wird signalisiert, ob dem festen RTP-Header noch zusätzliche
Erweiterungsheader folgen.
Im Datenteil eines RTP-Pakets werden verschiedene Inhaltsformate (Payload-Types)
unterstützt, die auf die jeweils zu übertragenden Daten angepasst sind. Hier können zum
Beispiel durch zusätzliche Header weitere relevante Informationen für die zu
übertragenden Daten implementiert werden. Der Payload-Type gibt die Syntax und die
Struktur für den Datenteil des RTP-Pakets vor und signalisiert dem Empfänger bereits auf
der Transportebene, welche Datenformate im RTP-Paket zu erwarten sind.
Die Idee für die Definition verschiedener Payload-Formate war zunächst sehr güngstig. Bis
heute haben sich aber so viele Formate entwickelt, dass es sehr aufwändig und
kostenintensiv ist, Stream-Server und Stream-Clients zu erstellen, die alle Formate
unterstützen. Die „Internet Streaming Media Alliance“ (ISMA) hat eine offene, nicht
proprietäre Spezifikation erstellt, in der der Einsatz von RTP mit festgelegten PayloadFormaten für die Übertragung multimedialer Daten vorgeschlagen wird. Die Spezifikation
bezieht sich im Besonderen auf den Transport von Dateneinheiten, die gemäß dem
MPEG4-System-Standard, als Elementarströme kodiert wurden. Die Spezifikation gab der
Industrie die Möglichkeit, plattformübergreifende, zueinander kompatible und vom
Hersteller unabhängige Lösungen für die Übertragung von MPEG4-kodierten
Elementarströmen zu entwickeln. ISMA ist ein Konsortium, das aus über 30 führenden
Firmen der Unterhaltungselektronik und der Film- und Musikindustrie besteht. Weitere
Informationen über die Allianz und die Spezifikation erhält man in [43].
6.3.3.2. Fazit
RTP ist im Zusammenhang mit dem User Datagram Protocol als Transportprotokoll für
multimediale Daten gut geeignet. Es übermittelt die wichtigen Informationen (Zeitstempel,
Sequenznummer, Quellenname) bei einem kleinen und festen Overhead von 20 Byte pro
Dateneinheit (8Byte UDP-Header + 12 Byte RTP-Header). Die optionalen Erweiterungen,
um mehrere Medienströme in einen RTP-Datenstrom zu multiplexen, sind zunächst nicht
notwendig.
RTP selbst bietet wie bereits beschrieben keine eigenen Sicherheits- und
Überwachungsmechanisen für den Datentransport an. Die Sicherung und Überwachung
des Transports von zeitkritischen Daten ist jedoch unerlässlich. Deshalb ist ein zusätzliches
94
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Kontrollprotokoll notwendig. Im RFC 3550 ist ein Kontrollprotokoll beschrieben, das über
einen exklusiven Signalisierungskanal Überwachungs- und Sicherungsfunktionen, mit
Hilfe der Headerinformationen der RTP-Pakete bereitstellt, das Realtime Transmission
Control Protocol.
6.3.4. Realtime Transmission Control Protocol (RTCP)
Die Hauptaufgabe von RTCP ist es, ein Feedback über die Qualität der RTPDatenübertragung zu geben. Dabei werden die typischen Aufgaben eines
Transportkontrollprotokolls unterstützt. RTCP bietet eine Fluss- und Staukontrolle für
RTP-Datenströme an und dient zur Übertragung qualitätsbeschreibender Angaben über die
Güte des Transportkanals. Aus diesen Angaben kann zum Beispiel die durchschnittliche
Paketverlustrate und der durch den Übertragungsweg entstandene Jitter ermittelt werden.
Der Client kann mit Hilfe dieser Informationen entscheiden, ob ein neuer Transportweg
ermittelt werden muss bzw. ob die Datenanforderungen an eine neue Quelle mit besserer
Kanalgüte gerichtet werden sollten. In welcher Rate die Kontrollpakete zwischen Sender
und Empfänger ausgetauscht werden, ist von der Implementierung abhängig. In [1] wird
ein Vorschlag für die Anpassung der Rate an die Auslastung des Übertragungskanals
beschrieben.
6.3.4.1. Syntax
RTCP unterstützt für die Informationsübertragung fünf verschiedene Paketformate:
•
Senderreport-Paket (SR)
•
Empfängerreport-Paket (ER)
•
Quellenbeschreibungs-Paket (SDES)
•
Ende-Signalisierungs-Paket (BYE)
•
Paket für anwendungsspezifische Funktionen (APP)
Alle Pakettypen beginnen mit einem RTCP-Header (siehe Abb. 55), der dem RTP-PaketHeader sehr ähnlich ist.
Abb. 55) RTCP-Paket-Header (Referenz: [1])
Das Headerfeld RC gibt an, wie viele Report Blöcke dem Header folgen. Innerhalb der
Report Blöcke werden die RTCP-Informationen übertragen. Sie stellen also den Datenteil
95
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
des RTCP-Pakets dar. Der Payload-Type gibt an, um welchen Pakettyp es sich handelt
(SR, RR, SDES, BYE, APP).
Senderreport-Paket (SR)
Ein Sendereport-Paket wird durch den Payload-Type 200 identifiziert. Es kann benutzt
werden, um dem Empfänger die Zeitbasis für einen Datenstrom einer Multimediasequenz
mitzuteilen (NTP-TimeStamp). Mit dieser Zeitbasis ist es dem Empfänger möglich,
mehrere unabhängig erzeugte Datenströme untereinander zu synchronisieren. Der
Datenteil hat folgende Struktur:
Abb. 56) Payload des Sendereport-Pakets (Referenz: [1])
Empfangsreport-Paket (RR)
Das Empfangsreport-Paket wird vom Empfänger an den Sender übermittelt. Es liefert dem
Sender Informationen über die Güte des Datenempfangs bzw. über die
Verbindungseigenschaften (Jitter, Paketverluste). Das RR-Paket wird durch den PayloadType 201 signalisiert. Die folgende Abbildung stellt den Datenteil eines RR-Pakets dar:
Abb. 57) Payload eines RR-Pakets (Referenz: [1])
Weiter Informationen, speziell über die Pakettypen SDES, BYE, und APP können in [1]
nachgelesen werden.
96
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.3.4.2. Fazit
Das RTCP-Protokoll ist ein sehr einfaches Transportkontrollprotokoll. Es ist nur für den
Informationsaustausch der Kontrolldaten zwischen Sender und Empfänger zuständig. Die
Berechnung der Kontrollparameter, wie z.B. Paketverlustrate, Jitter und
Übertragungsverzögerung wird nicht durch das RTCP-Protokoll definiert, sondern bleibt
weiterhin von der Implementierung der Anwendungen der Kommunikationspartner
abhängig. Aufgrund der exklusiven Signalisierungsverbindung und der relativ kleinen
zusätzlichen Belastung des Übertragungskanals kann dieses Transportkontrollprotokoll
auch bei knapper Ressourcenverfügbarkeit eingesetzt werden.
97
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.4. Analyse einer Auswahl verfügbarer Encoder / Stream-Server
Aktuell sind drei Kategorien von Systemen für die Kodierung und Verteilung
multimedialer Inhalte unterscheidbar:
1. Kategorie: Stream-Server als Einzelsystem
2. Kategorie: Encoder als Einzelsystem
3. Kategorie: Gesamtsystem aus Encoder und Stream-Server
Die drei bekanntesten Anbieter von Stream-Server-Systemen sind Microsoft (Microsoft
Windows Media Server), Real (Real Networks Helix Server) und Apple (Darwin Server).
Mit DivX und XviD stehen zwei MPEG4-Video-Encoder zur Verfügung.
Die Produkte „MPEGable Broadcaster“, „MPEG4IP“ und „Fraunhofer IIS MPEG4Encoder/Stream-Server“ sind interessante Vertreter der dritten Kategorie.
Die genannten Systeme werden kurz vorgestellt und mit den Anforderungen für den
Einsatz im Multisource-Streaming-Ansatz verifiziert.
6.4.1. Microsoft Windows Media Server
Der Microsoft Windows Media Server wird mit den Serverbetriebssystemen von Microsoft
(WIN2000 Server, WIN2003 Server) kostenlos ausgeliefert.
Die Multimediadaten werden in einem speziellen Microsoft-ASF-Format übertragen.
Multimediale Daten, die verschiedene Formate besitzen können und mit untschiedlichen
Kodierverfahren komprimiert wurden, müssen zunächst in dieses Microsoft-Format
transformiert werden. Mit dem User Datagram Protocol werden die transformierten
Multimediadaten in Form von ASF-Paketen im Netzwerk verteilt.
Metainformationen über Multimediainhalte von Datenströmen sind in ASX-Files abgelegt.
Die visuellen Elemente sind häufig mit dem Kodierverfahren Windows Media Video
(WMV), die auditiven Daten mit dem Kodierverfahren Windows Media Audio (Video)
kodiert. Diese Codecs sind Eigenentwicklungen von Microsoft. Aufgrund der
Firmenphilosophie des Unternehmens sind interne Funktionalitäten dieser Kodierverfahren
nicht öffentlich erhältlich.
Der Windows Media Server kann in einem ASF-File multimediale Datenströme in
mehreren Bitraten anbieten. Die Übertragung von skalierbar kodierten
Multimediasequenzen ist jedoch nicht möglich.
Da der Media Server kein Open-Source-Projekt ist und somit der Quellcode nicht
verfügbar ist, können keine Anpassungen des Servers an den Multisource-StreamingAnsatz vorgenommen werden.
98
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Eine genaue Beschreibung des Microsoft Windows Media Servers ist in [19] und [20] zu
finden.
6.4.2. Real Networks Helix Server
Der Helix Server von Real Networks ist seit 2002 ein Open-Source-Projekt. Der Server ist
plattformunabhängig und kann mit mehr als 55 Multimediaformaten umgehen. Die
Multimediadaten werden in ein Real-eigenes Format transformiert, bevor sie vom Server
im Netzwerk verteilt werden. Auf der Empfängerseite muss somit ein Realplayer
existieren, der mit diesem Format umgehen kann.
Metainformationen für eine Multimediasequenz werden in einer exclusiven .ram-Datei
angegeben. Hier sind z.B. Angaben über die Lokalität und den Namen der
Multimediasequenz sowie das zu verwendende Steuerprotokoll für den Server (meistens
RTSP) enthalten. In dieser Datei können auch redundante, alternative Lokalitäten für einen
Multimediastrom angegeben werden.
Eine skalierbar kodierte Multimediasequenz ist auch mit dem Helix Server nicht
übertragbar. Der MPEG4-Standard wird vom Helix Server noch nicht unterstützt. Das
Vermitteln von MPEG4-kodierten Sequenzen soll jedoch in absehbarer Zeit implementiert
werden.
Den Ablauf eines Vermittlungsprozesses von multimedialen Daten mit dem Helix Server
erhält der Leser in [18].
6.4.3. Apple Darwin Server
Der Darwin Server ist das Open-Source-Derivat des Quicktime Servers der Firma Apple.
Er ist für die Betriebssysteme Mac OS X Server, Linux (Red Hat 8 oder höher), Solaris 9,
und Windows 2000/2003 Server verfügbar. Der Server erlaubt das Verteilen von
gespeicherten MPEG4-(Simple-Profile), Quicktime-, 3GGP- und MP3-kodierten
Multimediasequenzen. Die unterschiedlich kodierten Sequenzen werden durch ein Hinting
Tool in das Darwin Stream Format (mov) transformiert.
Das Hinting Tool beschreibt, wie ein Element einer kodierten Multimediasequenz in ein
Transportpaket mit definiertem Payload-Format verpackt werden muss. Es besteht also die
Möglichkeit Authoring-Tools zu verwenden, die nur das Format ihrer Mediadaten kennen
bzw. Server zu verwenden, die nur ihr Transportprotokoll und das passende hint-file
kennen. Das Hinting-Tool bildet somit die „Brücke“ zwischen diesen beiden
Komponenten. Häufige Anpassungen von Authoring-Tools an neue Protokolle oder
Anpassungen von Servern an neue Mediendatentypen sind nicht notwendig.
99
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die transformierten Multimediadaten werden paketiert in RTP-Strömen übertragen.
Metainformationen sind mit den Protokollen RTSP und SDP in der Anwendungsschicht
verteilbar.
Ein direktes Live-Streaming ist mit dem Darwin Server nicht möglich. Die Daten eines
verfügbaren Live-Streams werden an anfragende Netzwerkknoten „reflektiert“. Der LiveStream muss jedoch durch eine Quelle, bereits in RTP-Paketen paketiert, dem Server zur
Verfügung gestellt werden. Der Server leitet die RTP-Pakete der Quelle an die
anfragenden Netzwerkknoten weiter. Allgemeine Informationen über den Darwin Server
sind unter [21] verfügbar. Der Reflektionsprozess wird in [22] genau beschrieben.
Dokumentationen für den Source Code des Darwin Servers erhält der Leser in [23].
6.4.4. DivX
DivX ist eine Entwicklung der Firma DivXNetworks. Der MPEG4-Codec wurde als
Alternative zum „Microsoft MPEG4“-Codec WMV entwickelt.
Er unterstützt das Simple-Visual-Profile und das Advanced-Simple-Visual-Profile des
MPEG4-Standards Part 2. Dabei sind jeweils 5 Level auswählbar, mit denen MPEG4kodierte Sequenzen in einer Auflösung von 176x144 bis 1280x720 bei einer Bitrate von
200KBit/s bis 32MBit/s erzeugt werden können.
Die DivX-kodierten Daten werden zusammen mit den zugehörigen Audiodaten in einem
AVI-Containerformat gespeichert. Audiodaten und Videodaten sind somit nicht
unabhängig von einander verteilbar.
Weitere Informationen zu DivX findet der Leser in [24].
6.4.5. XviD
XviD ist ein Open-Source-Projekt für die Entwicklung eines ISO-MPEG4-konformen
Videocodecs.
Mit XviD können MPEG4-Videosequenzen im Simple-Visual-Profile und AdvancedSimple-Visual-Profile aller Level kodiert werden. Das Verfahren unterstützt die Kodierung
visueller Daten mit einer Auflösung von 176x144 Pixel bis 720x576 Pixel mit einer Bitrate
von 16KBit/s bis 48,6MBit/s.
Auf welche Art die kodierten Daten gespeichert oder verteilt werden ist abhängig von der
Anwendung und wird von XviD nicht vorgegeben.
XviD arbeitet auf Windows-, Linux-, MacOSX-, BSD-, Solaris- und BeOS-Plattformen.
Erweiterte Informationen über das Open-Source-Projekt, Funktionsdetails und Foren
werden in [25] angeboten. Spezielle Anweisungen für den Einsatz von XviD mit den
Microsoft Betriebssystemen findet der Leser unter [26].
100
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.4.6. Fraunhofer IIS MPEG4 Encoder / Stream-Server
Der Fraunhofer IIS MPEG4-Encoder / Stream-Server ist ein kommerzielles Produkt des
„Fraunhofer Instituts für Integrierte Schaltungen“. Es ist ein Gesamtsystem für die
Kodierung und das Verteilen multimedialer Inhalte. Die Kodierung von visuellen
Datenelementen erfolgt konform zum MPEG4-Standard Part 10 (Advanced Video
Coding). Auditive Sequenzen werden gemäß dem MPEG4-Standard Part 3 (High
Efficiency Advanced Audio Coding) kodiert.
Die visuellen Daten können entsprechend dem Simple-Visual-Profile, dem AdvancedSimple-Visual-Profile, dem Core-Profile oder dem Advanced-Coding-Efficiency-Profile
in jeweils allen Leveln kodiert werden. Somit werden durch diesen Encoder VideoAuflösungen von 176x144 Pixel bis 1920x1088 Pixel bei Bitraten zwischen 64KBit/s und
38,4MBit/s unterstützt.
Audio- und Videodatenströme können als Elementarströme unabhängig voneinander im
Netzwerk verteilt werden. Die multimedialen Elemente werden entsprechend der „ISMASpecification“ paketiert und transportiert. Metainformation für eine MPEG4-Sequenz
werden auf der Anwendungsebene mit Hilfe der Protokolle RTSP und SDP bereitgestellt.
Die Software ist als Objekt-Code (linkable Libraries) für die Betriebssysteme Windows,
Linux und PocketPC verfügbar und für x86-Plattformen optimiert (SSE, SSE2, MMX).
Den Quellcode erhält man nach Bestätigung der Lizensbedingungen des Fraunhofer
Instituts.
Informationen, Kontakte und weitere Beschreibungen für dieses Produkt werden unter [28]
angeboten.
6.4.7. MPEGable Broadcaster
MPEGable Broadcaster ist ein interessantes, kommerzielles Produkt der Firma „dicas
digital image coding GmbH“ aus Berlin. Es wurde grundsätzlich für die Verteilung,
Kodierung und Speicherung multimedialer Inhalte, konform zum MPEG4-Standard und
zur „ISMA-Specification“ 1.1 entwickelt.
MPEGable Broadcaster unterstützt folgende Funktionen:
•
Echtzeit-MPEG4-Kodierung visueller Inhalte im Simple-Profile und AdvancedSimple-Profile (alle Level)
•
Echtzeit-MPEG4-AAC-LC-Kodierung auditiver Inhalte
•
RTP-Multicast-Streaming (“ISMA-Specification” 1.1) - Verteilen von
Elementarströmen
•
Steuerprotokoll/Beschreibungsprotokoll RTSP/SDP
101
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
•
Vorverarbeitung (Cropping, Resizing, Deinterlacing, RGB-, Helligkeits- und
Kontrastanpassung) der multimedialen Daten
•
Verteilung und Speicherung MPEG4 kodierter Sequenzen aus verschiedenen
Quellen (siehe Abb. 58)
Abb. 58) MPEGable Broadcaster (Referenz: [27])
Technische Vorraussetzungen für den Einsatz von MPEGable Broadcaster sind:
•
Prozessor: Pentium III, Athlon Prozessor oder besser
•
Bertriebssystem: Windows 98, ME, NT 4.0, 2000 oder XP
Der Quellcode für MPEGable Broadcaster wird von dem Unternehmen nicht zur
Verfügung gestellt. Angaben über technische Details der internen Funktionen des
Programms sind nicht verfügbar. MPEGable Broadcaster kann man für ca. 300 Euro
erwerben. Für Kontaktinformationen und detailiertere Beschreibungen des Produkts wird
auf [27] verwiesen.
6.4.8. MPEG4IP-MP4Live
MPEG4IP ist ein Open-Source-Projekt der Firma „Cisco Systems“. MPEG4IP ist ein
Gesamtsystem zum Kodieren, Streamen und Dekodieren von multimedialen Inhalten. Das
Projekt ist nicht für den Gebrauch im Endbenutzerbereich gedacht, sondern vielmehr für
Entwickler, die am Streaming standardisiert kodierter audiovisueller Daten interessiert
sind. Die hauptsächlichen Funktionalitäten von MPEG4IP werden von den
Softwarepaketen MP4Live und MP4Player geliefert.
MP4Live kodiert in Echtzeit Live-Streams und erlaubt es, die kodierten Daten über eine
Ende-zu-Ende-Verbindung in einem Netzwerk zu vermitteln, und (oder) die kodierten
Daten in einem MP4-Container-File abzulegen. MP4Live unterstützt verschiedene
standardisierte Kodierverfahren. Die wichtigsten Verfahren sind MPEG1, H.261, MPEG2,
MPEG4 (XviD), MP3 und MPEG4-AAC. Für den Streamprozess werden die kodierten
Daten entweder entsprechend dem MPEG2-System-Standard (MPEG2-Transportstrom)
oder gemäß dem MPEG4-System-Standard (OD-Framework, Elementarstrom) in Access
Units paketiert und mit Synchronisationsinformationen versehen. Der Transport der Access
102
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Units erfolgt konform zur „ISMA-Specification“ 1.1. Das Format der
Transportdateneinheiten wird durch das Realtime Transmission Protocol, mit den
vorgeschlagenenen Payload-Formaten der RFC3016(MPEG4-Video, siehe [11]),
RFC3640(MPEG4-AAC, siehe [10]), RFC2250(MPEG2-Video, siehe [8]) und
RFC3119(MP3, siehe [9]) bestimmt.
Metadaten werden in einer Konfigurationsdatei abgelegt und über die Protokolle RTSP
und SDP übermittelt. RTSP ist für die Übermittlung der Konfigurationsinformationen bei
MPEG4IP nicht zwingend erforderlich, sondern kann optional genutzt werden. Wenn
RTSP nicht benutzt werden soll, muss ein anderer Mechanismus für den Transport der
Konfigurationsinformationen an den dekodierenden Netzwerkknoten existieren.
In definierten Zeitabständen werden RTCP-Senderreport-Pakete vom MP4Live-Server
erzeugt und an den MP4Player übertragen. Die Senderreport-Pakete enthalten einen NTPZeitstempel mit der lokalen Systemzeit des Encoders. Der MP4Player nutzt diese
Zeitstempel, um die Zeitbasis des Encoders zu rekonstruieren. Diese Zeitbasis wird im
Wiedergabeprozess für die Ermittlung der korrekten Präsentationszeit der multimedialen
Dateneinheiten der Elementarströme benötigt.
Weitere Funktionalitäten von MPEG4IP und nähere Informationen über das Projekt sind
unter [29] zu finden.
6.4.9. Fazit
Aktuell existierende MPEG4-Encoder und Stream-Server unterstützen kein Profil des
MPEG4-Standards, dass eine skalierbare Kodierung multimedialer Daten erlaubt. Die
Realisierung des spezifizierten Multisource-Streaming-Ansatzes ist somit nicht vollständig
möglich. Die analysierte Heterogenität der Endgeräte kann in einer derzeitigen
Implementierung nicht berücksichtig werden. Jedoch sind einige Encoder in der Lage,
unabhängig verteilbare Audio- und Videoelementarströme gemäß dem MPEG4-Standard
Part 1 zu erzeugen. Somit kann ein veränderter Multisource-Streaming-Ansatz
implementiert werden, der die Möglichkeit der unabhängigen Verteilbarkeit von Audiound Videoelementarströmen ausnutzt. Die Implementierung weicht deshalb von der
Spezifikation ab. Es können keine skalierbar kodierten Datenströme verteilt werden,
jedoch Elementarströme des MPEG4-Standards Part 1.
Es werden ein Encoder und ein Stream-Server benötigt, die unabhängig verteilbare
Elementarströme gemäß dem MPEG4-Standard Part 1 erzeugen und verteilen können.
Das Open-Source-Projekt MPEG4IP bietet sich als Encoder und Stream-Server für die
Implementierung des abgeänderten Multisource-Streaming-Ansatzes an.
Durch folgende positive Eigenschaften konnte sich MPEG4IP von den anderen
analysierten Kodier- und Stream-Systemen abheben. Diese Eigenschaften haben zur
103
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Auswahl von MPEG4IP als Kodier- und Stream- System für die Implementierung des
Multisource-Streaming-Ansatzes geführt:
•
der Sourcecode ist frei verfügbar und kostenlos
•
das Projekt ist sehr aktuell und wird kontinuierlich weiterentwickelt
•
das Projekt ist bereits sehr bekannt und die Entwicklungsergebnisse werden schon
weit verbreitet eingesetzt
•
es nutzt nur standardisierte, populäre Kodierverfahren
•
durch seine PlugIn-Architektur ist MPEG4IP sehr leicht mit neuen
Kodierverfahren erweiterbar
•
es transportiert die multimedialen Dateneinheiten und Metainformationen gemäß
der ISMA-Specification 1.1 und ist damit kompatibel zu vielen Stream-Servern
und Wiedergabeeinheiten
•
es ist ein Gesamtsystem zum Kodieren, Streamen, Speichern und Dekodieren
multimedialer Inhalte
•
es erzeugt unabhängig verteilbare, synchronisierbare Elementarströme
•
es nutzt die positiven Eigenschaften von MPEG4 für die Fehlerverschleierung und
Fehlerkorrektur
•
es bietet eine einfache Schnittstelle an, um die multimedialen Daten und
Metainformationen für die eigene Implementierung nutzen zu können
•
es unterstützt die wichtigsten Betriebssysteme (MS Windows, Linux)
MPEG4IP hat aber auch Eigenschaften, die sich nachteilig auf die Implementierung
auswirken können.
•
es ist ein sehr junges Projekt und enthält damit noch einige Programmierfehler
•
der Stream-Server unterstützt nur eine Clientverbindung
Diese Schwächen lassen sich
Entwicklungszeit beseitigen.
jedoch
mit
vertretbarem
Aufwand
und
etwas
104
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.5. Analyse einer Auswahl verfügbarer Decoder / Wiedergabeeinheiten
Die Wahl eines geeigneten Decoders bzw. einer geeigneten Wiedergabeeinheit für die
Implementierung der Verteilerquellen des Multisource-Streaming-Ansatzes, ist direkt von
dem serverseitig eingesetzten Kodier- und Stream-System MPEG4IP abhängig.
Der Decoder der Verteilerquelle muss in der Lage sein, MPEG4-System-Datenströme,
MPEG4-Video(XviD) und MPEG4-Audio (AAC) dekodieren zu können. Zusätzlich
müssen der Wiedergabeeinheit die Payload-Formate der eintreffenden RTP-Datenströme
bekannt sein, damit die Daten korrekt aus dem Transportdatenstrom in einen MPEG4System-Datenstrom transformiert werden können. Die Wiedergabeeinheit muss den
Anforderungen der ISMA-Specification 1.1 genügen.
Die notwendigen Metainformationen für die Initialisierung der Decoderparameter muss die
Wiedergabeeinheit aus der MPEG4IP-Konfigurationsdatei auslesen können. Somit ist es
wichtig, dass die Wiedergabeeinheit Implementierungen der Steuer- und
Beschreibungsprotokolle RTSP und SDP besitzt.
Es gibt verschiedene Decoder / Wiedergabeeinheiten, die diesen Anforderungen gerecht
werden und somit in den Verteilerquellen, abhängig vom Betriebssystem, eingesetzt
werden können.
Für MS Windows XP ist der WMP4Player des MPEG4IP Projektes oder der Quicktime
Player von Apple geeignet. In einer Verteilerquelle mit Linux Betriebssystem kann der
Mplayer oder der GMP4Player des MPEG4IP Projektes eingesetzt werden.
105
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.6. Plattform für die Implementierung des Multisource-StreamingAnsatzes
Nachdem die serverseitigen und clientseitigen Komponenten für eine Implementierung des
Multisource-Streaming-Ansatzes ausgewählt wurden, kann eine Übersicht über die
grundlegende Plattform des zu implementierenden Systems gegeben werden.
6.6.1. Netzwerkstruktur
Die Infrastruktur des Verteilernetzwerkes wird durch ein WLAN-Adhoc-Netzwerk nach
dem Standard 802.11b bestimmt. Mehrere Netzwerkknoten sind in diesem Netzwerk
drahtlos, dynamisch, teilvermascht miteinander verbunden. Jedem Netzwerkknoten sind
seine aktuellen Nachbarn direkt bekannt. Die Adressen der Nachbarn werden von jedem
Knoten in einer Addressenliste verwaltet, die als Datei im Textformat lokal angelegt wird.
6.6.2. Netzwerkknoten
Die Netzwerkknoten werden, wie im Entwurf gefordert (siehe 4.2), in Hauptquelle und
Verteilerquelle unterschieden.
Die Hauptquelle des Systems besteht aus folgenden Hardware- und Softwarekomponenten:
Hardwareübersicht:
•
Kamera:
Canon Digital Video Camcorder PAL MVX100
•
Mikrofon:
in der Kamera enthalten
•
Capturekarte:
Haupauge WINTV Primio FM (Chipsatz: BT878)
•
Prozessor:
AMD Athlon 1GHz
•
Hauptspeicher:
256 MB SDRAM
•
Grafikkarte:
ATI Xpert 2000 Pro 64MB SDRAM
•
Netzwerkkarte:
LAN-Karte Realtek RTL8139-PCI-Fast Ethernet
Softwareübersicht:
•
Betriebssystem:
Linux Debian (Kernel 2.6.8.1)
•
Encoder video:
(VBR)
MPEG4IP XVID1.0 / MPEG4 - System / 25fps / 500kbps
•
Encoder audio:
MPEG4IP AAC / MPEG4 - System / 128kbps (CBR)
•
Stream-Server:
MPEG4IP-MP4LIVE
106
Diplomarbeit
•
Verteiler Server:
Inv.Nr.: 2004-11-03/096/IN99/2253
MultiSourceHq (eigene Implementierung)
Die Funktionalität der Hauptquelle kann folgendermaßen kurz beschrieben werden:
Eine digitale Kamera liefert einen Composit-Datenstrom und einen PCM-Datenstrom an
das Capture-Device der Hauptquelle. Der Composit-Datenstrom wird von dem CaptureDevice in einen YUV-Datenstrom transformiert. Der YUV-Datenstrom und der PCMDatenstrom werden vom Capture-Device an den MP4Live-Encoder weitergeleitet. Der
Encoder erzeugt ein MPEG4-Objekt mit zwei unabhängig verteilbaren MPEG4-SystemElementarströmen - einen XVID-kodierten Video-Elementarstrom und einen AACkodierten Audio-Elementarstrom. Der Video-Elementarstrom wird mit einer variablen
durchschnittlichen Bitrate von 500KBit/s und einer Framerate von 25 Frames/s kodiert.
Der kodierte Audio-Elementarstrom besitzt eine konstante Bitrate von 128KBit/s.
Wie bereits erwähnt, kann der MP4Live-Stream-Server die Elementarströme und die
Konfigurationsinformationen immer nur einem Netzwerkknoten anbieten. Um mehreren
Nutzern gleichzeitig den Zugriff auf den Live-Stream zu ermöglichen, ist ein zusätzlicher
Verteilerserver notwendig, der dem MP4Live-Stream-Server nachgeschaltet werden muss.
Der Darwin Server ist in der Lage diese Aufgabe zu übernehmen. Jedoch bietet er zu viele
Funktionalitäten an, die für diese Implementierung nicht benötigt werden. Entsprechend
groß sind deshalb auch die Hard- und die Softwareanforderungen des Darwin Servers an
einen Netzwerkknoten. Für die Aufgabe der Verteilung der Elementarströme ist es deshalb
besser, eine eigene, ressourcenschonendere Lösung zu entwickeln, die gleichzeitig in der
Hauptquelle und in den Verteilerquellen eingesetzt werden kann. Die eigene
Implementierung eines Verteilerservers wird „MultisourceHq“ (Hq=Hauptquelle) genannt.
Der MP4Live-Stream-Server übergibt die kodierten Daten der Elementarströme, paketiert
als RTP-Transportströme zum MultisourceHq-Verteilerserver. Der Verteilerserver bietet
die Transportdatenströme als Service im Adhoc-Netzwerk an. Der MultisourceHQVerteilerserver tritt gegenüber dem MP4Live Stream-Server als Client und den
Verteilerquellen des Netzwerks gegenüber als Server auf. Die nachfolgende Abbildung
stellt den Prozess grafisch dar:
Abb. 59) Architektur der implementierten Hauptquelle
107
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Verteilerquellen sind mobile Rechner
Hardwarekomponenten und Betriebssystemen.
(Laptop)
mit
unterschiedlichen
Hardwareübersicht:
•
Prozessor: Intel/AMD , Taktrate > 1GHz
•
Hauptspeicher: SDRAM > 256MB
•
Netzwerk-Karte (PCMCIA):
•
WLAN D-Link DWL 650G+ (802.11g)
•
WLAN RoamAbout (802.11b)
Softwareübersicht:
•
Betriebssystem:
•
Suse Linux 9.0 (Linux Kernel 2.4.x)
•
Suse Linux 9.1 (Linux Kernel 2.6.4)
•
Debian (Linux Kernel 2.6.8)
•
Windows XP
•
Decoder/Wiedergabeeinheit:
•
MPlayer (Linux)
•
QuickTime Player (Windows)
•
MPEG4IP MP4Player (Linux, Windows)
•
Stream-Client: Multisource
•
Verteiler Server: Multisource
Je nach Betriebssystem des Netzwerkknotens wird der MPLayer, der QuickTime-Player
oder der MP4Player als Wiedergabeeinheit und Decoder verwendet. Der
Kommunikationsprozess zwischen einer Verteilerquelle und der Hauptquelle bzw.
zwischen den Verteilerquellen untereinander, wird durch eine eigene Implementierung
realisiert. Sie enthält zusätzlich die Funktionen für die Annahme und die Verteilung der
Transportdateneinheiten und der Konfigurationsinformationen. Diese Implementierung
wird mit „Multisource“ bezeichnet. Mit der Abb. 60) wird die Architektur der
Implementierung einer Verteilerquelle grafisch dargestellt.
108
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 60) Architektur der implementierten Verteilerquelle
6.6.3. Protokolle
Mit der Wahl des Encoders stehen gleichzeitig die zu verwendenden Protokolle der
Anwendungsschicht und der Transportschicht fest.
MP4Live verwendet in der Anwendungsschicht für die Kodierung der Metainformationen,
wie z.B. Objekt-Deskriptoren, BIFS-Deskriptoren oder netzwerk- und encoderspezifische
Informationen das Stream Description Protocol (SDP). Diese Informationen werden in
einer Konfigurationsdatei im SDP-Format abgelegt, das dem Decoder für die
Initialisierung zugänglich gemacht werden muss. Aufgrund der Wichtigkeit dieser
Konfigurationsdaten, werden sie mit TCP zu den Netzwerkknoten der Dienstnutzer
transportiert.
Die visuellen und die auditiven Daten werden vom MP4Live-Stream-Server jeweils als
unabhängiger RTP-Datenstrom bereitgestellt. Für die Übermittlung dieser zeitkritischen
Daten wird UDP als geeignetes Transportprotokoll eingesetzt. Die Paketierung der
multimedialen Daten erfolgt gemäß der „ISMA-Specification“ 1.1.
109
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
6.6.4. Entwicklungsumgebung
Da in der Verteilerquelle und in der Hauptquelle unterschiedliche Betriebssysteme genutzt
werden, ist eine plattformunabhängige, höhere Programmiersprache für die Entwicklung
erforderlich. Zudem soll die Implementierung objektorientiert erfolgen, um spätere
Erweiterungen und Veränderungen des Systems leicht zu ermöglichen. Deshalb wurde
entschieden, für die Implementierung eine Java-Entwicklungsumgebung zu verwenden.
Die Entwicklungsumgebung Eclipse 3.0 erwies sich als sehr effizient und funktionell. Sie
bietet neben den grundlegenden programmiertechnischen Funktionen eine sehr gute
Online-Hilfe, ein übersichtliches Debug-System und sogar ein UML-PlugIn für ein
Softwaredesign an. Eclipse 3.0 kann mit allen Java-SDKs von Sun Microsystems
eingesetzt werden. Für diese Implementierung wird Java 1.4.2_05 verwendet.
110
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7. Implementierung
Dieses Kapitel beschreibt detailliert die Implementierung des spezifizierten Systems.
Grundsätzlich werden die Funktionen der entwickelten Klassen dokumentiert. Die
Beschreibung der Algorithmen erfolgt nicht vollständig, sondern es werden nur die
zentralen Stellen erläutert. Die Schilderung des Funktionsablaufs soll mit Zitaten aus dem
Programmcode und Skizzen verständlicher dargelegt werden.
Die Implementierung des neuen Multisource-Streaming-Ansatzes gliedert sich in drei
Funktionsgruppen: Hauptquelle, Verteilerquelle und Kernsystem. Die Gruppen sind durch
Kommunikationsbeziehungen mit einander verknüpft und sie stellen gruppeninterne
Funktionen untereinander bereit. Die nächsten Abschnitte des Kapitels beschreiben
ausführlich die Eigenschaften und die Aufgaben dieser Funktionsgruppen.
7.1. Hauptquelle
Im Abschnitt 6.6 wurde die grundlegende Plattform der spezifizierten Hauptquelle
beschrieben. Die Funktionen für die Erstellung und die Kodierung der multimedialen
Daten konnten durch frei verfügbare, ausgewählte Komponenten in die Hauptquelle
integriert werden. Die noch fehlenden funktionalen Elemente für die Bereitstellung und die
Verteilung der multimedialen Daten im hochdynamischen Netzwerk, wird durch die in
diesem Abschnitt beschriebene Implementierung eines Verteilerservers integriert. Die
Implementierung dieses Servers besteht aus den Klassen „MultisourceHq“,
„ServerHauptquelle“ und „ClientHauptquelle“. Die Funktionen dieser Klassen werden in
den folgenden Abschnitten dokumentiert.
7.1.1. MultisourceHq
Die Klasse MultisourceHq definiert das funktionale Gerüst des Verteilerservers der
Hauptquelle. Sie enthält die Mainmethode, die die Initialisierung und den Start der
MultisourceHq-Komponenten ServerHauptquelle, ClientHauptquelle und BufferManager
festlegt. Der Verteilerserver besteht aus einer Client- und einer Serverkomponente. Die
Clientkomponente (ClientHauptquelle) sorgt für die Datenverbindung zum MP4LiveStream-Server. Sie nimmt die MPEG4-kodierten multimedialen Elemente von dem
Stream-Server entgegen. Die Serverkomponente (ServerHauptquelle) des Verteilerservers
stellt die MPEG4-Sequenz als Service im Netzwerk bereit. Der Datenfluss der zu
vermittelnden Elementarströme im Verteilerserver ist in Abb. 61) dargestellt.
111
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 61) Grundgerüst der Implementierung des Verteilerservers „MultisourceHq“
In der Initialisierungsphase werden die Komponenten des Verteilerservers für die
Bereitstellung und die Verteilung multimedialer Daten vorbereitet. Zunächst wird eine
Instanz der Klasse „BufferManager“ erzeugt. Durch Referenzen auf diese Instanz können
die Client- und die Serverkomponente mit dem zentralen Puffermanager kommunizieren
(siehe Abb. 61). Danach wird der global gültige Parameterwert für das Homeverzeichnis
des Verteilerservers gesetzt. Im Homeverzeichnis ist die Konfigurationsdatei der kodierten
MPEG4-Sequenz von MP4Live abgelegt. Diese Konfigurationsdatei wird durch die
Methode parseSDPFile () einmalig ausgelesen, um die Eigenschaften und die Lokalität der
Elementarströme, die vom Stream-Server angeboten werden, zu ermitteln. Der
Puffermanager unterhält eine Wissensbasis, die alle notwendigen Informationen über
verfügbare Elementarströme zusammenfasst. Für jeden vom Stream-Server bereitgestellten
Elementarstrom wird ein Serviceeintrag in dieser Wissensbasis generiert. Ein
Serviceeintrag enthält elementarstromspezifische Informationen, die aus der
Konfigurationsdatei ausgelesen wurden. Solche Informationen sind z.B. der Name der
Multimediasequenz (Servicename), die Elementarstrom-ID und die durchschnittliche
Datenrate, mit der der Elementarstrom kodiert wurde. Die Kombination aus dem Namen
der Multimediasequenz und der Elementarstrom-ID kennzeichnet einen Elementarstrom
eindeutig.
Der Puffermanager richtet jeweils ein Pufferfeldelement für die zu erwartenden Daten
eines Elementarstroms und ein Pufferfeldelement für Signalisierungsdaten des zugehörigen
112
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Transportkontrollprotokollkanals ein. Die Nummern der Pufferfeldelemente werden
ebenfalls als elementarstromspezifische Informationen in die Wissensbasis eingetragen So
ist eine eindeutige Zuordnung zwischen dem Schlüssel, Servicename/Elementarstrom-ID
und der Pufferfeldelementnummer gegeben.
Nach dieser Initialisierungsphase ist der Verteilerserver bereit, die verfügbaren MPEG4Sequenzen im hochdynamischen Netzwerk anzubieten.
Der Nutzer kann mit dem Konsolenkommando „close“ den MultisourceHq-Verteilerserver
beenden. Nach dem close-Kommando wird das Pufferfeld geleert und es werden alle
Einträge aus der Serviceinformationstabelle entfernt.
7.1.2. ClientHauptquelle
Die Klasse „ClientHauptquelle“ implementiert die Funktionalität der Clientkomponente
des Verteilerservers. Die Aufgabe der Klasse besteht darin, die Daten der Elementarströme
und die zugehörigen Transportkontrollinformationen vom Stream-Server (MP4Live)
entgegenzunehmen und in den definierten Pufferfeldelementen abzulegen. Die
Elementarströme werden vom Stream-Server lokal auf fest definierten Ports bereitgestellt.
Die Portnummer für den ersten Elementarstrom beginnt bei 20000. Für jeden weiteren
Elementarstrom erhöht sich die Portnummer um zwei. Die Portnummer muss gemäß der
„ISMA-Specification“ geradzahlig sein, da sich für jeden Elementarstrom auf der nächsten,
folgenden ungeradzahligen Portnummer der zugehörige Signalisierungskanal des
Transportkontrollprotokolls befindet.
Der Client ermittelt aus der Wissensbasis des Puffermanagers alle Elementarströme, die
vom Stream-Server angeboten werden. Der Zugriff auf diese Tabelle erfolgt über die
Referenz des BufferManager-Objekts, das in der MultisourceHq-Klasse generiert wurde.
Für jeden Elementarstrom startet der Client zwei Empfänger-Threads. Einer der Threads
sorgt für den kontinuierlichen Datenempfang und die kontinuierliche Pufferung der
empfangenen Transportdateneinheiten des Elementarstroms im entsprechenden
Pufferfeldelement. Der zweite Thread ist für den Empfang und die Pufferung von
Transportkontrollinformationen (RTCP-Senderreport-Pakete) verantwortlich, die durch
den MP4Live-Stream-Server erzeugt und versendet wurden. Die Threads sind Instanzen
der Klasse „StreamRequest“. Diese Klasse ist eine Komponente des Kernsystems. Sie
enthält alle Funktionen für die Realisierung des kontinuierlichen Datenempfangs. Von
jedem Thread wird eine Referenz gebildet, die in eine global gültige Threadliste
eingetragen wird. Mit dieser Threadliste können alle erzeugten Threads verwaltet werden.
Die Funktionalität der Threadliste wird durch die statische Klasse „ThreadList“
bereitgestellt.
113
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7.1.3. ServerHauptquelle
Die Klasse „ServerHauptquelle“ enthält alle funktionalen Elemente der Serverkomponente
des Verteilerservers. Sie hat die Aufgabe, die gepufferten Elementarströme den
benachbarten Netzwerkknoten zur Verfügung zu stellen. Zudem enthält die Klasse die
Algorithmen, die die externen Kommunikationsprozesse zu Netzwerkknoten im
hochdynamischen Netzwerk definieren.
Für die Kommunikation ist ein exklusiver Signalisierungskanal vorgesehen. Die
Signalisierungsinformationen sind nicht zeitkritisch aber empfindlich bei
Übertragungsfehlern. Deshalb werden sie mit dem sicheren Transport Control Protocol
übertragen. Der Signalisierungskanal wird serverseitig durch ein Serversocket mit dem
definierten TCP-Port 5566 initialisiert. Dort erwartet der Server asynchron eintreffende
Clientanfragen. Damit das kontinuierliche Abhören des Serversockets nicht den
Programmablauf blockiert, ist jede Instanz der Klasse „ServerHauptquelle“ ein Thread.
Nach dem erfolgreichen Verbindungsprozess zwischen dem Client und dem Server, wird
eine neue Instanz der internen Klasse „ClientThread“ erzeugt (siehe Abb. 62). Dem
Konstruktor der Klasse wird ein neues Clientsocket übergeben. Die Klasse „ClientThread“
enthält die gesamte Funktionalität für die Signalisierung zwischen dem Server und einem
Client.
Abb. 62) Initialisierung von Threads für jede eintreffende Clientanfrage
Zunächst erwartet das „ClientThread“-Objekt vom Client einen „Service-Request“. Mit
dieser Anfrage überprüft der Client die Verfügbarkeit einer Multimediasequenz mit
bestimmtem Namen (Servicename). Der angefragte Servicename wird vom Server an das
„BufferManager“-Objekt weitergeleitet. Der Puffermanager durchsucht die Wissensbasis
nach dem Servicenamen. Existieren lokal gepufferte Daten eines oder mehrerer
Elementarströme für eine Multimediasequenz mit diesem Namen, dann liefert der
Puffermanager eine Liste mit allen Informationen über die verfügbaren
Elementarstromteile an den Server zurück. Solange diese Liste nicht leer ist, entnimmt der
114
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Server die Informationen über einen Elementarstrom aus der Liste und übermittelt sie an
den Client. In den Angaben sind die Elementarstrom-ID, der Medientyp, die
durchschnittliche Datenrate des Elementarstroms sowie die Sequenznummer und der
Zeitstempel der ersten und der letzten gepufferten Dateneinheit enthalten. Das Ende der
Informationsübertragung wird dem Client durch die Zeichenfolge „NoData“ signalisiert.
Besitzt die Hauptquelle keine Elementarstromteile der gewünschten Multimediasequenz,
dann sendet der Server sofort die Zeichenfolge „NoData“ an den Client. Der
Kommunikationsprozess ist in der folgenden Abbildung grafisch dargestellt.
Abb. 63) Zeitablaufdiagramm für einen Service-Request
Nach diesem Informationsaustausch ermittelt der Client die Linkgüte der Verbindung zum
Server (siehe Abb. 64). Der Server erhält für die Initialisierung dieses Prozesses einen
„Ping-Request“ über den Signalisierungskanal vom Client. Auf diese Anfrage antwortet
der Server mit seiner aktuell verfügbaren Uplink-Kapazität. Der Wert der Kapazität wird
vom Linkmanager des Servers verwaltet und geliefert. Die Funktionalität des
Linkmanagers definiert die Klasse „LinkmanagerServer“, die ein Teil des Kernsystems ist.
Nach der Übermittlung der verfügbaren Uplink-Kapazität erzeugt der Server, mit der
Methode Ping() der internen Klasse ClientThread, ein UDP-Socket mit der festgelegten
Portnummer 5556. Dort erwartet der Server zehn aufeinander folgende UDP-Pakete vom
Client. Die UDP-Pakete enthalten den Zeitwert des Zeitpunktes, an dem sie vom Client
erzeugt und an den Server übertragen wurden. Der Server sendet die UDP-Pakete direkt
nach dem Empfang an den Client zurück. Der Client kann mit Hilfe der Pakete, die er
wieder zurückbekommen hat, einfach die durchschnittliche Umlaufzeit (RTT) und die
Anzahl der Paketverluste für die Verbindung zum Server ermitteln.
115
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 64) Kommunikationsprozess zur Abschätzung der Verbindungsqualität
Warum wird UDP für die Abschätzung der Linkgüte verwendet? Das „User Datagram
Protocol“ garantiert die erfolgreiche, fehlerfreie Übertragung von Paketen nicht. Nur so
kann man gut ermitteln, wie stark die Fehler- und Verlusthäufigkeit der Verbindung
zwischen Client und Server ist.
Sollte der Server vom Client als Kandidat für die Übermittlung der
Konfigurationsinformationen einer Multimediasequenz ausgewählt werden, dann erhält er
über den Signalisierungskanal einen „Describe Request“. Diese Anfrage enthält den
Namen der Multimediasequenz, für die die Konfigurationsinformationen angefordert
wurden.
Die Konfigurationsinformationen für jede der in der Hauptquelle verfügbaren
Multimediasequenzen sind jeweils in einer Datei im Homeverzeichnis des Servers
abgelegt. Der Bezeichner der Datei ist identisch mit dem Namen der korrespondierenden
Multimediasequenz. Die Dateiendung „sdp“ verweist auf das SDP-Format, der
Informationen, die in der Datei enthalten sind. Ein Beispiel für SDP-formatierte
Konfigurationsinformationen ist im Anhang F gegeben.
Der Server durchsucht das Homeverzeichnis nach einer Konfigurationsdatei mit dem
Namen der gewünschten Multimediasequenz. Existiert diese Datei und sie ist vom Server
lesbar, dann bestätigt der Server die Verfügbarkeit der Konfigurationsinformationen durch
die Zeichenfolge „OK\n“. Sollte die geforderte Datei nicht verfügbar sein, dann wird die
Zeichenfolge „NEG\n“ vom Server an den Client gesendet.
116
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Nach einem positiven Ergebnis dieser Überprüfung, fordert
Konfigurationsinformationen beim Server an (siehe Abb. 65).
der
Client
die
Die Anforderung erfolgt mit einem „SDP-Request“. Der Server öffnet die
Konfigurationsdatei,
liest
sie
zeilenweise
aus
und
übermittelt
die
Konfigurationsinformationen ebenfalls zeilenweise, als String an den Client. Das Ende der
Informationsübertragung wird dem Client durch den String "END OF FILE\n" mitgeteilt.
Abb. 65) Anforderung der Konfigurationsinformationen
Der Client benötigt zu den Datenelementen der gewünschten Elementarströme zusätzliche
Transportkontrollprotokollinformationen, in Form von RTCP-Senderreport-Paketen. Jedes
RTCP-Senderreport-Paket enthält einen Zeitstempel des MP4Live-Stream-Servers. Mit
einer Folge dieser Zeitstempel kann der Client die Zeitbasis für die relativen
Zeitinformationen der kodierten Datenelemente der Elementarströme rekonstruieren.
Wenn der Server ausgewählt wurde, um gepufferte Daten eines Elementarstroms zu
vermitteln, dann erhält er über den Signalisierungskanal einen „Stream Request“ (siehe
Abb. 66). In dieser Anforderung ist der Servicename, die Elementarstrom-ID, der
gewünschte Startzeitpunkt für den Elementarstrom und die Portnummer des UDP-Sockets,
auf dem die Daten erwartet werden, enthalten. Der Server öffnet nach dem erhaltenen
„Stream Request“ zwei neue UDP-Sockets. Das erste UDP-Socket dient zur Übertragung
der gepufferten Datenelemente des gewünschten Elementarstroms. Das zweite UDPVerfasser: Holger Kärst
117
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Socket ist für den Transfer der gespeicherten Transportkontrollprotokollinformationen
(RTCP-Sendereportpakete) erforderlich.
Nun wird für jeden angeforderten Elementarstrom eine Instanz der Klasse „Streaming“
erzeugt. Diese Klasse enthält alle Funktionen, um eine zeitkorrekte Vermittlung der
gepufferten Datenelemente und Transportkontrollprotokollinformationen zu gewährleisten.
Abb. 66) Anforderung der Elementarströme
7.2. Verteilerquelle
Die Realisierung der Funktionen der Verteilerquelle für den Datenempfang und die
Datenverteilung erfolgte vollständig durch Neuentwicklungen. Die Verteilerquelle
definiert die Grundlage des neuen Multisource-Streaming-Ansatzes. Für den
Wiedergabeprozess wurde eine ausgewählte, verfügbare Wiedergabeeinheit, mit dem darin
enthaltenen MPEG4-Decoder, als eine eigenständige Komponente in die Verteilerquelle
integriert. Für die Übergabe der multimedialen Datenelemente an diese
Wiedergabekomponente musste eine Schnittstelle entwickelt werden.
Die resultierende Implementierung der Verteilerquelle wird durch die Klassen
„Multisource“, „Server“ und „Client“ funktional definiert.
7.2.1. Multisource
Die Klasse „Multisource“ legt die grundlegende funktionale Architektur der
Verteilerquelle fest. Sie enthält die Mainmethode, die die Initialisierung und den Start der
Komponenten der Verteilerquelle definiert. Die Verteilerquelle besteht aus einer
Clientkomponente, einer Serverkomponente und aus der Wiedergabeeinheit. Die
Clientkomponente sorgt für Datenverbindungen zu meist mehreren Verteilerservern im
118
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
hochdynamischen Netzwerk. Sie nimmt die MPEG4-kodierten multimedialen Elemente
von diesen Servern entgegen und leitet sie zur Darstellung an die Wiedergabeeinheit
weiter. Die Serverkomponente der Verteilerquelle stellt die MPEG4-Sequenz als Service
anderen Dienstnutzern im Netzwerk bereit. Der Datenfluss ist in der folgenden Abbildung
dargestellt:
Abb. 67) Grundgerüst der Implementierung der Verteilerquelle „Multisource“
In der Initialisierungsphase werden, entsprechend der Abb. 67), die Komponenten der
Verteilerquelle für den Datenempfang, die Datenvermittlung und die Darstellung der
multimedialen Daten vorbereitet. Zunächst wird eine Instanz der Klasse „BufferManager“
erzeugt, über deren Referenz die Client- und die Serverkomponente mit dem
Puffermanager kommunizieren können. Danach wird der global gültige Parameterwert für
das Homeverzeichnis gesetzt. Im Homeverzeichnis werden die Konfigurationsdateien der
lokal gepufferten MPEG4-Sequenzen und die Datei „serverlist.sdp“, für die Verwaltung
benachbarter Netzwerkknoten, abgelegt.
Nach der Initialisierungsphase wird die Serverkomponente als Instanz der Klasse „Server“
gestartet. Die Verteilerquelle ist nun als Diensterbringer für die Bereitstellung verfügbarer
Elementarströme bereit.
Der Nutzer kann in der Konsole den Namen einer Multimediasequenz eingeben, die für die
Wiedergabe gewünscht wird. Mit der Bestätigung des Wunsches, wird eine neue Instanz
119
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
der Klasse „Client“ erzeugt. Dem Konstruktor dieser Klasse werden der Name der
gewünschten Multimediasequenz und eine Referenz auf das erzeugte „BufferManager“Objekt übergeben.
7.2.2. Client
Die Klasse „Client“ implementiert die Clientkomponente der Verteilerquelle. Die
Funktionalität der Klasse besteht darin, die vom Nutzer gewünschte Multimediasequenz
bei benachbarten Netzwerkknoten anzufordern, zwischenzuspeichern und lokal
wiederzugeben. Der Hauptanteil der in dieser Klasse implementierten Funktionen
bestimmt den Kommunikationsprozess zwischen der Clientkomponente und
Diensterbringern.
Zunächst stellt der Client eine Service-Anfrage an alle bekannten benachbarten
Netzwerkknoten. Dazu wird die Methode serviceRequestBroadcast() aufgerufen. Der
Client liest zeilenweise die Datei „serverlist“ aus, in der die Anzahl und die Adressen der
benachbarten Netzwerkknoten verwaltet werden. Er erzeugt ein Feld, das Objekte der
Klasse „ServerType“ aufnehmen kann (siehe Abb. 69). Die Feldgröße entspricht der
Anzahl der bekannten benachbarten Netzwerkknoten. Ein „ServerType“-Objekt bündelt
die Eigenschaften eines Servers. Solche Eigenschaften sind z.B. die Serveradresse, die
Linkgüte zwischen dem Client und diesem Server und die aktuelle Uplink-Kapazität des
Servers. Außerdem enthält das „ServerType“-Objekt eine Liste (serviceList) mit Objekten
der Klasse „StreamType“ (siehe Abb. 70). In einem „StreamType“-Objekt sind alle
Informationen für einen Elementarstrom enthalten, der von dem Server des
korrespondierenden „ServerType“-Objekts angeboten wird (siehe Abb.
71). Die
nachfolgende Abbildung stellt den Ausleseprozess beispielhaft dar.
Abb. 68) Auslesen der Datei „serverlist“ und Anlegen des ServerType-Feldes
120
Diplomarbeit
Abb. 69) Definition eines „ServerType“-Objektes
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 70) Definition eines „StreamType“-Objektes
Zu jedem dieser Server wird nacheinander eine TCP-Verbindung - der
Signalisierungskanal - eröffnet und ein „Service Request“ gesendet. Die Anfrage enthält
den Namen der gewünschten Multimediasequenz. Der Server übermittelt daraufhin die
Informationen über alle Elementarströme, die er zu diesem Zeitpunkt für die
Multimediasequenz anbieten kann (siehe Abb.
63). Die Eigenschaften dieser
Elementarströme werden, wie bereits beschrieben, in die Liste „serviceList“ eingetragen.
Abb. 71) Beispiel einer „serviceList“
Sollte ein befragter Server keine Daten für die gewünschte Sequenz zur Verfügung stellen,
dann wird die Serveradresse des korrespondierenden „ServerType“-Objekts mit der
Zeichenfolge „NoService“ überschrieben.
Nachdem die Informationen über die verfügbaren Elementarströme für alle befragten
Server ermittelt wurden, wird die Linkgüte zu diesen Dienstanbietern abgeschätzt. Dazu
erzeugt der Client eine neue Instanz der Klasse „LinkmanagerClient“, die als Parameter
das Feld mit den ermittelten Servern erhält. Von jedem angegebenen Server wird die
verfügbare Uplink-Kapazität erfragt. Mit einer Folge von 10 Ping-Paketen schätzt der
Client die Linkgüte zum Server ab (siehe Abb. 64). Die Ergebnisse werden für jeden
Server im korrespondierenden „ServerType“-Objekt als Servereigenschaft eingetragen.
Der Linkmanager sortiert das Feld nach der Linkgüte der Server. Der Dienstanbieter mit
der besten Anbindung ist nach der Sortierung das erste Element des Feldes. Das sortierte
Feld wird vom Linkmanager an die Clientkomponente zurückgeliefert.
Der Client wählt aus diesem Feld den Kandidaten aus, von dem die
Konfigurationsinformationen der gewünschten Multimediasequenz angefordert werden
121
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
sollen. Aufgrund der Wichtigkeit dieser Informationen wird der Anbieter mit der besten
(sichersten) Anbindung, also das erste Element des Feldes ausgewählt. Die Serveradresse
des Kandidaten wird als Parameter an die Methode requestConfigurationInformation()
übergeben. Mit dieser Methode werden die Konfigurationsinformationen von dem
gewählten Kandidaten angefordert.
Über den Signalisierungskanal sendet der Client einen „Describe Request“, mit dem
Namen der gewünschten Multimediasequenz, an den Kandidaten. Ist die
Konfigurationsdatei beim Server verfügbar, dann erhält der Client die positive Bestätigung
„OK\n“. Im anderen Fall erhält er die Nachricht „NEG\n“ und bricht den gesamten
Kommunikationsprozess ab. Wird die Anfrage vom Server positiv beantwortet, dann
fordert der Client mit einem „SDP Request“ die Konfigurationsinformationen an. Der
Server sendet zeilenweise die Informationen aus der Konfigurationsdatei an den Client
(siehe Abb. 65).
Der Client legt im definierten Homeverzeichnis eine neue Konfigurationsdatei an. Der
Bezeichner der Datei ist identisch mit dem Namen der gewünschten Multimediasequenz
(Service Name). Die Dateiendung „sdp“ weist auf das Format der Informationen hin, die in
der Datei enthalten sein werden. In diese erzeugte Konfigurationsdatei schreibt der Client
die zeilenweise empfangenen Informationen ein. Gleichzeitig ermittelt er die
Elementarstrom-ID’s, die in den empfangen Daten enthalten sind. Die ID’s geben
Auskunft über die Elementarströme, die für die korrekte Dekodierung und Wiedergabe der
Multimediasequenz erforderlich sind. Sie werden in der Liste „ServiceWeNeed“
abgespeichert. Nach der empfangenen Zeichenfolge „END OF FILE“ hat der Client alle
Konfigurationsinformationen erhalten und die Datei wird geschlossen.
122
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Entsprechend der folgenden Abbildung wird die Auswahl der geeigneten Server
vorgenommen, von denen Elementarströme angefordert werden sollen.
Abb. 72) Auswahl der Diensterbringer
Der Client besitzt einerseits mit der Liste „ServiceWeNeed“ die Informationen über die
benötigten Elementarströme. Andererseits sind die serverseitig verfügbaren
Elementarströme durch die „ServerType“-Objekte des sortierten Serverfeldes bekannt. Die
Auswahl der Datenlieferanten wird nun folgendermaßen ermittelt:
Die erste Elementarstrom-ID aus der Liste „ServiceWeNeed“ wird mit den Identifikatoren
der Elementarströme verglichen, die von den Servern des sortierten Serverfeldes angeboten
werden. Beginnend bei dem ersten Element durchläuft der Algorithmus schrittweise das
sortierte Serverfeld, solange bis ein Server gefunden ist, der den Elementarstrom mit der
gesuchten ID anbietet. Zudem überprüft er, ob die Uplink-Kapazität des Servers
ausreichend ist, damit der Server die Daten des Elementarstroms korrekt an den Client
übertragen kann. Existiert ein solcher Server, dann erzeugt der Client eine Instanz der
Klasse „StreamRequest“. Ein „StreamRequest“-Objekt definiert den Ablauf für den
Empfang von Datenelementen eines Elementarstroms und wird als Thread erzeugt. Der
Client parkt dieses Objekt in dem Vektor „StreamRequestList“. Der Auswahlprozess wird
solange wiederholt, bis alle Elemente der Liste „ServiceWeNeed“ durchlaufen sind. Am
Ende enthält der Vektor „StreamRequestList“ eine Folge von Abbildungen, von den
verfügbaren Elementarströmen auf die ausgewählten Datenlieferanten.
Durch den Auswahlalgorithmus wird garantiert, dass immer zuerst die Server mit der
besten Verbindung zum Client als Diensterbringer ausgewählt werden.
123
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Es ist möglich, dass für die Auslieferung aller Elementarströme der gleiche Server
ausgewählt wird. Ebenso können auch mehrere verschiedene Datenlieferanten für die
Anforderung der Elementarströme gewählt werden. Eine Auswahl verschiedener
Kandidaten für die Anforderung eines Elementarstroms ist nicht möglich.
Ein Elementarstrom wird nicht vollständig von einem Netzwerkknoten gepuffert, sondern
nur ein zeitliches Intervall eines Elementarstroms. Da die Elementarströme von
unterschiedlichen Quellen angefordert werden können, differieren die Zeitintervalle der
angeforderten Elementarstromteile. Somit muss nach der erfolgreichen Auswahl der
Diensterbringer ein gemeinsamer Startzeitpunkt für die Auslieferung der Elementarströme
gefunden werden. Dafür ist die Methode SearchStartTimeStamp() zuständig.
Abb. 73) Ermittlung eines gemeinsamen Startzeitpunkts für den Anforderungsprozess der Elementarströme
Der Client ermittelt jeweils den Zeitstempel des jüngsten Datenelements der
Elementarstromteile, die von den verschiedenen Quellen angebotenen werden. Eine
erneute Anfrage an die Server ist nicht erforderlich, da diese Information bereits in den
gespeicherten „Stream-Type“-Objekten jedes ausgewählten Servers enthalten ist. Der
Älteste dieser ermittelten jüngsten Zeitstempel definiert den für alle Elementarströme
gemeinsam gültigen Startzeitpunkt (siehe Abb. 73).
Nun kann es jedoch passieren, dass die Zeitintervalle der Elementarstromteile so
verschieden sind, sodass es keine zeitlichen Überlappungen zwischen den
Elementarstromteilen gibt. Hierfür sind zwei Fälle unterscheidbar:
Entweder ist der erste Elementarstromteil dem zweiten Elementarstromteil zeitlich zu weit
voraus (siehe Abb.
74), oder der erste Elementarstromteil hängt dem zweiten
Elementarstromteil zeitlich zu weit hinterher (siehe Abb. 75).
124
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 74) Puffer- Asynchronität erster Fall
Abb. 75) Puffer - Asynchronität zweiter Fall
Diese beiden Fälle müssen abgefangen werden, da solche Elementarstromteile nicht
miteinander synchronisiert werden können.
Deshalb erfolgt bei der Auswahl des Startzeitpunkts immer der Vergleich, ob das älteste
Datenelement des einen Elementarstroms nicht jünger ist als das jüngste Datenelement des
anderen Elementarstroms bzw. ob das jüngste Datenelement des einen Elementarstroms
nicht älter ist als das älteste Element des anderen Elementarstroms. Kann kein
gemeinsamer Startzeitpunkt gefunden werden, dann wird einer der beiden
Elementarströme nicht angefordert.
Wenn für alle Elementarströme ein gemeinsamer Startzeitpunkt ermittelt werden konnte,
dann wird dieser Zeitwert in allen geparkten „StreamRequest“-Objekten der Liste
„StreamRequestList“ eingetragen. Die Anforderung der Elementarströme erfolgt nun
entsprechend der Abb. 66), indem die „StreamRequest“-Objekte dieser Liste aufgerufen
werden. Referenzen der gestarteten Threads werden in die Threadliste eingetragen.
125
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7.2.3. Server
Die Klasse „Server“ ist mit der Klasse „ServerHauptquelle“ identisch. Aus strukturellen
Gründen wurde die gleiche Klasse einmal für die Hauptquelle und einmal für die
Verteilerquelle implementiert. Beide Serverkomponenten besitzen die gleiche
Funktionalität (siehe Abschnitt 7.1.3).
7.3. Kernsystem
Die implementierten Klassen des Kernsystems werden von den Komponenten der
Hauptquelle und der Verteilerquelle gemeinsam benutzt. Hier sind die spezifizierten
Komponenten Puffer, Puffermanager und Linkmanager sowie alle abstrakten Datentypen
(StreamType, ServerType, RTPPacket, RTCPPacket, ESID) und alle internen
Schnittstellen für die Kommunikation zwischen den Komponenten enthalten.
Die wichtigsten Elemente des Kernsystems sind die Klassen „BufferManager“, „Buffer“,
„CircularQueue“,
„Streaming“,
„StreamRequest“,
„LinkManagerClient“
und
„LinkManagerServer“.
7.3.1. BufferManager
Von der Klasse „BufferManager“ wird in jedem Netzwerkknoten genau eine Instanz
erzeugt. Die Klasse implementiert die Funktionen des spezifizierten Puffermanagers. Der
Puffermanager besitzt Kommunikationsbeziehungen zum Client, zum Server und zum
Puffer des Systems. Er ist für die Initialisierung und die Verwaltung des Pufferfeldes
zuständig und unterhält eine Wissensbasis über alle im Netzwerkknoten verfügbaren
Anteile von Multimediasequenzen und ihren Eigenschaften.
Bei der Initialisierung eines „BufferManager“-Objekts wird zunächst eine
Serviceinformationstabelle, die Wissensbasis des Puffermanagers, angelegt. Die
Serviceinformationstabelle ist ein Vektor, der Objekte des Typs „StreamType“ aufnehmen
kann (siehe Abb. 71). Solch ein Objekt enthält, wie bereits beschrieben, alle Eigenschaften
eines Elementarstroms einer Multimediasequenz.
Mit der Methode addNewService() können die Informationen neuer, verfügbarer
Elementarströme in die Tabelle eingetragen werden.
Der Aufruf der Methode deleteOldService() entfernt Informationen von Elementarströmen,
die von dem Netzwerkknoten nicht mehr angeboten werden.
Die Methode request() hat die Aufgabe, Serveranfragen nach der Verfügbarkeit von
Elementarströmen einer Multimediasequenz zu beantworten. Sind Elementarströme für
126
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
diese Sequenz vorhanden, dann liefert die Methode eine Liste mit den angeforderten
Informationen zurück.
Informationselemente eines lokal verfügbaren Elementarstroms können sich mit der Zeit
ändern. Im Besonderen verändern sich die Zeitinformationen für das erste und das letzte
gepufferte Element eines Elementarstroms. Neue Daten werden in den Puffer
aufgenommen, alte Daten werden aus dem Puffer entfernt. Um die Aktualität der
Serviceinformationstabelle zu gewährleisten, können mit der Methode update() die
eingetragenen Informationen aktualisiert werden.
Nach der Einrichtung der Wissensbasis wird das Pufferfeld vom Puffermanager erzeugt
und initialisiert. Das Pufferfeld ist eine Instanz der Klasse „Buffer“.
Mit der Methode addNewService() wird nicht nur ein Informationseintrag für einen neuen
lokal zu speichernden Elementarstrom erzeugt. Mit dem Aufruf der Methode sendet der
Puffermanager dem „Buffer“-Objekt eine Anweisung zur Initialisierung eines neuen
Pufferfeldelements mit einer definierten Größe. Die Pufferfeldelementgröße wird vom
Puffermanager berechnet. Sie ist abhängig von der durchschnittlichen Datenrate und der
Größe des zu speichernden Zeitintervalls des gewünschten Elementarstromteiles.
Der Wert berechnet sich wie folgt:
Datenrate ∗ Pufferzeit
Pufferfeldelementgröße =
Datenelementgröße
Bit ∗ s
s
Bit
Die Datenrate entspricht der durchschnittlichen Kodierrate des Elementarstroms. Die
Pufferzeit ist aktuell auf 10 Sekunden festgelegt. Sie ist theoretisch unmittelbar von der
Größe des dynamischen Netzwerkes abhängig und soll später variabel an diese Größe
angepasst werden können. Die Datenelementgröße entspricht der MTU des Netzwerks.
Das Ergebnis dieser Berechnung ist eine Abschätzung der Anzahl der Datenelemente, die
das Pufferfeldelement für eine Pufferzeit von 10 Sekunden speichern können muss.
Der Puffermanager erlaubt den Zugriff auf ein bestimmtes Pufferfeldelement mit der
Methode getQueue(). Die Methode erwartet als Eingabeparameter die
Pufferfeldelementnummer für das gewünschte Pufferfeldelement.
Um die Pufferfeldelementnummer für einen Elementarstrom zu ermitteln, kann die
Methode getQueueNr() aufgerufen werden. Sie erwartet als Eingabeparameter den Namen
der Multimediasequenz und die Elementarstrom-ID des Elementarstromteils, das in dem
Pufferfeldelement mit der gesuchten Pufferfeldelementnummer gespeichert ist. Nach dem
Aufruf dieser Methode durchsucht der Puffermanager die Serviceinformationstabelle nach
dem eindeutigen Schlüssel Sequenzname/Elementarstrom-ID. Die zu diesem Schlüssel
eingetragene Pufferfeldelementnummer wird zurückgeliefert.
127
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7.3.2. Buffer
Die Klasse „Buffer“ stellt das Pufferfeld zur Verfügung. Das Pufferfeld ist eine Liste, die
aus meist mehreren Objekten der Klasse „CircularQueue“ besteht. Jedes dieser Objekte ist
ein Pufferfeldelement, das für die Speicherung der Daten eines Datenstroms verantwortlich
ist. Ein Datenstrom ist entweder ein Elementarstrom einer Multimediasequenz oder ein
Strom von Transportkontrollinformationen.
7.3.3. CircularQueue
„CircularQueue“ implementiert die Funktionen für die effiziente Speicherung von Daten
bzw. den Zugriff auf die Daten eines Pufferfeldelements.
Jedes Pufferfeldelement ist ein Ringpuffer (Schlange) mit einer Speicherkapazität, die vom
Puffermanager definiert wurde. In einem Pufferfeldelement können entweder Objekte des
Typs „RTPpacket“ (Datenelement) oder Objekte des Typs „RTCPpacket“
(Transportkontrollprotokollinformation) gespeichert werden. Ihre Funktionalitäten werden
in den gleichnamigen Klassen definiert. Die Syntax der Objekte entspricht den
Empfehlungen der RFC 3550 (siehe [1]).
Für die Datenspeicherung wurde ein Ringpuffer gewählt, da durch diese Pufferart
kontinuierlich in unbegrenzter Zeit Datenelemente in den Puffer aufgenommen werden
können. Die benötigte Speicherkapazität wird einmal festgelegt und nie überschritten. Alte
Datenelemente können einfach durch neue Elemente überschrieben werden. Der
Ringpuffer arbeitet dabei nach dem First-In-First-Out-Prinzip (FIFO). Ein Beispiel eines
Ringpuffers wird in Abb. 76) gezeigt.
Der Puffer wird bei der Initialisierung einmalig mit leeren Datenelementen gefüllt. Mit der
Initialisierung werden zwei Begrenzungszeiger erzeugt. Der Zeiger „Front“ referenziert
das erste, älteste Datenelement des Ringpuffers. Der Zeiger „Back“ verweist auf das letzte,
jüngste Element des Ringpuffers. Für jeden Ringpuffer können „beliebig“ viele Lesezeiger
existieren.
Abb. 76) Ringpuffer
128
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Klasse besitzt verschiedene Methoden für den Zugriff auf den Ringpuffer. Die
Methode add() legt neue Datenelemente im Ringpuffer ab. Vor der Speicherung eines
neuen Elements wird der „Front“-Zeiger um eine Stelle im Uhrzeigersinn verschoben.
„Front“ zeigt nun auf das zweitälteste Element des Puffers. Der vorher von „Front“
referenzierte Speicherplatz ist nun zum Überschreiben freigegeben. Danach wird die
Referenz des „Back“-Zeigers um eine Stelle im Uhrzeigersinn verschoben. „Back“
referenziert jetzt den Speicherplatz, auf den „Front“ vorher verwiesen hat. In der von
„Back“ referenzierten Stelle überschreibt das neue Datenelement die alte Dateneinheit. Das
von „Front“ referenzierte Datenelement ist nun automatisch wieder das Älteste des Puffers.
Idealerweise erreichen die neuen Datenelemente den Puffer in der richtigen Reihenfolge.
Durch den Transportprozess kann die Ordnung der Datenelemente verloren gehen, oder es
treten Datenverluste oder Datenverdoppelungen auf. Um die Datenelemente in der
korrekten Ordnung abspeichern zu können, müssen sie sortiert werden. Alle RTP-Pakete
besitzen eine eindeutige Sequenznummer. Durch diese Sequenznummer existiert ein
Parameter, mit dem die Ordnung der Datensequenz wiederhergestellt werden kann. Es gibt
verschiedene Möglichkeiten, den Sortierprozess zu gestalten. Man kann z.B. den gesamten
Puffer sortieren wenn ein neues Datenelement gespeichert wurde. Intelligenter ist es
jedoch, eine Abbildung zwischen der Sequenznummer der Dateneinheit und der Nummer
des Speicherplatzes für diese Einheit zu generieren. So kann das neue Element direkt an
der richtigen Stelle im Puffer abgelegt werden. Dieser Speicheralgorithmus hat folgende
Vorteile:
•
der Sortierprozess hat eine lineare Laufzeit
•
Duplikate von Datenelementen werden einfach überschrieben
•
auf Datenelemente mit bekannter Sequenznummer kann direkt zugegriffen werden
Für diese Lösung müssen aber verschiedene Ausnahmefälle beachtet werden.
Die Ordnung der gespeicherten Sequenz ist nur dann korrekt, wenn keine Datenverluste
während des Transports aufgetreten sind (siehe Abb. 77). Eine „Lücke“ in der
Sequenznummernfolge bewirkt, dass auch eine Lücke im Ringpuffer entsteht (siehe
Konfigurationsdatei Abb.
78). In dieser Lücke bleiben die alten gespeicherten
Datenelemente erhalten, auch wenn der Puffer bereits mit neuen Datenelementen
überschrieben wurde.
129
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 78)
Abb. 77) Korrekt gefüllter Ringpuffer
Ringpuffer teilweise überschrieben, mit
„Fehlerlücke“ durch Transportverlust der
Elemente 18-21
Dieser fehlerhafte Pufferzustand muss im Ausleseprozess beachten werden.
Die Sequenznummern der Datenelemente liegen im Wertebereich von 0 bis 65536. Da
bedeutend mehr Datenelemente nummeriert werden müssen, werden die Sequenznummern
durch einen Modulo-Zähler erzeugt. Nach dem Datenelement mit der Sequenznummer
65536 folgt somit korrekterweise das Datenelement mit der Sequenznummer 0. Ohne eine
Anpassung des Speicherprozesses, würden bei einem solchen Überlauf Fehler in der
Datenspeicherung auftreten. Um die Korrektheit des Speicherprozesses wieder
herzustellen, muss die Modulo-Operation auch bei der Abbildung der Sequenznummer auf
die Speicherplatznummer angewendet werden. Die Operation führt nur dann zum
korrekten Ergebnis, wenn die Puffergröße ein Vielfaches der Größe des Wertebereichs der
Sequenznummern ist. Jede Zweierpotenz ist ein Vielfaches dieses Wertebereichs. Die vom
Puffermanager geforderte Puffergröße wird deshalb bei der Initialisierung auf die nächste,
größere Zweierpotenz aufgerundet.
Damit zu Beginn des Speicherprozesses der Ringpuffer von der ersten Speicherstelle an
gefüllt wird, muss die Sequenznummer der ersten eintreffenden Dateneinheit gespeichert
werden. Dieses Datenelement wird in der ersten Speicherstelle des Puffers abgelegt. Für
alle folgenden Datenelemente muss nun die Differenz zwischen ihrer Sequenznummer und
der gespeicherten Sequenznummer gebildet werden. Der Wert der Differenz bestimmt
direkt den Speicherplatz des jeweiligen Elements.
Der endgültige Rechenweg für die Ermittlung des korrekten Speicherplatzes einer
Dateneinheit ist folgender:
(( AktuelleSe quenznumme r − StartSeque nznummer ) + SeqWertebe reich ) mod Puffergröß e
130
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Variable „SeqWertebereich“ stellt den Wertebereich der Sequenznummern dar. Die
Addition dieser Variable mit der Differenz entspricht einer Betragsbildung des
Differenzwertes in der Modulo-Operation.
Aufgrund der Möglichkeit eines Sequenznummernüberlaufs, kann anhand der
Sequenznummer nicht mehr auf die zeitliche Aktualität eines eintreffenden Datenelements
geschlossen werden. Deshalb ist ein weiterer Parameter erforderlich, um überprüfen zu
können, ob das eingetroffene Datenelement zeitlich in das Pufferintervall passt. RTP- und
RTCP-Pakete liefern, wie bereits analysiert, die zeitliche Relevanz der in den Paketen
enthaltenen Daten mit. Dieser Zeitstempel kann als geeigneter Parameter für die
notwendige Überprüfung verwendet werden. Es wird verglichen, ob der Zeitstempel des zu
speichernden Datenelements jünger als der Zeitstempel des ältesten gespeicherten
Elements und gleichzeitig älter als der Zeitstempel des jüngsten gespeicherten Elements
ist. Bei einem positiven Ergebnis des Vergleichs kann das Datenelement korrekt in das
Pufferintervall eingegliedert werden. Ist das Ergebnis negativ, dann wird das Element
verworfen.
„CircularQueue“ bietet neben der Methode add() noch folgende weitere Methoden an:
•
reset() - Lesezeiger initialisieren
•
succ() - Lesezeiger verschieben
•
getBack() - Wert des Begrenzungszeigers „Back“ zurückliefern
•
getFront() - Wert des Begrenzungszeigers „Front“ zurückliefern
•
current(Speicherstelle) - Datenelement von der angegebenen Speicherstelle
auslesen
•
bufferOverRun() - Überprüfung auf Pufferüberlauf
•
bufferUnderRun() - Überprüfung auf Pufferleerlauf
•
size() - Anzahl der gepufferten Datenelemente zurückliefern
•
clear () - den Ringpuffer leeren
Ein Pufferleerlauf tritt in dem Moment auf, wenn ein Lesezeiger den Begrenzungszeiger
„Back“ überspringt. In diesem Fall würde der Lesezeiger auf veraltete Datenelemente
verweisen. Ein Pufferüberlauf entsteht, wenn ein Lesezeiger den Begrenzungszeiger
„Front“ unterschreitet. Der Lesezeiger verweist dann auf Datenelemente, die dem aktuellen
Leseprozesszustand vorauseilen. Beide Ereignisse führen zu Fehlern im
Wiedergabeprozess und müssen unbedingt verhindert werden.
131
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7.3.4. Streaming
Die Klasse „Streaming“ implementiert den Prozess für den Datenversand der
Datenelemente eines Elementarstroms. Instanzen der Klasse werden von der
Serverkomponente und von der Clientkomponente erzeugt. Der Server benötigt diese
Objekte, um die Datenelemente angeforderter Elementarströme an einen entfernten Client
zu übermitteln. Die Clientkomponente eines Netzwerkknotens übergibt, mit Hilfe eines
„Streaming“-Objekts, Datenelemente eines lokal gespeicherten Elementarstroms an die
lokale Wiedergabeeinheit weiter.
Zunächst müssen die Pufferfeldelemente ermittelt werden, in dem die Datenelemente des
gewünschten Elementarstroms bzw. die Transportkontrollinformationen gespeichert sind.
Dazu sendet das „Streaming“-Objekt eine Anfrage an den Puffermanager, mit Angabe des
Namens der Multimediasequenz und der Elementarstrom-ID. Existiert ein
Pufferfeldelement für den Elementarstrom, dann liefert der Puffermanager die Nummer
des Feldes zurück. Die zum Datenstrom gehörenden Transportkontrollinformationen
befinden sich im darauf folgenden Pufferfeldelement. Das Objekt kann nun die ermittelten
Pufferfeldelemente zugreifen. Für den Zugriff auf ein Datenelement oder ein Element mit
Transportkontrollinformationen eines Pufferfeldelements wird ein Lesezeiger initialisiert.
Mit dem Parameter „offset“ kann die Position des Lesezeigers im Ringpuffer, relativ zur
Position des Begrenzungszeigers „Back“, festgelegt werden. Der Lesezeiger sollte nie
direkt auf die Position eines Begrenzungszeigers initialisiert werden, da sonst sofort ein
Pufferüberlauf bzw. ein Pufferleerlauf entstehen kann. Während der Testphase des
implementierten Systems stellte sich heraus, dass für die Vermittlung der Elementarströme
an entfernte Netzwerkknoten, der Lesezeiger auf sehr aktuelle Daten, also nahe am
Begrenzungszeiger „Back“ initialisiert werden sollte (siehe Abb. 79).
Im Verteilungsprozess entsteht an jeder Verteilungsstufe eine Verzögerungszeit durch das
Puffern der Elementarströme in den Verteilerquellen. Die Verzögerungszeit zwischen der
Hauptquelle und einer Verteilerquelle der letzten Verteilungsstufe erhöht sich linear mit
der Anzahl der Verteilungsstufen. Die Verzögerungszeit kann minimalisiert werden, indem
der Datenversand an jeder Verteilerquelle mit den aktuellsten verfügbaren Datenelementen
beginnt.
Für die von einem entfernten Client angeforderten Elementarströme wurden jedoch
Startzeitpunkte für den Vermittlungsbeginn festgelegt. Nur die Datenelemente, die eine
relative Zeitinformation enthalten, die größer oder gleich diesem Startzeitpunkt ist, sollen
an den anfragenden Client übermittelt werden. Der Lesezeiger wird deshalb so lange im
Uhrzeigersinn verschoben, bis diese Bedingung von einem Datenelement erfüllt wird.
Für die lokale Datenvermittlung an die Wiedergabeeinheit eines Netzwerkknotens ist es
besser, den Lesezeiger auf ältere Datenelemente, also nahe am Begrenzungszeiger „Front“
132
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
zu initialisieren (siehe Abb. 80). Für den Netzwerkknoten besteht somit die Chance, einen
Verbindungsausfall über einen begrenzten Zeitraum vor dem Wiedergabeprozess
verstecken zu können. Der Zeitraum ist natürlich direkt von der Puffergröße abhängig.
Abb. 79)
Ringpuffer mit Lesezeiger für Streaming zu
Abb. 80)
Ringpuffer mit Lesezeiger für lokales Streaming
einem entfernten Client
Nach der Initialisierung des Lesezeigers ist das „Streaming“-Objekt bereit, Datenelemente
aus dem Puffer auszulesen.
Im nächsten Schritt muss die Auslesegeschwindigkeit bzw. die Vermittlungsgeschwindigkeit für die Elemente des Elementarstroms ermittelt werden. Die
Datenelemente besitzen eine fest definierte Zeitrelevanz. Die Geschwindigkeit muss
deshalb so gewählt sein, dass alle Datenelemente rechtzeitig den Empfänger bzw. den
Decoder erreichen. Die bekannte Datenrate, mit der der Elementarstrom an einer
Hauptquelle erzeugt wurde, kann nicht direkt für die Geschwindigkeitsbestimmung
verwendet werden, da die Rate nur als Mittelwert angegeben ist und den Overhead durch
die Transportinformationen nicht beachtet. Deshalb benutzt der implementierte
Algorithmus für die Geschwindigkeitsabschätzung die relativen Zeitinformationen der
Datenelemente. Der Algorithmus bildet die Differenz zwischen den Zeitstempeln zweier
aufeinander folgender Datenelemente. Vom letzten, bereits vermittelten Datenelement
merkt sich der Algorithmus den Zeitstempel. Der Wert dieses Zeitstempels wird von dem
Zeitwert des aktuell zu vermittelnden Elements abgezogen. Das aktuelle Datenelement
wird erst nach dem Ablauf der errechneten Zeitdifferenz vermittelt. Es dient nun wiederum
als Grundlage für die Berechnung des Vermittlungszeitpunkts für die nächste Dateneinheit.
Diese Nachbildung der originalen Vermittlungsgeschwindigkeit kann nur ein Schätzwert
sein. Durch Berechnungs- und Verarbeitungszeiten weicht die berechnete Geschwindigkeit
von der originalen Geschwindigkeit ab. Der Wert dieser Abweichung ist nicht konstant.
Damit die Differenz zwischen der originalen und der berechneten Geschwindigkeit nicht
133
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
zu groß wird, werden Korrekturkoeffizienten eingesetzt. Diese Koeffizienten können die
Lese- und Vermittlungsgeschwindigkeit geringfügig beschleunigen oder abbremsen. Da
die Originalgeschwindigkeit nicht bekannt ist, kann die Differenz zur berechneten
Geschwindigkeit nicht ermittelt werden. Deshalb wird mit Hilfe der bekannten mittleren
Datenrate des Elementarstroms ein Intervall im Puffer festgelegt, zwischen dessen
Grenzwerten die Lesezeigerposition schwanken darf. Die Grenzwerte berechnen sich wie
folgt:
IntervallUntergrenze = ZeitwertUntergrenze *
bit
DatenrateAVG s ∗ s
PaketgrößeAVG bit
IntervallObergrenze = Zeitwert Obergrenze *
bit
Datenrate AVG s ∗ s
PaketgrößeAVG bit
Der Zeitwert definiert die zeitliche Position eines Grenzwertes im Puffer. Durch die
Multiplikation mit dem Quotienten aus Datenrate und Paketgröße, wird die zeitliche
Position in eine räumliche Position des Grenzwertes im Puffer transformiert.
Die Position des Lesezeigers im Puffer wird kontinuierlich mit einem Sensor ermittelt. Der
Sensorwert entspricht dem Abstand des Lesezeigers zum Begrenzungszeiger „Front“.
Dieser Abstand erhöht sich, für jedes ausgelesene Datenelement und verringert sich für
jedes neu im Puffer abgelegte Datenelement. Erreicht der Sensorwert eine der
Intervallgrenzen, dann wird der entsprechende Korrekturkoeffizient für die
Geschwindigkeitsanpassung aktiviert. Die folgende Abbildung stellt den Prozess grafisch
dar.
Abb. 81) Geschwindigkeitskorrektur im Auslesevorgang
134
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die Lese- und Vermittlungsgeschwindigkeit ist von der Schreibgeschwindigkeit und von
den relativen Zeitinformationen der Datenelemente abhängig. Der Vermittlungszeitpunkt
eines Datenelements wird letztendlich folgendermaßen berechnet:
VZ = (( Zeitstempe lAktuell − Zeitstempe lAlt ) − Korrekturk oeffizient ) + Systemzeit Aktuell
Der Wert des Korrekturkoeffizienten entspricht der halben, mittleren Differenzzeit zweier
aufeinander folgender Datenelemente eines Elementarstroms. Die mittlere Differenzzeit
kann mit dem Quotienten aus der mittleren Datenelementgröße und der bekannten
mittleren Datenrate abgeschätzt werden.
Korrekturkoeffizient =
1
MTU
bit
∗
2 Datenrate AVG bit
s
Die Datenelemente werden in der Hauptquelle, gemäß der „ISMA-Specification“, während
des Kodierprozesses und bei der Paketierung, an die Größe der MTU des Netzwerkes
angepasst. Für die mittlere Datenelementgröße wurde deshalb die MTU des Netzwerks
gewählt.
Für das Lesen aus dem Puffer sind noch einige Besonderheiten zu beachten.
Wenn ein Pufferleerlauf erkannt wurde, dann wird der Auslesevorgang für ein Zeitintervall
von 200 ms gestoppt. In dieser Zeit können neue Daten in den Puffer aufgenommen
werden.
Tritt ein Pufferüberlauf auf, dann werden zwei Datenelemente im Lesevorgang
übersprungen.
Für die Erkennung eines Pufferüberlaufs oder Pufferleerlaufs wird der bereits definierte
Sensor genutzt. Der Sensorwert=0 signalisiert einen Pufferüberlauf. Entspricht der
Sensorwert der maximalen Puffergröße, dann ist ein Pufferleerlauf aufgetreten.
Aufgrund des definierten Speicherungsprozesses können Fehlerlücken im Ringpuffer
existieren. Um die Korrektheit der Ordnung der ausgelesenen Daten zu garantieren,
werden diese Lücken im Auslesevorgang übersprungen. Die Fehlerlücken sind leicht
erkennbar, da sie nur veraltete Datenelemente enthalten. Während des Auslesens wird
kontinuierlich überprüft, ob das gerade gelesene Element zeitlich aktueller ist als das
vorher gelesene Element. Dieser Zeitvergleich ist aufgrund der in den Datenelementen
enthaltenen Zeitinformationen möglich. Ist der Vergleich negativ, dann wurde eine
Fehlerlücke erkannt.
Nachdem dieser relativ aufwändige Initialisierungsvorgang abgeschlossen ist, werden
Transportverbindungen zu dem anfragenden Client, bzw. zur Wiedergabeeinheit
aufgebaut. Der Datentransport erfolgt mit UDP.
135
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Entsprechend der Information aus der Konfigurationsdatei, erwartet die Wiedergabeeinheit
die Elementarströme an lokalen UDP-Sockets mit definierten Portnummern. Der erste
Elementarstrom wird an den lokalen Port mit der Nummer 20000 weitergeleitet. Für jeden
weiteren Elementarstrom erhöht sich die Portnummer um zwei. Die
Transportkontrollinformationen erwartet die Wiedergabeeinheit immer an der nächsten
Portnummer des zugehörigen Elementarstroms. Für den ersten Elementarstrom werden
beispielsweise die Transportkontrollinformationen an den lokalen Port mit der Nummer
20001 übertragen.
Die Übermittlung der Transportkontrollinformationen übernimmt eine Instanz der Klasse
„RTCPServer“.
Für den Transport der Daten an einen entfernten Client sind die Socketadressen nicht
festgelegt. Sie werden in der Signalisierungsphase zwischen den Kommunikationspartnern
ausgetauscht.
Da das unsichere „User Datagram Protocol“ für den Datentransport verwendet wird, kann
das „Streaming“-Objekt nicht erkennen, ob die versendeten Datenelemente den Client
erreichen. Um dennoch die Erreichbarkeit des Kommunikationspartners überprüfen zu
können, wird ein Beobachter für den Streamvorgang generiert. Dieser Beobachter ist eine
Instanz der Klasse „ServerIsAlive“. Der Beobachter erwartet im Abstand von 1,5
Sekunden
„Lebenszeichen“,
in
Form
von
leeren
UDP-Paketen,
vom
Kommunikationspartner. Sollten diese Lebenszeichen über einen Zeitraum von 5
Sekunden ausbleiben, dann wird die Datenübertragung zu diesem Client beendet.
7.3.5. StreamRequest
Die Klasse „StreamRequest“ beschreibt das implementierte funktionale Kernsystem für
den Empfang und die Pufferung von Datenelementen und Transportkontrollinformationen.
Instanzen dieser Klasse werden von der Clientkomponente der Hauptquelle generiert, um
lokale Transportverbindungen zum MP4Live-Stream-Server zu initialisieren und Daten der
ursprünglichen Elementarströme von diesem Server zu empfangen und abzuspeichern. Die
Clientkomponente der Verteilerquelle nutzt Instanzen dieser Klasse, um sich mit
Verteilerservern zu verbinden und Datenelemente bzw. Transportkontrollinformationen
von angeforderten Elementarströmen zu empfangen und zu puffern. Jedes initialisierte
„StreamRequest“-Objekt ist für den Empfang und die Speicherung von Daten eines
Elementarstroms zuständig.
In der Initialisierungsphase fordert das „StreamRequest“-Objekt mit der Methode
addnewService() den Puffermanager auf, zwei neue Pufferfeldelemente für die erwarteten
Datenelemente und Transportkontrollinformationen des Elementarstroms zu generieren.
Der Puffermanager trägt die Eigenschaften des neuen Elementarstroms in der
136
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Serviceinformationstabelle ein und liefert die Nummern der neuen Pufferfeldelemente an
das Objekt zurück. Nach der erfolgreichen Initialisierung der Pufferfeldelemente, werden
mit der Methode Connection() zwei UDP-Verbindungen von der Clientkomponente zum
Diensterbringer aufgebaut. Eine Verbindung wird für die Vermittlung der Datenelemente
des Elementarstroms benötigt. Mit der zweiten Verbindung sollen die
Transportkontrollinformationen (RTCP-Senderreport-Pakete) übertragen werden.
Die Clientkomponente der Hauptquelle erwartet die Elementarströme und die
Transportkontrollinformationen an Ports mit fest definierten Portnummern. Der erste
Elementarstrom wird am Port mit der Nummer 20000 erwartet. Die zu diesem
Elementarstrom
gehörenden
Transportkontrollinformationen
erwartet
die
Clientkomponente der Hauptquelle am Port mit der Nummer 20001. Für jeden weiteren
Elementarstrom und die zugehörigen Transportkontrollinformationen erhöht sich die
Portnummer jeweils um zwei. Diese Festlegung ist notwendig, da die EmpfängerPortnummern für die Elementarströme vom MP4Live-Stream-Server definiert werden.
Die Clientkomponente der Verteilerquelle stellt keine Anforderungen an die Adressen der
Verbindungsendpunkte. Die Portnummern werden in der Signalisierungsphase zwischen
der Clientkomponente der Verteilerquelle und dem Diensterbringer ausgehandelt.
Nach
der
erfolgreichen
Initialisierung
der
Transportverbindungen beginnt der Datenempfang.
Pufferfeldelemente
und
der
Um die Transportkontrollinformationen unabhängig vom Empfang der Datenelemente des
Elementarstroms entgegennehmen und speichern zu können, wird in der Methode
getRTCP() eine Instanz der Klasse „RTCPClient“ als Thread generiert. Diese Instanz
empfängt die Transportkontrollinformationen und puffert sie im entsprechenden
Pufferfeldelement.
Die Methode getData() der Klasse „StreamRequest“ übernimmt den Empfang und die
Speicherung der Datenelemente des Elementarstroms.
Damit die Clientkomponente auf Verbindungsausfälle reagieren kann, überprüft sie die
Kontinuität des Datenempfangs. Durch Verbindungsausfälle oder Datenverluste während
des Transports, entstehen kürzere oder längere Pausen im Empfangsprozess. Ein
Verbindungsausfall wird angenommen, wenn in einer Zeitspanne von mehr als 10
Sekunden kein Paket mehr empfangen wurde.
Auch der Diensterbringer überprüft kontinuierlich die Erreichbarkeit seiner Dienstnutzer.
Deshalb erwartet er von der Clientkomponente in definierten zeitlichen Abständen ein
Lebenszeichen. Mit dem Beginn des Empfangsprozesses wird eine Instanz der Klasse
„ClientIsAlive“ generiert. Dieses Objekt versendet alle 1,5 Sekunden ein leeres UDP-Paket
an den entfernten Kommunikationspartner.
137
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Tritt ein Verbindungsausfall auf, oder entfernt sich einer der Kommunikationspartner aus
dem dynamischen Netzwerk, dann kann dieser Zustand durch diese Mechanismen von
beiden Seiten erkannt werden.
Das „StreamRequest“-Objekt einer Verteilerquelle hat zusätzlich zum Datenempfang die
Aufgabe, den empfangenen, gepufferten Elementarstrom an die Wiedergabeeinheit
weiterzuleiten. Nachdem ein definierter Pufferfüllstand für den Elementarstrom erreicht
wurde, wird eine Instanz der Klasse „Streaming“ erzeugt. Dieses „Streaming“-Objekt liest
die gepufferten Datenelemente des Elementarstroms aus und übergibt sie für die
Darstellung an die Wiedergabeeinheit.
7.3.6. LinkmanagerClient
Die Klasse „LinkmanagerClient“ implementiert die Funktionen zur Überprüfung der
Kanalgüte zwischen dem Client und seinen benachbarten Netzwerkknoten. Im Besonderen
wird die durchschnittliche Umlaufzeit (RTT) errechnet und die Häufigkeit von
Datenverlusten ermittelt.
Bei der Initialisierung einer Instanz der Klasse, wird dem Konstruktor eine Liste mit den
Adressen der benachbarten Netzwerkknoten übergeben.
Der Linkmanager überprüft die Verbindungseigenschaften zu jedem dieser angegebenen
Server.
Zunächst wird die serverseitig verfügbare Uplink-Kapazität erfragt.
Danach sendet der Linkmanager zehn Ping-Pakete zu dem Server. In jedem Paket ist ein
Zeitstempel mit der aktuellen Systemzeit des Linkmanagers enthalten. Der Zeitstempel
entspricht dem Versandzeitpunkt des Pakets. Der Linkmanager erwartet, dass alle Pakete
an ihn zurückgesendet werden. Beim Empfang eines Pakets wird wiederum die Systemzeit
des Linkmanagers aufgenommen. Die Umlaufzeit des Pakets kann nun einfach durch die
Differenz zwischen der aktuellen Systemzeit und dem Zeitstempel des Pakes bestimmt
werden.
RTT = Sendezeitp unkt − Empfangsze itpunkt
Um einen genaueren Eindruck über die Verbindungsqualität zur erhalten ist es besser,
einen durchschnittlichen Wert für die Umlaufzeit, über alle korrekt empfangen Pakete zu
berechnen.
RTT AVG = RTT AVG +
RTT Akt
10
RTTAkt entspricht der ermittelten Umlaufzeit des gerade empfangenen Pakets.
138
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Wenn mehr als eine Sekunde nach dem Paketversand vergangen ist, ohne dass das Paket
wieder den Linkmanager erreicht hat, dann wird dieses Paket als verloren signalisiert. Für
jeden Paketverlust erhält der getestete Server eine Zeitstrafe von 2 Sekunden.
Konnte zu einem angegebenen Server keine Verbindung aufgebaut werden, dann erhält der
Server die maximale Zeitstrafe von 20 Sekunden, und die Anzahl der Paketverluste wird
auf 10 festgelegt.
Nach dem Test der Verbindungsqualität wird die berechnete Gesamtzeitstrafe, für die
Anzahl der Paketverluste, zu der ermittelten durchschnittlichen Umlaufzeit addiert.
RTT AVG = RTT AVG + n ∗ 2 Sekunden (n = Anzahl der Paketverluste)
Die für jeden Server ermittelten Parameter werden als Servereigenschaften in die
Serverliste (siehe Abb. 72) / erste Tabelle) eingetragen.
Zum Schluss sortiert der Linkmanager die Serverliste nach der Größe des Wertes der
durchschnittlichen Umlaufzeit. Als Sortierverfahren wird Quicksort eingesetzt. Die
resultierende Liste ist aufsteigend geordnet, beginnend mit dem Server, der den kleinsten
Wert für die durchschnittliche Umlaufzeit besitzt.
7.3.7. LinkManagerServer
Die Klasse „LinkManagerServer“ hat die Aufgabe, die Uplink-Kapazität des Servers zu
verwalten. Aktuell wird die Kapazität mit einem definierten Wert initialisiert. Durch die
Vermittlung eines Datenstroms von diesem Server an einen anderen Netzwerkknoten sinkt
die Uplink-Kapazität. Der Kapazitätswert wird um den Betrag der mittleren Datenrate
dieses Datenstroms verringert. Ist die Vermittlung eines Datenstroms beendet, dann wird
der Kapazitätswert um den Betrag der mittleren Datenrate dieses Datenstroms erhöht.
7.3.8. RTPPacket
Die Daten der zu vermittelnden und zu speichernden Elementarströme sind in RTPPaketen gekapselt. Durch eine Instanz der Klasse „RTPPacket“ kann ein Datenelement
eines Elementarstroms abstrakt, als speicherbare und transportierbare Einheit, in Form
eines RTP-Paket-Objektes eindeutig beschrieben werden. Durch die definierten Methoden
der Klasse kann man auf die wichtigsten internen Headerinformationen und den Datenteil
der RTP-Pakete zugreifen. Die wichtigsten Informationen sind die Zeitstempel und die
Sequenznummern der Pakete.
139
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
7.3.9. StreamManager
Die Klasse „StreamManager“ sorgt dafür, dass der Verteilungsprozess für
zusammengehörige Elementarströme zur gleichen Zeit gestartet wird. Der Stream Manager
ist also ein Mechanismus, mit dem „Streaming“-Threads synchronisiert werden können.
Dazu werden alle „Streaming“-Objekte in eine Warteliste aufgenommen. Dort werden die
Objekte solange festgehalten, bis der letzte der zusammengehörenden Elementarströme
(„Streaming“-Thread) für den Verteilungsprozess initialisiert und bereit ist.
140
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
8. Ergebnisse
In diesem Kapitel werden die Ergebnisse vorgestellt und ausgewertet, die mit dem
implementierten neuen Multisource-Streaming-Ansatz durch verschiedene Experimente
ermittelt werden konnten. Die Untersuchung gliedert sich in fünf Versuchsaufbauten auf,
mit denen jeweils meist mehrere Testreihen generiert wurden.
In den Experimenten wurden multimediale Livedaten von einer Hauptquelle erzeugt und in
einem Netzwerk bereitgestellt.
Die technischen Eigenschaften der Hauptquelle entsprechen den Angaben des Abschnitts
6.6. Die Hautpquelle besitzt keinen WLAN-Adapter und muss deshalb drahtgebunden mit
einer Verteilerquelle verbunden werden.
Die multimedialen Daten bestehen aus zwei MPEG4-kodierten Elementarströmen. Der
Videoelementarstrom wird mit einer durchschnittlichen Datenrate von 500kbs in XViD
kodiert. Der Audioelementarstrom wird mit einer Samplerate von 44,1 kHz und
entsprechend dem MPEG4-AAC-Standard erzeugt.
In der Testumgebung existieren drei Verteilerquellen, die drahtlos im Adhoc-Modus
kommunizieren. Zwei Verteilerquellen arbeiten mit dem Betriebssystem Debian (Linux /
Kernel 2.6.8) und jeweils mit einem drahtlosen Netzzugang (WLAN-RoamAbout
(802.11b)). Bei diesen Verteilerquellen wird der MPlayer als Wiedergabeeinheit/Decoder
verwendet. Die dritte Verteilerquelle nutzt das Microsoft Betriebssystem MS Windows
XP. Sie besitzt einen drahtlosen Netzzugang (WLAN-Karte D-Link DWL 650G+
(802.11g)) zum Adhoc-Netzwerk und eine drahtgebunde Verbindung zur Hauptquelle. Für
diese
Verteilerquelle
wurde
der
WMP4Player
von
MPEG4IP
als
Wiedergabeeinheit/Decoder ausgewählt.
141
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
8.1. Test der Ressourcenauslastung (single Source Streaming)
Mit dem ersten Experiment soll die Auslastung der Ressourcen einer Quelle ermittelt
werden, die durch den Verteilungsvorgang multimedialer Daten an vier Empfänger
entsteht.
Im Versuchsaufbau existieren fünf Verteilerquellen und eine Hauptquelle, die
drahtgebunden miteinander vernetzt sind. Die folgende Abbildung stellt die Topologie
grafisch dar:
Abb. 82) Netzwerktopologie im Versuchsaufbau 1: Multiple Anfragen
Durch die Generierung der multimedialen Daten sind die Ressourcen der Hauptquelle
zusätzlich belastet. Da die Ressourcenauslastung für den Verteilungsprozess ermittelt
werden soll, wird das Messergebnis durch diese zusätzliche Belastung verfälscht. Deshalb
werden die Messgrößen Prozessorlast, genutzte Hauptspeicherkapazität, Eingangsdatenrate
und Ausgangsdatenrate an der Verteilerquelle VQ1 ermittelt. Diese Verteilerquelle erhält
die multimedialen Daten von der Hauptquelle und bietet sie im Netzwerk an. In
gleichmäßigen Abständen stellen die Verteilerquellen VQ2, VQ3, VQ4 und VQ5 jeweils
eine Serviceanfrage an die Verteilerquelle VQ1. VQ1 liefert die angeforderten
Elementarströme direkt nach jeder Anfrage aus. Die Abb. 83) stellt die Messergebnisse
dar:
142
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 83) Messergebnis Versuch 1
Das linke obere Bild beschreibt die Prozessorlast in Prozent. Rechts daneben wird die
benötigte Hauptspeicherkapazität in Byte angegeben. Die linke untere Grafik stellt die
Eingangsdatenrate in KByte/s dar. Das rechte untere Messfenster beschreibt den zeitlichen
Verlauf der Ausgangsdatenrate in KByte/s.
Die Prozessorlast und die Hauptspeicherauslastung bleiben während der Messzeit konstant.
Die Ausgangsdatenrate steigt linear mit der Anzahl der Serviceanfragen an. Nach vier
Serviceanfragen wird bereits eine Bandbreite von mehr als 300KByte/s benötigt, um die
multimedialen Daten vom Diensterbringer an die Dienstnutzer zu verteilen. Die kritische
Ressource der Verteilerquelle ist somit die Kapazität der verfügbaren Ausgangsbandbreite.
Der Uplink einer Verteilerquelle ist ohne einen guten Verteilungsmechanismus sehr
schnell ausgelastet.
143
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
8.2. Entfernungstest im drahtlosen Adhoc-Netzwerk (single Source
Streaming)
Im zweiten Versuchsaufbau wird die maximale Entfernung ermittelt, bei der multimediale
Daten drahtlos im Adhoc-Netzwerk übertragen werden können. Dabei soll die zu
erwartende Fehlerrate maximal so groß werden, dass die multimedialen Daten am
Verbindungsendpunkt des Dienstnutzers noch darstellbar sind. Es werden vier Testreihen
ausgewertet. Die Entfernung zwischen Diensterbringer und Dienstnutzer beträgt in der
1.Testreihe 1m, in der 2.Testreihe 5m, in der 3.Testreihe 28m und in der 4.Testreihe 30m.
Die Verteilerquelle VQ1 ist drahtgebunden mit der Hauptquelle vernetzt und besitzt eine
drahtlose Verbindung zum Adhoc-Netzwerk. Das Adhoc-Netzwerk besteht aus den
Verteilerquellen VQ1 und VQ2, wobei VQ1 als Diensterbringer und VQ2 als Dienstnutzer
auftreten. Die folgende Abbildung stellt die Topologie der vier Testreihen grafisch dar:
Abb. 84) Netwerktopologie im Versuchsaufbau 2: Entfernungstest
Gemessen wurden die Meßgrößen Entfernung, Zeitdifferenz zwischen gepufferten
Elementarströmen, Paketverluste des Audio-Elementarstroms, Paketverluste des VideoElementarstroms, die Darstellungsqualität (Schätzung) und die mittlere Umlaufzeit von 10
Ping-Paketen. Die Verteilquellen VQ1 und VQ2 wurden als Messpunkte ausgewählt.
144
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Folgende Messergebnisse konnten in den vier Testreihen ermittelt werden:
Abstand zum
Zeitdifferenz
Diensterbringer zwischen ES
in m
in ms
Test
Nr.
Mess
punkt
Messzeitraum
in min
1
VQ1
5,00
0
913
0
0
5
VQ2
5,00
1
640
0
0
0
2
3
4
Paketverluste Paketverluste Darstellungs RTT
Audio
Video
qualität
in s
Timeouts
VQ1
5,00
0
956
0
0
3
VQ2
5,00
5
201
1
0
1
VQ1
5,00
0
943
0
0
9
VQ2
5,00
28
343
15
21
57
VQ1
2,00
0
903
0
0
2
VQ2
ca. 0,5
30
247
Verbindungs
abbruch
nach ca 30
sek.
59
128
0,0
sehr gut
0,0
0,0
sehr gut
0,1
0,0
befriedigend
Pixelfehler
Stocken in
der Audiowiedergabe
0,3 +
Time
outs
0,0
schlecht,
Bild bleibt
stehen,
Audio kaum
verstehbar
0,6 +
Time
outs
Tabelle 9: Messergebniss Entfernungstest (single Source)
Wie erwartet, wird die Fehlerhäufigkeit mit zunehmender Entfernung größer und die
Darstellungsqualität der übertragen Multimediasequenz nimmt ab. Bei Entfernungen
zwischen 1m bis 5m treten Übertragungsfehler sehr selten auf und die Darstellungsqualität
ist sehr gut. Mehr als 28m sollte die Strecke zwischen Diensterbringer und Dienstnutzer in
dem gewählten drahtlosen Adhoc-Netzwerk nicht betragen. Bei dieser Entfernung treten
schon häufige Datenverluste während der Übertragung auf, die sich in sichtbaren
Pixelfehlern und Stockungen bei der Tonwiedergabe äußern. Schließlich bricht die
Verbindung bei einem Abstand von 30m zwischen den Kommunikationspartnern ab.
Die hohe Fehlerhäufigkeit im drahtgebundenen Verbindungsabschnitt, zwischen der
Hauptquelle HQ und der Verteilerquelle VQ1, erklärt sich durch die hohe CPU-Auslastung
(95%) der Hauptquelle. Die Hauptquelle wird durch die Generierung (Kodierung) der
multimedialen Datenströme enorm belastet.
145
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
8.3. Entfernungstest mit multiplen Anfragen (single Source Streaming)
Der dritte Versuchsaufbau ist ähnlich zum Aufbau des vorigen Abschnittes. Die
Verteilerquelle VQ1 tritt jedoch gegenüber zwei Dienstnutzern (VQ2, VQ3) als
Diensterbringer auf. Die folgende Abbildung verdeutlicht die topologische Struktur:
Abb. 85) Netzwerktopologie im Versuchsaufbau 3: Entfernungstest/Kapazitätsauslastung
Es wurden Messergebnisse für zwei Testreihen ermittelt. In der ersten Testreihe betrug der
Abstand von jedem Dienstnutzer zum Diensterbringer 2m. In der zweiten Testreihe
bewegte sich ein Dienstnutzer in einer Entfernung von 15m - 20m von der Verteilerquelle
VQ1 weg. Der zweite Dienstnutzer bewahrte während des gesamten Messzeitraums einen
Abstand von 15m zu VQ1. Die nachstehende Tabelle gibt die gewonnen Messergebnisse
wieder:
Abstand zum
Zeitdifferenz
in m
in ms
Test
Nr.
Mess
punkt
Messzeitraum
in min
5
VQ1
5,00
0
934
0
0
7
k.A.
0,0
VQ2
5,00
2
343
2
0
3
sehr gut
0,0
VQ3
5,00
2
411
0
0
3
sehr gut
0,0
VQ1
5,00
0
970
0
0
2
k.A.
0,0
VQ2
5,00
15
192
2
0
0
sehr gut
0,2
38
gut, wenige
Pixelfehler,
selten Ton
stockungen
0,2
6
VQ3
5,00
15 - 20
224
Audio
Video
qualität
in s
Timeouts
6
11
Tabelle 10: Messergebnis Entfernungstest mit multiplen Anfragen (single Source)
146
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Obwohl die Auslastung der Uplink-Kapazität durch die Existenz zweier Dienstnutzer an
der Verteilerquelle VQ1 gegenüber dem Test aus Abschnitt 8.2 erhöht wurde, hat sich das
Fehlerverhalten des Vermittlungsprozesses nicht wesentlich verändert. Deshalb wird mit
der Messung der Kapazitätsauslastung des Datenein- und Datenausgangs der
Verteilerquelle VQ1 eine weitere Untersuchung vorgenommen.
Die Messergebnisse der zusätzlichen Messgrößen sind in der folgenden Grafik ersichtlich:
Abb. 86) Messergebniss Ressourcenauslastung VQ1 Versuch 3
Das obere Messfenster stellt die Auslastung der Dateneingangskapazität (100Mbit/s) der
Verteilerquelle VQ1 in Prozent dar. Die untere Messkurve beschreibt die Auslastung der
Uplink-Kapazität (11Mbit/s) von VQ1 in Prozent. Zum Zeitpunkt t1 stellt VQ2 eine
Serviceanfrage an die Verteilerquelle VQ1. Daraufhin beginnt VQ1 damit, die
Multimediasequenz an den Dienstnutzer auszuliefern. Die Auslastung der UplinkKapazität steigt von 0% auf ca. 6,25% an. Zum Zeitpunkt t2 erhält die Verteilerquelle VQ1
eine weitere Serviceanfrage vom zweiten Diensnutzer VQ3. Die Auslastung der UplinkKapazität steigt mit der zusätzlichen Auslieferung der multimedialen Daten an den zweiten
Dienstnutzer weiter um ca. 6,25% auf 12,5% an. Auch in diesem Versuch ist erkennbar,
dass die Kapazitätsauslastung linear mit der Anzahl der Serviceanfragen steigt. Zum
147
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Zeitpunkt t3 bricht der erste Dienstnutzer die Verbindung zu VQ1 ab. Die
Datenvermittlung zu diesem Netzwerkknoten wird beendet und die Auslastung der UplinkKapazität sinkt um ca. 6,25% ab. Zum Zeitpunkt t4 bricht auch der zweite Dienstnutzer die
Verbindung zu VQ1 ab und der Datenvermittlungsprozess wird beendet. Die Auslastung
der Eingangskapazität bleibt während des gesamten Messzeitraums konstant. Die
Hauptquelle wird, als Diensterbringer an VQ1, durch die Anfragen mehrerer Dienstnutzer
an VQ1 nicht weiter belastet. Durch diese kooperative Art der Datenverteilung kann die
Gesamtlast auf mehrere Netzwerkknoten aufgeteilt werden.
Durch die zusätzlichen Messergebnisse ist ersichtlich, dass die mittlere UplinkKapazitätsauslastung maximal 12,5% beträgt. Aufgrund dieser geringen Auslastung,
unterscheidet sich das Fehlerverhalten des Vermittlungsprozesses nicht wesentlich vom
ermittelten Verhalten in Abschnitt 8.2. Die Mobilität der Verteilerquelle VQ3 hatte geringe
Auswirkungen auf die Fehlerhäufigkeit. Mit zunehmendem Abstand von VQ3 (bis max.
20m) zur Verteilerquelle VQ1 erhöhte sich die Häufigkeit von Übertragungsfehlern
geringfügig. Die Darstellungsqualität nahm ab und musste von „sehr gut“ auf „gut“
herabgestuft werden.
148
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
8.4. Entfernungstest im 3-stufigen Verteilersystem (single Source
Streaming)
Das vierte Experiment soll ermitteln, ob die Übertragungsstrecke durch eine Kette von
hintereinander geschalteten Verteilerquellen verlängert werden kann. Dazu werden eine
Hauptquelle und drei Verteilerquellen entsprechend der Abb. 87) miteinander verbunden.
Die in Abschnitt 8.3 definierten Messgrößen sollen auch in diesem Versuch für die
Ermittlung von Testergebnissen verwendet werden.
Abb. 87) Netzwerktopologie Versuch 4: erweiterter Entfernungstest
Folgende Ergebnisse wurden gemessen:
Test
Nr.
Mess
punkt
Messzeitraum
in min
7
VQ1
6,00
8
Abstand zum
Zeitdifferenz
in m
in ms
0
Timeouts
933
Audio
Video
qualität
in s
0
0
2
k.A.
0,0
VQ2
6,00
1
150
0
0
2
sehr gut
0,0
VQ3
5,00
1
152
0
0
2
sehr gut
0,0
VQ1
5,50
0
963
0
0
10
k.A.
0,0
VQ2
5,50
15
224
0
0
2
sehr gut
0,2
8
gut, wenige
Ton
stockungen
0,2
VQ3
5,00
22,00 zu VQ2
37,00 zu VQ1
287
0
6
Tabelle 11: Messergebnis 3-stufiger Entfernungstest (single Source)
149
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Aus den Messwerten ist erkennbar, dass durch den Vermittlungsprozess des
implementierten Systems und eine Kettenschaltung von mehreren Verteilerquellen, der
Übertragungsradius für die Verteilung multimedialer Daten im Adhoc-Netzwerk
vergrößert werden kann. Der Gesamtabstand zwischen der Verteilerquelle VQ3 und der
Hauptquelle beträgt bei einer guten Darstellungsqualität 37m. Im Versuchsaufbau 8.2 ist
dagegen die Verbindung in der vierten Testreihe, bei einer Entfernung von 30m zwischen
der Hauptquelle und der Verteilerquelle der letzten Verteilungsstufe, abgebrochen und die
Darstellungsqualität war schlecht.
Während des Testzeitraums wurden an der Verteilerquelle VQ1 die Auslastung der
Eingangsbandbreite und die Auslaustung der Uplink-Kapazität gemessen. Die Messkurven
werden in Abb. 88) wiedergegeben.
Abb. 88) Messergebnis Ressourcenauslastung VQ1 Versuch4
Die Werte der Auslastung sind in Prozent dargestellt. Über den gesamten Messzeitraum
wurde genau eine Dienstanforderung von VQ1 erfüllt. Die Auslastung der UplinkKapazität von 11Mbit/s betrug im Mittel ca. 6,25%. Über den Zeitraum der Messung
konnte eine mittlere Auslastung der Eingangskapazität (100Mbit/s) von weniger als 1%
ermittelt werden. Die Serviceanfrage von der Verteilerquelle VQ3 an die Verteilerquelle
150
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
VQ2 hatte keine Auswirkungen auf die Auslastung der Uplink-Kapazität und die
Auslastung der Eingangskapazität von VQ1. Dies zeigt, dass durch das implementierte
Verteilersystem multimediale Daten mehrfach in der Verteilungskette für den
Darstellungsprozess verwendet werden.
8.5. Entfernungstest im 3-stufigen Verteilersystem (multi Source
Streaming)
Im letzten Versuchsaufbau wird die Funktionsweise des Verteilungsprozesses überprüft,
indem Elementarströme von unterschiedlichen Quellen angefordert werden. Eine
Hauptquelle und drei Verteilerquellen sind im Adhoc-Netzwerk drahtlos miteinander
verbunden. Die Abb. 89) zeigt die Netzwerktopologie des Versuchsaufbaus von zwei
Testreihen.
Abb. 89) Netzwerktopologie Versuch5: multi Source Streaming
Die realen Uplink-Kapazitäten (11Mbit/s) der Verteilerquellen erlauben im
implementierten Vermittlungssystem die Übertragung aller Elementarströme von einem
Diensterbringer zu einem Dienstnutzer.
Um den Vermittlungsprozess, wie in Abb. 89) dargestellt, realisieren zu können, mussten
die Werte für die Uplink-Kapazitäten der Verteilerquellen VQ1 und VQ2 künstlich
beschränkt werden. Der Verteilerquelle VQ1 wurde eine Ausgangsvermittlungskapazität
von 1150kBit/s zugewiesen. Die Uplink-Kapazität der Verteilquelle VQ2 wurde auf
151
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
600kBit/s festgelegt. VQ1 kann nun eine Dienstanforderung vollständig erfüllen und die
Elementarströme einer zweiten Serviceanfrage nur teilweise ausliefern (entweder VideoES, oder Audio-ES). Die Verteilerquelle VQ2 ist nur in der Lage, eine Dienstanforderung
teilweise zu erfüllen.
Folgende Messergebnisse wurden ermittelt:
Test
Nr.
Mess
punkt
7
VQ1
5,50
VQ2
8
Messzeitraum Abstand zum
in min
Diensterbringer in
m
Zeitdifferenz
zwischen ES
in ms
Timeouts
Audio
Video
qualität
in s
0
938
0
0
9
k.A.
0,0
5,50
1,5
460
1
0
2
sehr gut
0,0
VQ3
5,00
0,5 zu VQ2
1,5 zu VQ1
1080
1
0
3
sehr gut
0,0
VQ1
5,50
0
931
0
0
2
k.A.
0,0
VQ2
5,50
9
376
0
0
2
sehr gut
0,2
5,00
ES1: 20,00 zu VQ1
ES2: 35,00 zu VQ1
bzw.
ES2: 26,00 zu VQ2
15
gut, wenige
Ton
stockungen
wenige
Pixelfehler
0,2
zu
VQ1
0,3
zu
VQ2
VQ3
1244
1
8
Tabelle 12: Messergebnis 3-stufiger Entfernungstest (multi Source)
Von den ermittelten Ergebnissen hebt sich die Messgröße „Zeitdifferenz zwischen
Elementarströmen“ der Verteilerquelle VQ3 gegenüber den gemessenen Werten voriger
Experimenten ab. Die größere Differenz entsteht teilweise durch die unterschiedlichen
Längen der Übertragungswege, hauptsächlich jedoch durch die unterschiedliche Anzahl
der Verteilungsstufen, über die die Elementarströme übertragen wurden. Ein
Elementarstrom wird an zwei Verteilungsstufen zwischengespeichert, der andere
Elementarstrom an einer Verteilungsstufe weniger. Obwohl diese erhöhte Zeitdifferenz
zwischen den Elementarströmen existiert, ist die Darstellungsqualität der
zusammengesetzten Multimediasequenz in der 1.Testreihe sehr gut und in der zweiten
Testreihe gut. Die Herabstufung der eingeschätzen Darstellungqualität der 2.Testreihe
entsteht weniger durch die Anforderung der Elementarströme von verschiedenen Quellen,
sondern mehr durch die größeren Abstände zwischen den Diensterbringern und dem
Dienstnutzer. Die Nutzung mehrerer Diensterbringer im Verteilungsprozess kann aufgrund
der ermittelten Ergebnisse nur eine geringe Auswirkung auf die Darstellungsqualität
haben.
Auch in diesem letzten Experiment wurden an der Verteilerquelle VQ1 die Auslastungen
der verfügbaren Eingangs- und Ausgangsbandbreite gemessen. Die Abb. 90) stellt den
Messverlauf grafisch dar.
152
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Abb. 90) Messergebnis Ressourcenauslastung VQ1 Versuch5
Die Auslastung wird über den gesamten Messzeitraum in Prozent angegeben. Die
Kapazität der Eingangsbandbreite wurde im Mittel weniger als 1% genutzt. Die Auslastung
der Kapazität der Ausgangsbandbreite stieg mit der Anzahl der Serviceanfragen an. Die
Verteilerquelle VQ1 lieferte in diesem Test einen Audio- und einen Videodatenstrom an
VQ2 sowie einen weiteren Videodatenstrom an VQ3 aus. VQ3 erhielt den
Audiodatenstrom von der Verteilerquelle VQ2.
Zum Zeitpunkt t1 bewirkte die Auslieferung der multimedialen Daten an den ersten
Dienstnutzer einen Anstieg der Auslastung der Uplink-Kapazität auf ca. 6,25%. Zum
Zeitpunkt t2 wurde der zweite Videodatenstrom an die Verteilerquelle VQ3 vermittelt. Die
Auslastung erhöhte sich auf ca. 10%. Nach dem Abbruch des Datenempfangs zum
Zeitpunkt t3 durch VQ2 und VQ3 wurde der Vermittlungsprozess beendet.
Die Auslastung der Verteilerquelle VQ1 konnte durch die Lastverteilung zwischen den
Diensterbringern gegenüber dem Experiment aus Abschnitt 8.3 von 12,5% auf 10%
gesenkt werden.
153
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
9. Zusammenfassung
Das Ziel dieser Arbeit war die Entwicklung eines Konzepts, dass einen neuen
Verteilungsmechanismus für multimediale Daten in hochdynamischen Netzwerken
beschreibt. Ein ausgewähltes, verfügbares Kodierverfahren sollte dabei die Grundlage für
das Konzept liefern. Die Anforderung an das gewählte Verfahren bestand darin, eine
Multimediasequenz bereits im Kodierprozess so skalierbar zu strukturieren, dass sie
flexibel an alle Endgeräteklassen anpassbar ist und aus mehreren unabhängig verteilbaren
Datenströmen besteht.
Die Datenströme sollten von verschiedenen Quellen anforderbar sein und zu einer
darstellbaren Multimediasequenz zusammengeführt werden können. Dieser Grundgedanke
ermöglicht eine kooperative Lastverteilung bei der Dienstbereitstellung zwischen den
Teilnehmern des Netzwerks. An die Datenströme wurde die zusätzliche Bedingung
gestellt, durch eine definierte Stromstruktur robuster gegenüber Fehlern bei der
Übertragung über verlustbehaftete Kanäle zu sein.
Nach der Anforderungsanalyse wurden für das zu entwickelnde System der Entwurf und
die Spezifikation erstellt. Danach folgte eine Recherche über die verfügbaren
Kodierverfahren, Protokolle und Systeme, die für eine Implementierung des spezifizierten
Konzepts eingesetzt werden können.
Bei der umfassenden Analyse der Kodierverfahren wurde MPEG4 als grundlegendes
Kodierverfahren für den neuen Multisource-Streaming-Ansatz gewählt. Den theoretischen
Angaben des Standards zufolge, erfüllt MPEG4 alle analysierten Anforderungen an das zu
verwendende Kodierverfahren. Während der Untersuchung verfügbarer Encoder, StreamServer und Decoder wurde jedoch festgestellt, dass keine der aktuellen Geräte, die im
MPEG4-Standard ausgewiesenen Techniken für eine skalierbare Kodierung multimedialer
Daten unterstützen. Das Ziel, eine schnelle und effiziente Anpassung multimedialer
Datenelemente an die Anforderungen unterschiedlicher Endgeräteklassen realisieren zu
können, war deshalb zum Zeitpunkt der Implementierung des neuen MultisourceStreaming-Ansatzes nicht erreichbar.
Welche Anforderungen an das neue Verteilungssystem konnten dennoch erfüllt und in
einer prototypischen Implementierung umgesetzt werden?
Mit der Auswahl von MPEG4IP stand ein Gesamtsystem für die Erstellung und die
Darstellung multimedialer Daten und ihrer Vorbereitung auf den Transportprozess zur
Verfügung. Die Struktur der generierten Datenströme entspricht dem MPEG4-Standard im
„Simple-Profile“. Somit wurde die Forderung nach einer fehlerrobusten Struktur der
Datenströme, für eine Vermittlung multimedialer Daten über verlustbehaftete
154
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Transportkanäle, vollständig erfüllt. MPEG4IP ermöglicht die Erstellung unabhängig
verteilbarer Datenströme für eine Multimediasequenz. Diese verteilbaren Datenströme
lieferten die grundlegende Datenstruktur und definierten die Art der Verteilbarkeit der
multimedialen Informationen für den implementierten „Multisource-Streaming-Ansatz“.
Nach der Wahl der geeigneten, verfügbaren Plattform, folgte die prototypische
Implementierung des spezifizierten Konzepts. Der implementierte Ansatz unterstützt die
Verteilung multimedialer Daten im hochdynamischen Netzwerk. Dabei wird der
Verteilungsprozess an die Verbindungseigenschaften angepasst, die zwischen den
potentiellen Dienstanbietern und dem Dienstnutzer bestehen. Ebenso haben die
verfügbaren Ressourcenkapazitäten der Dienstanbieter einen Einfluss auf den
Verteilungsprozess.
Die Ergebnisse verschiedener Experimente mit dem implementierten Prototyp zeigten,
dass die Verteilbarkeit von Datenströmen einer Multimediasequenz nicht nur möglich ist,
sondern dass mit dieser Verteilbarkeit der Lastenausgleich zwischen Dienstanbietern
realisiert werden konnte. Die Wiederverwendbarkeit der verteilten multimedialen Daten im
implementierten System erlaubt es, empfangene multimediale Elemente anderen
Dienstnutzern zur Verfügung zu stellen. Die Testergebnisse haben gezeigt, dass durch
dieses Verteilungsprinzip die Reichweite der Datenverteilung erhöht werden konnte. Durch
den neuen implementierten Verteilungsmechanismus können mit mehreren
Verteilerquellen kürzere Übertragungsstrecken realisiert werden, wodurch die
Fehlerhäufigkeit im Übertragungsprozess gesenkt werden kann. Diese Aussage wird durch
experimentell gewonnene Versuchsergebnisse unterstützt.
In dieser Arbeit konnte somit ein Konzept eines neuen Mechanismus für die Verteilung
multimedialer Daten in hochdynamischen Netzwerken entwickelt und prototypisch
implementiert werden.
155
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
10. Ausblick
Für die weitere Entwicklung des neuen Verteilungsmechanismus ist die Verfügbarkeit von
Encodern, Stream-Servern und Decodern, die skalierbar kodierte multimediale Daten
erzeugen, verteilen und darstellen können, von größter Bedeutung. Mit der Verwendung
eines Kodiersystems, dass die skalierbare Kodierung multimedialer Daten vollständig,
gemäß dem MPEG4-Standard unterstützt, kann die Verteilbarkeit der Elemente einer
Multimediasequenz bedeutend erweitert werden. Je unabhängiger der korrekte
Dekodiervorgang, mit Hilfe der Skalierbarkeit, von der Forderung nach dem vollständigen
Empfang der Elemente einer Multimediasequenz ist, umso fehlerrobuster ist der
Wiedergabeprozess und umso besser kann der Verteilungsprozess an die verfügbaren
Ressourcen des Netzwerkes und der Endgeräte angepasst werden.
Folgende,
teilweise
bereits
spezifizierte
Erweiterungen
Gesamtfunktionalität des implementierten Prototyps:
verbessern
die
Eine erweiterte Verteilbarkeit multimedialer Daten ist durch Aufteilung von
Datenelementen eines Elementarstroms auf mehrere Transportdatenströme möglich. Diese
Art der Datenverteilung erfordert jedoch den vollständigen Empfang aller
Transportdatenströme eines Elementarstroms, um einen korrekten Dekodiervorgang
garantieren zu können.
Durch die Implementierung von Routing-Mechanismen und mit der Möglichkeit,
optimierte dynamische Multicast-Bäume erstellen zu können, ist der Verteilungsprozess
kooperativer gestaltbar und kann besser an die Dynamik der Ressourcenverfügbarkeit
angepasst werden. Die Ermittlung der benachbarten Dienstanbieter ist somit für einen
Dienstnutzer nicht mehr fest definiert, sondern orientiert sich dynamisch an den
wechselnden Umgebungseigenschaften.
Der Einsatz eines geeigneten Scheduling-Verfahrens im Datenversandprozess verbessert
die Synchronitsation der Datenvermittlung mehrerer zusammengehöriger Elementarströme
von einer Quelle. Mit diesem Scheduling-Verfahren ist gleichzeitig eine vermehrte
Berücksichtigung der Zeitrelevanzen der zu vermittelnden Datenelemente erreichbar.
Somit kann auch dem Problem der Übertragung großer visueller Datenelemente
gegengesteuert werden. Bei der Übertragung solcher Datenelemente, die über mehrere
Transportdateneinheiten verteilt werden müssen, treten die häufigsten Datenverluste auf.
Die Transportdateneinheiten besitzen die gleiche Zeitrelevanz und müssen somit zum
gleichen Zeitpunkt übertragen werden. Für diesen Augenblick übersteigt die Datenrate die
verfügbare Transportkapazität des Netzwerks bzw. die CPU des Versenders kann den
Versandprozess nicht schnell genug abarbeiten.
156
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Die
stochastisch
wechselnden
Verbindungseigenschaften
zwischen
Kommunikationspartnern im Adhoc-Netzwerk sollten kontinuierlich überprüft werden. Mit
den protokollierten Informationen können Entscheidungen im Verbindungsmanagement
getroffen werden. So ist ein Umschalten von Verbindungen zwischen Dienstanbietern
während des Empfangs- und Darstellungsprozesses durch den Dienstnutzer denkbar.
Die Abschätzung der Verbindungseigenschaften mit Hilfe der Ermittlung der
Paketumlaufzeit und der Paketverlusthäufigkeit kann durch weitere Messgrößen, wie z.B.
die Jitterbestimmung, verbessert werden.
Ein ganzes Forschungsgebiet eröffnet die Untersuchung der Fehlererkennbarkeit, der
Fehlerkontrolle, der Einsatzmöglichkeiten von Fehlerabsicherungen durch Datenredundanz
und der Entwicklung von Reaktionsmechanismen auf entstandene Fehler für multimediale
Daten. Mit der Implementierung solcher Mechanismen kann die Darstellungsqualität der
verteilten Multimediasequenzen erheblich gesteigert werden.
11. Schlussbemerkung
Der prototypisch implementierte, neue Ansatz bietet die Grundlage für die Entwicklung
eines Gesamtsystems für die Verteilung multimedialer Daten in hochdynamischen
Netzwerken. Diese Basis ist mit neuen Funktionen und Ideen beliebig erweiterbar.
Für das kontinuierlich steigende Interesse an mobiler, multimedialer Kommunikation in
Netzwerken ohne Infrastruktur, beschreibt das entwickelte Konzept einen Vorschlag, der
einige der vorgestellten Probleme lösen kann.
157
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
12. Anhang
Anhang A
Geräteklasse
Übersicht über verfügbare mobile Endgeräte
Endgerät
Prozessorleistung
Displayeigenschaften
(Displayauflösung/Farbauflös
ung)
Speicherkapazität
Akkulaufzeit
Handy
Smart
Phone
Samsung 200 MHz
i600
PXA250
XScale
processor
Displayauflösung:
176x220 Pixel
Farbauflösung: 65k
Farben
32MB Flash ROM
32 MB SDRAM
Speichererweiterung
über SD- und MMCKarten
Betriebssystem /
Multimediafähigkeit
Netzwerkanbindung
Handys ohne
Betriebssystem
haben keine
Funktionen um
Multimediasequen
zen (Video)
abspielen zu
können
GSM,
GPRS,
Bluetooth
, HSCSD
BS: Microsoft
Windows Mobile
for Smartphone
OS 2002
GSM,
GPRS
Kopfhörer- und
Mikrofonanschluss
(stereo)
POP3, IMAP,
SMTP,WAP,
HTML, cHTML
über SDKarten
zusätzlic
h WLAN,
Bluetooth
, GPS
Windows Media
Player for
Smartphone
(Wiedergabe von
gespeicherten
oder gestreamten
WM9-kodierten
Multimediasequen
zen und MP3
Audio)
Orange
SPV
E200
GSM
Phone
132 MHz Ti
OMAP 710
processor
Displayauflösung:
176x220 Pixel
Farbauflösung: 65k
Farben
32MB Flash ROM
32 MB SDRAM
Speichererweiterung
über SD- und MMCKarten
BS: Microsoft
Windows Mobile
for Smartphone
OS 2003
GSM,
GPRS,
Bluetooth
Kamera zur
Aufnahme von
Videos mit einer
Aufl. von 352 x
288 oder 176 x
144 und Audio.
Video files werden
im AVI format
gespeichert
Kopfhörer- und
Mikrofonanschluss
(stereo)
POP3, IMAP,
SMTP,WAP2.0,
HTML4.0, CSS
über SDKarten
zusätzlic
h WLAN,
GPS
158
Diplomarbeit
Geräteklasse
Endgerät
Inv.Nr.: 2004-11-03/096/IN99/2253
Prozessorleistung
Nokia
7610
(Displayauflösung/Farbauflösung)
Speicherkapazität
Akkulaufzeit
Betriebssystem /
Netzwerkanbindung
Displayauflösung: 176x208
Pixel Farbauflösung: 65k
Farben
8MB für Daten
(Multimedia,
Telefonbuch,...)
Speichererweite
rung über SDund MMCKarten
BS:
GSM,
Betriebssystem:
GPRS,
Symbian OS 7.0s Bluetooth
RealPlayer:
OfflineWiedergabe und
Online-Streaming
von
Musikdateien(MP3
, AAC, RealAudio,
WAV) und
Videoclips(MPEG
4, H.263)
Akkulaufzeit:
Sprechzeit bis
zu 180 Minuten
VideokameraFunktion mit
Tonaufnahme und
4-fachem
Digitalzoom zum
Aufzeichnen von
bis zu 10 Minuten
langen Videoclips
(128x96 oder
176x144) in
MPEG4, H.263,
3GGP
Kopfhörer- und
Mikrofonanschluss
(stereo)
POP3, IMAP,
SMTP,WAP2.0,
HTML4.0, CSS
Nokia
7700
Farben
20-25MB für
Daten
(Multimedia,
Telefonbuch,...)
Speichererweite
RealPlayer:
OfflineWiedergabe und
Online-Streaming
von
Musikdateien(MP3
, AAC, RealAudio,
WAV) und
Videoclips(MPEG
4, H.263) UKW
Radio
Kopfhörer- und
Mikrofonanschluss
(stereo)
POP3, IMAP,
SMTP,WAP2.0,
HTML4.0, CSS
Akkulaufzeit:
Sprechzeit bis
zu 4 Stunden
Kamera zur
Aufnahme von
Videos mit einer
Aufl. von 640 x
480 und Audio.
Video files werden
in MPEG4 oder
H.263 gespeichert
GSM,
GPRS,
HSCSD,
Bluetooth
, DVB-H
159
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Geräteklasse
Endgerät
Prozessorleistung
Pocket PC
Phone
T-Mobile
Pocket
PC
Phone
Edition
StrongARM Displayauflösung: 240x320
206 MHz
processor
Farben
Speicherkapazität
Akkulaufzeit
Betriebssystem /
Netzwerkanbindung
32MB Flash
ROM 32 MB
SDRAM
Speichererweite
BS: Pocket PC
GSM,
2002 / Windows
GPRS
Mobile 2003
Kopfhörer- und
Mikrofonanschluss
(stereo)
Windows Media
Player
(Wiedergabe von
gespeicherten
oder gestreamten
WM9-kodierten
Multimediasequen
zen und MP3
Audio)
Pocket PC
PDA
Fujitsu
Siemens
Pocket
LOOX
610
BT/WLA
N
Toshiba
Pocket
PC e800
WiFi
XScaleProzessor
(PXA255)
mit 400
MHz
XScaleProzessor
(PXA263)
mit 400
MHz
Farben
Pixel aber Betriebssystem
unterstützt nur 240x320 Pixel
Farbauflösung: 65k Farben
64MB Flash
ROM 128 MB
SDRAM
Speichererweite
BS: Pocket PC
Bluetooth
2003 (Windows
, WLAN
Mobile 2003)
802.11b
Kopfhörer- und
Mikrofonanschluss
(stereo)
Akkulaufzeit:
224min (volle
Leistung)
126min (mit
WLAN)
Windows Media
Player
(Wiedergabe von
gespeicherten
oder gestreamten
WM9-kodierten
Multimediasequen
zen und MP3
Audio)
32MB Flash
ROM 128 MB
SDRAM
32MB NAND
Flash
Speichererweite
Akkulaufzeit:
223min (volle
Leistung)
119min (mit
WLAN)
BS: Pocket PC
WLAN
2003 (Windows
802.11b
Mobile 2003)
Kopfhörer- und
Mikrofonanschluss
(stereo)
Windows Media
Player
(Wiedergabe von
gespeicherten
oder gestreamten
WM9-kodierten
Multimediasequen
zen und MP3
Audio)
160
Diplomarbeit
Geräteklasse
Inv.Nr.: 2004-11-03/096/IN99/2253
Endgerät
Prozessorleistung
Speicherkapazität
Akkulaufzeit
Betriebssystem /
Netzwerk
JVC MPPV332
XScaleProzessor
(PXA255)
mit 400
MHz
Farben
32MB Flash ROM
128 MB SDRAM
Speichererweiteru
ng über SD- und
MMC-Karten
BS: Pocket PC
WLAN
2003 (Windows
802.11b
Mobile 2003)
Kopfhörer- und
Mikrofonanschluss
(stereo)
JVC eigener AV
Player unterstützt
das Abspielen von
MPEG4 (AVI,
AFS-Videofiles),
mp3, wav und ogg
komprimierte
audio Files.
Ermöglicht das
erstellen und
streamen von
MPEG4 video,
jedoch nur mit
kompatiblen JVC
Mini DV digital
Camcordern
Linux
PDA
Sharp
Zaurus
C760
XScaleProzessor
(PXA255)
mit 400
MHz
Pixel
Farbauflösung:
65k Farben
64MB System
SDRAM
128
MB Storage
SDRAM
Speichererweiteru
ng über SD- und
MMC-Karten
Linux-based
WLAN
operating system
802.11b
(OpenPDA)
Kopfhörer- und
Mikrofonanschluss
(stereo)
POP3, IMAP,
SMTP,WAP,
HTML, cHTML
Video Player
(MPEG4), Music
Player for MP3s,
Palm OS
PDA
Sony
Clié
model
UX50 &
UX40
Sony
CXD2330G
A ARM
family
processor
8-123MHz
Pixel
Farbauflösung:
65k Farben
8MB CPUinterner
Speicher
32MB DRAM
64MB NAND Flash
davon 16MB für
Programme und
29MB für
Multimediadaten
BS: Palm OS 5.2
WLAN
eine 320x240
802.11b
MPEG1 Sequenz Bluetooth
mit 15fps
abspielbar , MP3
Player Kopfhörerund
Mikrofonanschluss
(stereo)
POP3, IMAP,
SMTP,WAP2.0,
HTML4.0, CSS
Akkulaufzeit:
210min (volle
Leistung) 150min
(mit WLAN)
Kamera zur
Aufnahme von
Videos mit einer
Aufl. von 160 x
112 und Audio.
Videoformat
unbekannt(wahrsc
hnl. MPEG1)
161
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Geräteklasse
Endgerät
Prozessorleistung
Tablet PC
Acer
Pentium M
TravelMa Centrino
te
1600MHz
C302XMi
Speicher-kapazität
Akkulaufzeit
Betriebssystem /
Netzwerk
Pixel
Farbauflösung:
32bit True Color
512 MB RAM,
max. 2048MB
60GB Festplatte
Grafikkarte Intel
DVMT mit
64MB RAM
BS: Windows XP
Tablet PC Edition
oder GNU/LINUX
Software
Kodierung/Dekodi
erung aller
MultimediaFormate möglich,
Stereo
Lautsprecher und
Mikrofon, digit.
Ausgang für 5.1
Soundsysteme
WLAN
802.11b
Bluetooth
, 1Gbit
Ethernet,
56k V.92
Modem,
IEEE
1394
BS: Windows XP
Tablet PC Edition
Software
Kodierung/Dekodi
erung der meisten
Stereo
Lautsprecher und
Mikrofon
WLAN
802.11b
Bluetooth
, 100Mbit
Ethernet,
56k V.90
Modem,
IEEE
1394
BS: Windows XP
Professional
Software
Kodierung/Dekodi
erung der meisten
Stereo
Lautsprecher und
Mikrofon
WLAN
802.11g,
100Mbit
Ethernet,
56k V.92
Modem,
IEEE
1394
BS: Windows XP
Home / Media
Center / LINUX
Software
Kodierung/Dekodi
erung aller
Stereo
Lautsprecher und
Mikrofon
TV-Karte
WLAN
802.11g,
100Mbit
Ethernet,
56k V.92
Modem,
IEEE
1394
Akkulaufzeit:
7 Stunden
Ultra Low Pentium M
Voltage
933MHz
Mobile
Intel®
Pentium
® III
Processo
r
933MHz
Displayauflösung: 10.4" XGA
TFT 1024x768 Pixel
Farbauflösung: 32bit True
Color
256 MB RAM,
max. 768MB
60GB Festplatte
Grafikkarte Intel
830MG mit
48MB Shared
RAM
Akkulaufzeit:
4 Stunden, 3
Stunden mit
WLAN
Laptop
Sony
Vaio
VGNX505VP
Ultra Low
Voltage
Intel®
Pentium® M
Prozessor
mit 1,1 GHz
Displayauflösung: 10.4" XGA
TFT 1024x768 Pixel
Color
512 MB RAM,
max. 512MB
20GB Festplatte
Grafikkarte Intel
855GM mit
64MB Shared
RAM
Akkulaufzeit:
3 Stunden mit
WLAN
HP
ZD7000
Mobile Intel®
Pentium®
Prozessor
mit 3,4 GHz
Displayauflösung: 17.0" WVA
WSXGA+ BrightView
1680x1050 Pixel
Color
512 MB RAM,
max. 2,048GB
100GB
Festplatte
Grafikkarte
NVIDIA(R)
GeForce(TM)
FX Go5700 mit
128MB SDRAM
Akkulaufzeit:
1,5 Stunden mit
WLAN
162
Diplomarbeit
Anhang B
Inv.Nr.: 2004-11-03/096/IN99/2253
Überblick über MPEG2 Profile und Level
Level
Layer
High
Base
Simple
samples/line
1920
lines/frame
1152
frames/sec
-
bitrate
VbVBuffersize
Chroma Format
Base +
Enhancement 1
Main
60
Profile
SNR
Spatial
und SNR
960
576
-
-
25 Mbit/s
9,781 Mbit
3,047 Mbit
4:2:0
4:2:0
1920
1152
lines/frame
-
-
-
-
9,781 Mbit
VbVBuffersize
Chroma Format
4:2:0
samples/line
1920
Enhancement 1 +
lines/frame
Enhancement 2
frames/sec
1152
-
-
-
-
12,222 Mbit
VbVBuffersize
4:2:2
Chroma Format
Base
1440
samples/line
1152
lines/frame
frames/sec
-
bitrate
VbVBuffersize
Enhancement 1
720
720
576
576
30
30
60 Mbit/s
15 Mbit/s
20 Mbit/s
7,340 Mbit
1,835 Mbit
2,441 Mbit
60
-
4:2:0
4:2:0
Chroma Format
Base +
samples/line
1440
1440
lines/frame
1152
1152
frames/sec
-
-
-
bitrate
VbVBuffersize
30
60
40 Mbit/s
60 Mbit/s
4,882 Mbit
7,340 Mbit
4:2:0
Chroma Format
samples/line
1440
1440
Enhancement 1 +
lines/frame
1152
1152
Enhancement 2
frames/sec
Base +
-
-
-
bitrate
VbVBuffersize
30
60
60 Mbit/s
80 Mbit/s
7,340 Mbit
9,781 Mbit
4:2:2
Chroma Format
Main
60
100 Mbit/s
bitrate
High-1440
60
80 Mbit/s
bitrate
Base +
30
80 Mbit/s
samples/line
frames/sec
High
Base
720
720
720
lines/frame
576
576
576
frames/sec
30
30
30
15 Mbit/s
15 Mbit/s
10 Mbit/s
4 Mbit/s
1,835 Mbit
1,835 Mbit
1,212 Mbit
475,14 Kbit
4:2:0
4:2:0
4:2:0
4:2:0
bitrate
VbVBuffersize
Chroma Format
352
samples/line
288
-
30
163
Diplomarbeit
Level
Inv.Nr.: 2004-11-03/096/IN99/2253
Layer
Base +
Enhancement 1
Simple
Main
samples/line
720
lines/frame
576
frames/sec
-
-
bitrate
VbVBuffersize
Chroma Format
Base +
Profile
SNR
30
Spatial
und SNR
720
576
-
lines/frame
Enhancement 2
frames/sec
15 Mbit/s
1,835 Mbit
1,835 Mbit
4:2:0
4:2:0
720
576
-
-
-
-
2,441 Mbit
VbVBuffersize
4:2:2
Chroma Format
Base
samples/line
lines/frame
frames/sec
-
bitrate
VbVBuffersize
Chroma Format
Base +
Enhancement 1
352
352
288
288
30
30
4 Mbit/s
3 Mbit/s
475,14 Kbit
360,45 Mbit
4:2:0
4:2:0
-
-
-
-
-
288
lines/frame
-
-
30
4 Mbit/s
bitrate
475,14 Mbit
VbVBuffersize
4:2:0
Chroma Format
Base +
-
352
samples/line
frames/sec
30
20 Mbit/s
bitrate
Low
30
15 Mbit/s
samples/line
Enhancement 1 +
High
samples/line
Enhancement 1 +
lines/frame
Enhancement 2
frames/sec
-
-
-
bitrate
VbVBuffersize
Chroma Format
164
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Anhang C Optimale Einsatzmöglichkeiten für Fehlerverschleierungstechniken in MPEG2
Kategorie
Technik
Einsatzgebiete
Concealment
Temporal predictive concmt.
Substitution beschädigter,
bzw. verlorener Makroblöcke
durch Makroblöcke
benachbarter Bilder
In jedem Profil einsetzbar, gut geeignet für relativ
statische Videosequenzen (geringe Bewegung)
Abschätzung der
Bewegungsvektoren eines
beschädigten Bildes durch
Bewegungsvektoren
benachbarter Bilder.
In jedem Profil einsetzbar, verbesserte zeitliche
Fehlerverschleierung in Videosequenzen möglich, in
denen sich die Bildinhalte schnell verändern.
Concealment Motion Vector’s In jedem Profil einsetzbar, jedoch zusätzlicher
werden mit I-Picture kodiert
Overhead, höhere geforderte Rechenkapazitäten beim
und übertragen
Encoder und Decoder.
Spatial predictive
concealment
In jedem Profil einsetzbar, nicht gut geeignet für
statische Bilder mit hohen Kontrasten und vielen
verschiedenen
Bildelementen.
Gute
Einsatzmöglichkeit in Videosequenzen mit schnellen
Informations-veränderungen zwischen benachbarten
Bildern
verbesserte
Fehlerverschleierung durch
Data Partitioning
In keinem Profil benutzt, kann jedoch als Post-oder
Preprozessing eingesetzt werden. Gut geeignet bei der
Übertragung von Videosequenzen über verschieden
gestörte Kanäle.
Geringer Overhead und geringe zusätzliche geforderte
Rechenkapazität.
verbesserte
SNR Scalability
Einsatz in den Profilen SNR SCALABLE,
SPATIALLY SCALABLE, und HIGH. Gut geeignet
für
die
Übertragung
von
Daten
der
Erweiterungsschicht in einem Kanal mit hoher
Fehlerrate oder zwischenzeitlichem Ausfall bei
paralleler Übertragung von Daten der Basisschicht in
einem störsicheren, zuverlässigen Kanal. Relativ
einfach zu implementieren.
verbesserte
Spatial Scalability
Einsatz in den Profilen SNR SCALABLE,
SPATIALLY SCALABLE, und HIGH. Gut geeignet
für
die
Übertragung
von
Daten
der
einem störsicheren, zuverlässigen Kanal. Hohe
Komplexität bei der Implementierung, sehr
rechenintensiv.
165
Diplomarbeit
Kategorie
Spatial Localisation
Temporal Localisation
Inv.Nr.: 2004-11-03/096/IN99/2253
Technik
Einsatzgebiete
verbesserte
Temporal Scalability
Gut geeignet für die Übertragung von Daten der
einem störsicheren, zuverlässigen Kanal.
kleinere Slices
In
jedem
Profil
einsetzbar.
Schnellere
Resynchronisation des Decoders möglich, jedoch
zusätzlicher Overhead durch häufigere Übertragung
von Sliceheadern.
Adaptive Slicelängen
In jedem Profil einsetzbar, Informationen über die
Transfercharakteristiken erforderlich, um Slicelängen
und damit Paketgrößen definieren zu können.
zusätzliche I-Picture
In jedem Profil einsetzbar, I-Picture sind aufgrund der
großen Datenmenge selbst sehr fehleranfällig bei der
Übertragung
Intra slices
In jedem Profil einsetzbar, Intra Slice’s sind weniger
fehleranfällig als I-Picture, aufgetretene Fehler werden
jedoch eine längere Zeit weiterpropagiert (mind. ein
Intervall von P-Picture)
166
Diplomarbeit
Anhang D
Inv.Nr.: 2004-11-03/096/IN99/2253
Beispiel für die Binäre Kodierung eines MPEG4-IOD
Headerfeld
InitialObjectDeskriptor tag
Deskriptor size
ObjectDeskriptorID
URL_Flag
includeInlineProfilesFlag
Reserved
Wert
2
81
1
0
0
15
Binäre Kodierung
0000 0010
0101 0001
0000 0000 01
0
0
1111
ODProfileLevelIndication
255 1111 1111
sceneProfileLevelIndication
audioProfileLevelIndication
255 1111 1111
1 0000 0001
visualProfileLevelIndication
255 1111 1111
graphicsProfileLevelIndication
ES_Deskriptor OD-Stream
ES_Deskriptor tag
Deskriptor size
ES_ID
streamDependenceFlag
URL_Flag
OCRstreamFlag
streamPriority
DecoderConfigDeskriptor
OD-Stream
DecoderConfigDeskriptor tag
Deskriptor size
objectTypeIndication
streamType
upStream
Reserved
bufferSizeDB
255 1111 1111
maxBitrate
avgBitrate
SLConfigDeskriptor OD
Stream
SLConfigDeskriptor tag
Deskriptor size
3
34
1
0
0
0
32
4
15
1
1
0
1
3000
0000 0011
0010 0010
0000 0000 0000 0001
0
0
0
11111
0000 0100
0000 1111
0000 0001
0000 01
0
1
0000 0000 0000 1011 1011 1000
0000 0000 0000 0000 0000 0000
0000 0000
0000 0000 0000 0000 0000 0000
0000 0000
Kommentar
keinem definierten Profil
zuzuordnen
zuzuordnen
AAC-Main Profile/Level
zuzuordnen
zuzuordnen
höchste Priorität
Typ: Systems
Typ: OD-Stream
0 =variable Bitrate
0 =variable Bitrate
6 0000 0110
19 0001 0011
167
Diplomarbeit
Headerfeld
Predefined
Use Access Unit Start Flag
Use Access Unit End Flag
Use Random Access Point
Flag
has Random Access Unit
Only Flag
Use Padding Flag
Use TimeStamps Flag
Use Idle Flag
Duration Flag
Inv.Nr.: 2004-11-03/096/IN99/2253
Wert Binäre Kodierung
0 (2) 0000 0000
1 1
1 1
0
0
1
0
0
90000
OCR Resolution
TimeStamp Length
OCR Length
AU-Length
instant Bitrate Length
degradation Priority Length
AU-Seq-Length
packet Seq Length
Reserved
ES_Deskriptor BIFS
ES_Deskriptor tag
Deskriptor size
ES_ID
StreamDependenceFlag
URL_Flag
OCRstreamFlag
StreamPriority
DecoderConfigDeskriptor
BIFS
DecoderConfigDeskriptor tag
Deskriptor size
ObjectTypeIndication
90000
32
32
12
0
0
32
0
3
MaxBitrate
AvgBitrate
0=Benutzerdefinierter SLPaket-Header
2=SL-Paket-Header für
MP4-Files
0 0
TimeStamp Resolution
StreamType
Upstream
Reserved
BufferSizeDB
Kommentar
0
0
1
0
0
0000 0000 0000 0001 0101 1111
1001 0000
0000 0000 0000 0001 0101 1111
1001 0000
0010 0000
0010 0000
0000 1100
0000 0000
0000
0010 0000
0000 0000
11
90KHz
90KHz
3 0000 0011
38 0010 0110
0000 0010
0 0
0 0
0 0
32 11111
4 0000 0100
19 0001 0011
1 0000 0001
3
0
1
100
0000 11
0
1
0000 0000 0000 0000 0110 0100
0000 0000 0000 0000 0000 0000
0000 0000
0000 0000 0000 0000 0000 0000
0000 0000
System:BIFS-Config
Typ: Scene Description
Stream
0=variable Bitrate
0=variable Bitrate
168
Diplomarbeit
Headerfeld
Decoder Specific
Deskriptor (BIFSConfig)
Decoder Specific Deskriptor
Tag
Deskriptor size
Inv.Nr.: 2004-11-03/096/IN99/2253
Wert Binäre Kodierung
5 0000 0101
4 0000 0100
NodeIDbits
3 00011
RouteIDbits
IsCommandStream
PixelMetric
3 00011
1 1
1 1
HasSize
SLConfigDeskriptor BIFS
SLConfigDeskriptor tag
Deskriptor size
0 0
Predefined
Use Access Unit Start Flag
Use Access Unit End Flag
Use Random Access Point
Flag
has Random Access Unit
Only Flag
Use Padding Flag
Use TimeStamps Flag
Use Idle Flag
Duration Flag
3-bit zur Identifikation der
Node ID => max 8 Nodes
3-bit zur Identifikation der
Route ID => max 8 Routes
keine Größe für die Szene
definiert
6 0000 0110
19 0001 0010
0 (2) 0000 0000
1 1
1 1
0=Benutzerdefinierter SLPaket-Header
2=SL-Paket-Header für
MP4-Files
0 0
0
0
1
0
0
TimeStamp Resolution
90000
OCR Resolution
TimeStamp Length
OCR Length
AU-Length
instant Bitrate Length
degradation Priority Length
AU-Seq-Length
packet Seq Length
Reserved
90000
32
32
12
0
0
32
0
3
Kommentar
0
0
1
0
0
0000 0000 0000 0001 0101 1111
1001 0000
0000 0000 0000 0001 0101 1111
1001 0000
0010 0000
0010 0000
0000 1100
0000 0000
0000
0010 0000
0000 0000
11
90KHz
90KHz
169
Diplomarbeit
Anhang E
Inv.Nr.: 2004-11-03/096/IN99/2253
DMIF-Funktionalität
170
Diplomarbeit
Anhang F
Inv.Nr.: 2004-11-03/096/IN99/2253
Beispiel einer vollständigen SDP-Präsentationsbeschreibung
Beschrieben wird eine Multimediasequenz, die nach dem MPEG4-System-Standard
kodiert wurde. Sie besteht aus zwei Elementarströmen. Das benutzerdefinierte Attribut
„a=mpeg4-iod“ definiert den Objekt-Deskriptor und die Szenenbeschreibung für die
MPEG4-Sequenz. Diese Information ist im Format BASE64 kodiert. Die Definition des
BASE64 Formats wird in [6] und [7] erläutert.
Die erste Media Level Description beschreibt einen Video-Elementarstrom. Der VideoElementarstrom ist im „Simple-Profile“ des MPEG4-Standards kodiert. Der Parameter
„Config“ im Attribut „a=fmtp“ in der Media Level Description des Video-Elementarstroms
171
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
enthält Konfigurationsinformationen für den Videodecoder (Sequenz-Header, VO-Header,
VOP-Header).
Die zweite Media Level Description beschreibt einen Audio-Elementarstrom. Dieser
Elementarstrom ist MPEG4-AAC-kodiert.
Beide Elementarströme werden mit Hilfe des Transportprotokolls RTP übertragen.
172
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
13. Literaturverzeichnis
[1]
RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
[2]
RFC 3551 - RTP Profile for Audio and Video Conferences with Minimal Control
[3]
RFC 2326 - Real Time Streaming Protocol (RTSP)
[4]
RFC 2327 - SDP: Session Description Protocol
[5]
RFC 2279 - UTF-8, a transformation format of ISO 10646
[6]
RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
for Specifying and Describing the Format of Internet Message Bodies (S. 21)
[7]
RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies (S. 24)
[8]
RFC 2250 - RTP Payload Format for MPEG1/MPEG2 Video
[9]
RFC 3119 - A More Loss-Tolerant RTP Payload Format for MP3 Audio
[10]
RFC 3640 - RTP Payload Format for Transport of MPEG-4 Elementary Streams
[11]
RFC 3016 - RTP Payload Format for MPEG-4 Audio/Visual Streams
[12]
FKT „Fachzeitschrift für Fernsehen, Film und elektronische Medien“ 58.Jahrgang /
Ausgabe 5/2004 ISSN 1430-9947 Fachverlag Schiele & Schön GmbH Berlin
[13]
MPEG Video Compression Standard Joan L. Mitchel, William B. Pennebaker,
Chad E. Fogg, Didier J. LeGall 1997 Verleger: Chapman & Hall
[14]
MPEG2 John Watkinson 1999 ISBN: 0 240 51510 2 Verleger: Focal Press
[15]
IEEE J.Langham Thompson Prize / Electronics and Communication Engineering
Journal 1995
[16]
MPEG2-Standard Paper ISO/IEC 13818-2 Draft International Standard März 1994
[17]
The MPEG4 Book / Fernando Pereira und Touradj Ebrahimi / Verlag IMSC Press
Multimedia Series 2002
[18]
http://www.rhrk.uni-kl.de/MML/Anleitung/helix.unicasting.html
[19]
www.microsoft.com/windows2000/ en/server/help/ns_glossary_epcb.htm
[20]
www.microsoft.com/windows/ windowsmedia/technologies/services.aspx
[21]
http://developer.apple.com/darwin/projects/streaming/
[22]
http://developer.apple.com/darwin/projects/streaming/faq.html / Question: “What is
the Reflector, and how does it work?”
173
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
[23]
http://developer.apple.com/documentation/Darwin/Darwin.html
[24]
http://www.divx.com
[25]
http://www.xvid.org
[26]
http://www.doom9.org
[27]
http://www.mpegable.com
[28]
http://www.iis.fraunhofer.de/amm
[29]
http://sourceforge.net/projects/mpeg4ip/
[30]
ISO/IEC 11721-1:1991 (MPEG1-Systems)
[31]
ISO/IEC 11721-2:1991 (MPEG1-Visual)
[32]
ISO/IEC 11721-3:1991 (MPEG1-Audio)
[33]
ISO/IEC 13818-1:1994 Document N0801 (MPEG2-Systems)
[34]
ISO/IEC 13818-2:1995 (E) (MPEG2-Visual)
[35]
ISO/IEC 13818-3:1994 (MPEG2-Audio)
[36]
ISO/IEC 14496-1:2002 Document N4848 (MPEG4-Systems)
[37]
ISO/IEC 14496-2:2003 Document N5546 (MPEG4-Visual)
[38]
ISO/IEC 14496-3:2001 Document W3995 Subpart 1 (MPEG4-Audio)
[39]
ISO/IEC 14496-3:2001 Document W3995 Subpart 4 (MPEG4 - General Audio
Coding)
[40]
ISO/IEC 14496-8 FDIS Document N4427 (14496-Content over IP-Networks)
[41]
ISO/IEC 14496-10:2000 (E) Document W3713 (MPEG4-DMIF)
[42]
ISO/IEC 14496-14 FDIS :2003 Document W5298 (MP4-File Format)
[43]
Internet Streaming Media Alliance Implementation Specification Version 1.0 + 1.1
Corrigenda June 3, 2004 / www.isma.tv
174
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
14. Abkürzungen
AAC
Advanced Audio Coding
AAC-LC
Advanced Audio Coding – Low Complexity
ADPCM
Adaptive Differential Pulse Code Modulation
ARQ
Automatic Repeat on reQuest
AU
Access Unit
BAB
Binary Alpha Block
BSAC
Bit Sliced Arithmetic Coding
CAE
Context specific Arithmetic Encoding
CAT
Channel Association Tag
CCITT
Comitée Consultativ International Télégraphique et Telephonique
CELP
Code Excited Linear Prediction
CIF
Common Intermediat Format
CRC
Cyclic Redundancy Check
CTS
Composition Timestamp
DAI
Delivery Application Interface
DMIF
Delivery Multimedia Integration Framework
DNI
DMIF Network Interface
DPCM
Differential Pulse Code Modulation
DTS
Decoding Timestamp
EP
Error Protection
ES
Elementary Stream
ESC
Error Sensitivity Categories
ESD
Elementary Stream Deskriptor
FEC
Forward Error Correction
FGS
Fine Granularity Scalability
FIFO
First-in First-out
FTP
File Transfer Protocol
GOV
Group of Visual Object Planes
175
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
HCR
Huffman Codewort Reordering
HDTV
High Definition Television
HEC
Header Extension Code
HILN
Harmonic and Individual Lines and Noise
HVXC
Harmonic Vector Excitation Coding
IOD
Initial Objekt-Deskriptor
IPMP
Interoperable Protection of Multimedia Content
ITU
International Telecommunication Union
LSB
Lowest Significant Bit
MPEG
Moving Picture Expert Group
MSB
Most Significant Bit
OCI
Object Content Information
OCR
Object Clock Reference
OD
Objekt-Deskriptor
PCM
Pulse Code Modulation
PCR
Program Clock Reference
PES
Packetized Elementary Stream
PS
Programmstrom (MPEG2)
PTS
Presentation Timestamp
QCIF
Quarter Common Intermediat Format
RTP
Realtime Transmission Protocol
RTSP
Realtime Specification Protocol
RTT
Round Trip Time
RVLC
Reverse Variable Length Coding
SC
Synchronisation Layer
SCR
System Clock Reference
SDP
Stream Description Protocol
SLD
Session Level Description
SNR
Signal to Noise Ratio
SQCIF
Sub Quarter Common Intermediat Format
TAT
Transmux Association Tag
176
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
TCP
Transport Control Protocol
TRANSMUX
Transport Multiplexer
TS
Transportstrom (MPEG2)
TwinVQ
Transform Domain Weighted Interleave Vector Quantization
UDP
User Datagram Protocol
UEP
Unequal Error Protection
URL
Uniform Resource Locator
VLC
Variable Length Coding
VO
Visual Object
VOL
Visual Object Layer
VOP
Visual Object Plane
VOS
Visual Object Sequence
177
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
Thesen
1. Durch die skalierbare Kodierung multimedialer Daten ist eine flexible Anpassung von
Multimediasequenzen für die Übertragung in hochdynamischen Netzwerken mit
heterogenen Netzwerkknoten möglich, ohne eine Transkodierung der Multimediadaten
vornehmen zu müssen.
2. Skalierbar kodierte Multimediasequenzen lassen sich fehlerrobust, in Form von
mehreren, unabhängig übertragbaren Datenströmen im Netzwerk verteilen und beim
Dienstnutzer mit einer empfangenen Teilmenge der verteilten Datenströme korrekt
darstellen.
3. Der MPEG4-Standard erfüllt alle Anforderungen an ein geeignetes Kodierverfahren für
die Verteilung multimedialer Daten in hochdynamischen Netzwerken mit heterogenen
Endgeräten. MPEG4 ist deshalb als Kodierverfahren für den Einsatz im neuen
Multisource-Streaming-Ansatz auszuwählen.
4. Für die vollständige Realisierbarkeit des neuen Multisource-Streaming-Ansatzes wird
ein Gesamtsystem gefordert, dass skalierbar kodierte multimediale Daten bereitstellen
und wiedergeben kann. Es existieren jedoch aktuell keine Encoder, keine StreamServer und keine Decoder, die diese Anforderung erfüllen können.
5. Der neue Multisource-Streaming-Ansatz erlaubt einen kooperativen Verteilungsprozess
für multimediale Daten, sodass die entstehende Gesamtlast für die Bereitstellung und
die Auslieferung der Daten auf mehrere Netzwerkknoten verteilt wird.
6. Mit dem neu entwickelten Verteilungskonzept kann die Reichweite für die
Datenvermittlung durch Verkettung mehrerer Verteilerquellen vergrößert werden.
7. Mit dem Multisource-Streaming-Ansatz ist es möglich, Verbindungsabbrüche in einem
definierten Zeitraum vor dem Wiedergabeprozess zu verstecken, in dem in diesem
Zeitraum eine neue Verbindung zu einem anderen Diensterbringer aufgebaut wird.
8. Um auf Übertragungsfehler im hochdynamischen Netzwerk mit verlustbehafteten
Transportkanälen reagieren zu können, ist ein Puffer an jeder Verteilerquelle des
Netzwerks erforderlich. Mit diesem Puffer müssen Jitter ausgeglichen und die
eintreffenden Daten sortiert werden.
9. Durch das Zwischenspeichern der multimedialen Daten an jeder Verteilerquelle sowie
durch den Verteilungsprozess akkumulieren sich Verzögerungszeiten, sodass die
Aktualität der verteilten Multimediasequenz mit zunehmender Entfernung von ihrem
Ursprung immer weiter abnimmt.
179
Diplomarbeit
Inv.Nr.: 2004-11-03/096/IN99/2253
10. Mit der Verkettung von mehreren Verteilerquellen können kürzere Punkt-zu-PunktVerbindungen im Netzwerk realisiert werden, wodurch die Fehlerhäufigkeit gesenkt
werden kann. Da die Stärke von Funksignalen quadratisch mit zunehmender
Entfernung abnimmt, ist die Fehlerhäufigkeit bei kurzen Punkt-zu-Punkt-Verbindungen
geringer als bei langen Verbindungswegen.
11. Bei der Übertragung großer visueller Datenelemente, die über mehrere
Transportdateneinheiten verteilt wurden, treten die häufigsten Datenverluste auf. Die
Transportdateneinheiten besitzen die gleiche Zeitrelevanz und müssen somit zum
gleichen Zeitpunkt übertragen werden. Für diesen Augenblick übersteigt die Datenrate
die verfügbare Transportkapazität des Netzwerks bzw. die CPU des Versenders kann
den Versandprozess nicht schnell genug abarbeiten.
_____________________
__________________
_____________________
Ort
Datum
Unterschrift
180
Eidesstattliche Erklärung
Ich versichere an Eides statt, die von mir vorgelegte Arbeit selbständig verfasst zu haben.
Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht veröffentlichten
Arbeiten Anderer entnommen sind, habe ich kenntlich gemacht. Sämtliche Quellen und
Hilfsmittel, die ich für die Arbeit benutzt habe, sind angegeben. Die Arbeit hat mit
gleichem Inhalt bzw. in wesentlichen Teilen noch keiner anderen Prüfungsbehörde
vorgelegen.
_____________________
__________________
_____________________
Ort
Datum
Unterschrift

Paper

Transcription

Similar documents

Nachrichten - LGLN

Newsletter zum Downloaden

Multimediatechnik / Audio

Sichtbare und unsichtbare digitale Visual Effects im

Interaktives Streaming von hochaufgelösten 360°

2 Ziele dieser Arbeit

Dokument_36.

Permanentmagnetische Lager

instruction manual

Verbreitete Inhaltstypen Übersicht