Diplomarbeit

Transcription

Diplomarbeit

Fachhochschule München
Munich University of Applied Sciences
Fachbereich Elektrotechnik | Datentechnik
Abteilung Audiosystemtechnik
Diplomarbeit
Webcasting:
Untersuchungen zur Qualität, Komplexität und Eignung
moderner Videokompressionsverfahren für Video@Internet
Betreuer (FHM): ...........Prof. Dr. Konrad Walliser
Betreuer (IRT): .............Dipl.-Ing. Gerhard Stoll,
Dipl.-Phys. Philip Mackensen, M.A.
Verfasser: ....................Martin Schmalohr
Beginn:.........................01. Juli 2000
Abgabe:........................02. Februar 2001
Laufende Nummer:.......1626
Fachhochschule München
Fachbereich Elektrotechnik
Diplomarbeit
Abgabetermin:
02.01.2001
Betreuer:
Diplomand:
Studiengruppe:
Prof. Dr. K. Walliser
Martin Schmalohr
04EL8DW
Thema:
Untersuchungen zur Qualität, Komplexität und Eignung moderner
Videokompressionsverfahren für Video@Internet
Kurzfassung:
Im Hinblick auf Broadcasting im Internet (Webcasting) werden Videoübertragungen in weltweiten Netzen immer wichtiger. Diese Arbeit gibt
einen Überblick über alle derzeit und in naher Zukunft für das Internet
verfügbaren Videokompressionsverfahren. Eingangs wird die Komplexität der verwendeten Algorithmen analysiert. Verfügbare Implementierungen werden bezüglich ihrer Bildqualität bei unterschiedlichen Netzwerkeigenschaften und bei gestörter Übertragung untersucht. Als Netzzugänge kommen beispielsweise das analoge Modem und ein ISDNoder ADSL-Anschluß zum Einsatz. Auch Unterschiede in der Rechenintensität in Produktion und Benutzung wurde untersucht.
Dazu wurde ein interaktives HTML-basiertes Testsystem entwickelt, mit
dem ein Benutzer einen individuellen Vergleich der Videosysteme selbst
durchführen kann.
Mittels dieses Testsystems konnte gezeigt werden, daß gegenwärtig
verfügbare Verfahren bereits dafür geeignet sind, bewegte Bilder über
digitale Netzwerke zu übertragen. Mit dem Ausbau der Bandbreiten und
einer Modernisierung der Netzwerktechnologien werden in naher Zukunft qualitativ hochwertige Videoübertragungen, interaktive Unterhaltung und aktive Programmgestaltung möglich.
Inhaltsverzeichnis
INHALT
ABBILDUNGEN
TABELLEN
1 EINLEITUNG
2 PRINZIPIEN DER MEDIENKODIERUNG- UND VERBREITUNG
2.1
2.2
2.2.1
2.2.2
2.3
2.4
2.4.1
2.4.2
GRUNDLAGEN .............................................................................................................................................. 2
DIGITALE VERARBEITUNG BEWEGTER BILDER ....................................................................................... 3
GENERIERUNG VON DIGITALEN BILDDATEN ..............................................................................................3
DIGITALE SPEICHERUNG VON BILDFOLGEN ...............................................................................................4
DIGITALE ÜBERTRAGUNG VON MULTIMEDIAINHALTEN ......................................................................... 4
VERFAHREN ZUR DATENREDUKTION ........................................................................................................ 6
REDUNDANZREDUKTION.............................................................................................................................6
IRRELEVANZREDUKTION .............................................................................................................................7
3 DARSTELLUNG VON VIDEOKOMPRESSIONSALGORITHMEN
3.1 INFORMATION UND KODIERUNG................................................................................................................ 8
3.1.1 ENTROPIEKODIERUNG .................................................................................................................................8
3.1.2 TRANSFORMATIONSKODIERUNG .................................................................................................................9
3.2 KOMPRESSION STEHENDER BILDER .......................................................................................................... 9
3.2.1 VEKTORQUANTISIERUNG ..........................................................................................................................10
3.2.2 DISKRETE KOSINUSTRANSFORMATION.....................................................................................................10
3.2.3 DISKRETE WAVELETTRANSFORMATION ...................................................................................................11
3.2.4 KONTURBASIERTE BILDKODIERUNG ........................................................................................................11
3.3 KOMPRESSION BEWEGTER BILDER ......................................................................................................... 12
3.3.1 FRAMEDIFFERENZIERUNG .........................................................................................................................12
3.3.2 BEWEGUNGSKOMPENSATION ....................................................................................................................12
3.3.3 FRAMETYPEN ............................................................................................................................................13
3.3.4 ARTEFAKTE ...............................................................................................................................................14
4 ANALYSE DER KOMPLEXITÄT VERSCHIEDENER VERFAHREN
4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.4
CAPTURING ................................................................................................................................................ 18
CODECS ...................................................................................................................................................... 19
MULTIMEDIA-ARCHITEKTUREN .............................................................................................................. 20
REAL VIDEO ..............................................................................................................................................20
APPLE QUICKTIME ....................................................................................................................................21
WINDOWS MEDIA TECHNOLOGIES ...........................................................................................................22
DIRECT SHOW ...........................................................................................................................................22
VIDEO FOR WINDOWS ...............................................................................................................................23
ANDERE ARCHITEKTUREN ........................................................................................................................23
DATEIFORMATE ........................................................................................................................................ 23
5 ÜBERSICHT VERFÜGBARER IMPLEMENTIERUNGEN
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.8.1
5.8.2
5.8.3
5.9
UNKOMPRIMIERTES VIDEO ...................................................................................................................... 25
LAUFLÄNGENKODIERUNG ........................................................................................................................ 26
CINEPAK .................................................................................................................................................... 26
INDEO ......................................................................................................................................................... 26
INDEO INTERACTIVE ................................................................................................................................. 27
H.261.......................................................................................................................................................... 27
H.263.......................................................................................................................................................... 27
MPEG........................................................................................................................................................ 28
MPEG 1 ....................................................................................................................................................28
MPEG 2 ....................................................................................................................................................28
MPEG 4 ....................................................................................................................................................29
DIVX........................................................................................................................................................... 30
-i-
Inhaltsverzeichnis
5.10
5.11
5.12
5.13
5.14
5.15
5.16
REALVIDEO G2 ......................................................................................................................................... 30
SORENSON VIDEO...................................................................................................................................... 31
APPLE VIDEO ............................................................................................................................................. 32
VDOWAVE ................................................................................................................................................ 32
ESCAPE VIDEOSTUDIO .............................................................................................................................. 33
CLEARVIDEO ............................................................................................................................................. 33
ANDERE CODECS ....................................................................................................................................... 33
6 EIGENSCHAFTEN AKTUELLER NETZWERKTECHNOLOGIEN
6.1
6.1.1
6.1.2
6.2
6.3
6.4
6.5
6.5.1
6.5.2
6.5.3
6.5.4
DAS OSI-REFERENZMODELL ................................................................................................................... 34
ANWENDUNGSSCHICHTEN ........................................................................................................................34
TRANSPORTSCHICHTEN.............................................................................................................................34
VERFÜGBARE ÜBERTRAGUNGSTECHNIKEN ............................................................................................ 35
AUSGEWÄHLTE ÜBERTRAGUNGSPROTOKOLLE ..................................................................................... 36
NETZWERKE UND MULTIMEDIA .............................................................................................................. 38
WEBCASTING TECHNOLOGIEN ................................................................................................................ 38
TRANSFER .................................................................................................................................................39
STREAMING ...............................................................................................................................................39
UNICAST ....................................................................................................................................................40
MULTICAST ...............................................................................................................................................40
7 UNTERSUCHUNG DER BILDQUALITÄT BEI UNTERSCHIEDLICHEN NETZZUGÄNGEN
7.1 VIDEO INTERNET DEMONSTRATION AID ................................................................................................ 42
7.2 REALISIERUNG .......................................................................................................................................... 43
7.2.1 QUELLENMATERIAL ..................................................................................................................................43
7.2.2 PARAMETERPROFILE .................................................................................................................................44
7.2.3 DESIGN ......................................................................................................................................................45
7.2.4 KOMPONENTEN .........................................................................................................................................46
7.2.5 SEQUENZKODIERUNG ................................................................................................................................47
7.3 BENUTZUNG ............................................................................................................................................... 48
7.3.1 INSTALLATION ..........................................................................................................................................48
7.3.2 NETZWERKEIGENSCHAFTEN .....................................................................................................................48
7.3.3 SEQUENZTABELLE .....................................................................................................................................49
7.3.4 INFORMATIONEN .......................................................................................................................................49
7.3.5 BITRATENDIAGRAMM ...............................................................................................................................51
8 UNTERSUCHUNG DER RECHENINTENSITÄT AUSGEWÄHLTER VERFAHREN
8.1 SERVERSEITIGE ENKODIERUNG............................................................................................................... 52
8.1.1 ISDN .........................................................................................................................................................53
8.1.2 DSL...........................................................................................................................................................53
8.1.3 LAN ..........................................................................................................................................................54
8.1.4 LIVEBETRIEB .............................................................................................................................................54
8.2 CLIENTSEITIGE DEKODIERUNG ............................................................................................................... 56
9 AUSWIRKUNGEN EINER GESTÖRTEN ÜBERTRAGUNG
9.1
9.2
9.3
MÖGLICHE URSACHEN VON ÜBERTRAGUNGSFEHLERN ........................................................................ 57
AUSWIRKUNG AUF DIE BILD- UND TONÜBERTRAGUNG ......................................................................... 57
KOMPENSATIONSMÖGLICHKEITEN ......................................................................................................... 58
10 ZUSAMMENFASSUNG
11 AUSBLICK
LITERATURVERZEICHNIS
QUELLENVERZEICHNIS
ABKÜRZUNGSVERZEICHNIS
- ii -
Abbildungen & Tabellen
ABBILDUNGEN
ABBILDUNG 1: NETZWERKE & VIDEOSTANDARDS, TYPISCHE DATENRATEN ....................................... 5
ABBILDUNG 2: KOMPRESSIONSARTEN .................................................................................................. 6
ABBILDUNG 3: KOMPRESSION UND KODIERUNG .................................................................................. 8
ABBILDUNG 4: VIDEOKOMPRESSIONSALGORITHMEN, ÜBERSICHT ..................................................... 10
ABBILDUNG 5: NETZWERK BROADCASTING, ABLAUF ........................................................................ 18
ABBILDUNG 6: MULTIMEDIA ARCHITEKTUREN & CODECS, STRUKTUR ............................................. 19
ABBILDUNG 7: VIDA, DESIGNSPEZIFIKATION ................................................................................... 45
ABBILDUNG 8: SELEKTION, NETZWERKPROFIL .................................................................................. 48
ABBILDUNG 9: DEMONSTRATOR, SEQUENZTABELLE .......................................................................... 49
ABBILDUNG 10: SEQUENZTABELLE, KODIERUNGSPARAMETER .......................................................... 50
ABBILDUNG 11: BITRATENDIAGRAMM, ERLÄUTERUNG ..................................................................... 51
ABBILDUNG 12: DAUER DER ENKODIERUNG VON 8 SEKUNDEN NTSC VIDEO FÜR ISDN AUF
EINEM PIII-500 WINDOWS98 SYSTEM ..................................................................... 53
ABBILDUNG 13: DAUER DER ENKODIERUNG VON 8 SEKUNDEN NTSC VIDEO FÜR DSL AUF
ABBILDUNG 14: DAUER DER ENKODIERUNG VON 8 SEKUNDEN NTSC VIDEO FÜR LAN AUF
ABBILDUNG 15: CPU-AUSLASTUNG EINER LIVEENKODIERUNG VON PAL VIDEO AUF EINEM
DUAL PIII-866 WINDOWS2000 SYSTEM ................................................................... 55
ABBILDUNG 16: CPU-AUSLASTUNG BEIM ABSPIELEN VON NTSC VIDEO AUF EINEM PIII-800
WINDOWS2000 SYSTEM ........................................................................................... 56
TABELLEN
TABELLE 1: TRANSFORMATIONEN UND ARTEFAKTE .......................................................................... 14
TABELLE 2: ARTEFAKTE (I)................................................................................................................ 15
TABELLE 3: ARTEFAKTE (II)............................................................................................................... 16
TABELLE 4: ARTEFAKTE (III) ............................................................................................................. 16
TABELLE 5: ARTEFAKTE (IV) ............................................................................................................. 17
TABELLE 6 : CODECÜBERBLICK, MERKMALE..................................................................................... 25
TABELLE 7: TESTSEQUENZEN, AUSWAHL........................................................................................... 52
TABELLE 8: PLAYERKONFIGURATION, PUFFERUNG ............................................................................ 58
- iii -
Einleitung
1
Grundlagen
EINLEITUNG
Die Kommunikation über Netzwerke weitet sich ständig aus. Überall in den Industrienationen werden „Informations-Autobahnen” installiert. Mit neuen Technologien wird eine Infrastruktur
geschaffen, die drei bisher getrennte Entwicklungsgebiete zusammenwachsen läßt. Die Kombination von Informationstechnologie, Unterhaltungstechnologie und Kommunikationstechnologie ergibt
neue Möglichkeiten der Verarbeitung, Verbreitung und Auswertung von Informationen. Ein erstes
Beispiele hierfür ist das interaktive Fernsehen via Digital Video Broadcasting (DVB), das eine
individuelle Nachrichtenauswahl sowie flexible Informationsdarstellung ermöglicht. Das visuelle
Telefon per Integrated Services Digital Network (ISDN) und Video on Demand Services über das
Internet sind weitere Beispiele. Möglich geworden sind diese Anwendungen durch eine effektievere, auf Kompression beruhende, platzsparende Übertragung von Daten.
Vergängliche Medien
Durch eine Digitalisierung der Archivbestände sowie durch die Umstellung von Radio und
Fernsehproduktion auf EDV-Technik stellen die politisch Verantwortlichen der öffentlich-rechtlichen
Anstalten die Weichen für den digitalen Rundfunk. Der Auslöser für die aufwendigen Umstellungen, die derzeit hinter den Kulissen der Sender stattfinden, war allerdings nicht der Wunsch nach
zusätzlichen Vermarktungsmöglichkeiten, sondern die Bewahrung der Bestände in den Archiven.
Bis Anfang der neunziger Jahre wurden die Medienbestände nach einer bestimmten Lagerzeit auf
neue Datenträger umkopiert. Bei analogen Medien geht damit stets ein Qualitätsverlust einher. Für
die Lagerung der Filmbestände ist zudem eine kostenaufwendige Klimatisierung notwendig. In der
1992 gegründeten Arbeitsgruppe "Sicherung der Archivbestände" fanden die technischen Leiter
der ARD-Anstalten mit der Umstellung auf digitale Medien einen dauerhaften, ewigen Bild- und
Tonträger. Eine Expertise vom Institut für Rundfunktechnik IRT [14] führte zu der Erkenntnis, daß
die qualitative Beschaffenheit von analogen wie digitalen Aufzeichnungsmedien in der Praxis
lediglich durch Stichprobenkontrollen beurteilt werden kann. Da es letztlich auch gar nicht auf die
Bewahrung der Medien selbst, sondern auf den Erhalt der darauf befindlichen Inhalte ankommt,
nahm man von der medienorientierten Archivierung Abstand. Eine gedanklichen Trennung von
Medien und deren Inhalten erforderte die Anschaffung hinreichend großer Speichersysteme. Die
Archivsicherung erfolgte ab nun unabhängig von der zu Grunde liegenden Hardware. Im Vergleich
zur klassischen Archiv- und Produktionstechnik stellte sich diese Lösung auch noch als unerwartet
preiswert heraus.
Digitale Produktion
Bei einem Archiv in EDV-Technik wird jeder Mitarbeiter mit einer vernetzten Workstation ausgestattet, die Bandmaschinen und Mischpulte ersetzt. Das ausgeweitete Transportnetz zwischen
Sendegebäuden und Studios ermöglicht ein computerbasiertes Recherche-System, über das der
aktuelle Bestand jederzeit abgefragt werden kann. Da der direkte Zugriff auf Audio oder Videoinhalte allerdings noch technische Probleme verursacht, müssen diese per Hauspost oder über
konventionelle Audio- und Videoleitungen geschickt werden. Damit sind sie in dieser Zeit für andere nicht verfügbar. Der Produktionsprozess inclusive Sichtung, Kopieren und Schnitt des Materials kann, besonders bei Fernsehbeiträgen, eine gute Woche dauern. Im vernetzten Funkhaus der
Zukunft bekommt man jedoch das Material direkt an den Arbeitsplatz überspielt. Man arbeitet stets
mit Kopien, das Originalmaterial bleibt stehts unangetastet und ist nach sehr kurzer Zeit bereits
-1-
Prinzipien der Medienkodierung- und verbreitung
Grundlagen
von anderen Kollegen abrufbar. Zudem besteht die Möglichkeit, während der Aufzeichnung bereits
mit dem Material zu arbeiten. (vgl. [1])
Webcasting
Distribution von Audio- und Videoinhalten geschieht heute noch größtenteils über klassische
Speichermedien und Rundfunk. Für diese existieren allgemein anerkannte Qualitätsstandards
sowie entsprechende technische und kommerzielle Strukturen. Neu hinzugekommen ist seit einiger Zeit das Internet. Als weltumspannendes Medium ist es für die Verbreitung von angeforderten1
oder Live-Inhalten prädestiniert. Bis vor kurzem war es für eingeschränkte Anwendungen wie
Nachrichten und Musikaustausch mit begrenzter Qualität geeignet. Größere Bandbreite und
schnellerer Zugang im Integrated Services Digital Network (ISDN) oder mit Digital Subscriber Line
(DSL) einerseits und die Verwendung optimierter, skalierbarer Audio- und Videokodierverfahren
andererseits sollen schon in naher Zukunft eine verbesserte Qualität ermöglichen. Um neue Hörer
zu gewinnen, ist es für den Rundfunk ein Muss auch im Internet mit neuen Technologien, interaktiven Gestaltungsmöglichkeiten und multimedialer Darstellung präsent zu sein. In dieser Arbeit
werden daher im Rahmen der Webcastingaktivitäten der European Broadcasting Union (EBU)
Möglichkeiten für eine optimale Videoübertragung im weltweiten Netz untersucht. Mit neuen Kompressions und Übertragungstechniken können mittlerweile bei Bitraten um 300 Kilobit pro Sekunde
Qualitäten erreicht werden, die an das weit verbreitete Video Home System (VHS) heranreichen.
Der permanente Ausbau von Netzkapazitäten scheint schon in naher Zukunft eine Videoübertragung von Ereignissen im Web in ausreichender Qualität zu ermöglichen. (vgl.[1])
Mensch und Technik
Für die notwendige Komprimierung stehen mittlerweile verschiedenste Verfahren zur Verfügung, die den Vorteil einer geringeren Datenrate und den Nachteil einer wahrnehmbaren
Veränderung des Bildes mit sich bringen. Allzu häufig werden diese Verfahren von den Produzenten verabscheut, da das aufwendig produzierte Material erheblich an Qualität verliert. Es darf
jedoch nicht außer Acht bleiben, daß auch jedes analog ausgestrahlte Signal zahlreiche Bandbreitenbegrenzungen und Umwandlungen durchläuft. Diese auf dem Transportweg zum Endverbraucher entstehenden Auswirkungen sind in der Praxis häufig denen einer digitalen Kompression
sehr ähnlich. Es kann daher nur darum gehen, jede individuelle Anwendung an alle technischen
Systeme möglichst gut anzupassen. Dazu ist ein detailliertes Verständnis der unterschiedlichen
Videosysteme, Kompressionsverfahren und Datenübertragungskanäle erforderlich. Diese Arbeit
will einen Einblick in bestehende Videosysteme sowie Übertragungsmöglichkeiten geben und
bietet dazu einen Überblick aktueller und in Zukunft verfügbarer Kompressionsverfahren.
2
2.1
PRINZIPIEN DER MEDIENKODIERUNG- UND VERBREITUNG
Grundlagen
Auf dem Weg von der Produktion bis hin zum Konsumenten durchläuft ein Videoinhalt verschiedene Instanzen und Prozeduren. Deren grundlegende Prinzipien sollen im Folgenden einleitend
aufgezeigt werden.
Die digitale Datenkompression dient zur Verringerung einer gegebenen Datenmenge, die
nicht nur eine Reduzierung des für die Ablage benötigten Speicherplatzes, sondern auch der
notwendigen Bandbreite für eine Übertragung ermöglicht. In der Nachrichtentechnik nimmt die
-2-
Digitale Verarbeitung bewegter Bilder
Übertragung eines Signals ein Frequenzband bestimmter Breite ein. Im Gegensatz dazu spricht
man in der Informationstechnik auf Grund einer digital definierten Übertragungsstrecke von der
Datenrate oder Bitrate eines Signals. Ein Standard-Videosignal [3] hat beispielsweise eine Datenrate von über 20 Megabyte pro Sekunde. Wegen der in der einschlägigen Literatur und Software
häufig mißverständlichen Bezeichnungen wird in dieser Arbeit folgende Nomenklatur bezüglich der
verwendeten Einheiten eingeführt:
Bei Angaben zur Bitrate oder Kapazität bezeichnen die Kurzschreibweisen [kbps] und
[Mbps] Werte von "Kilobit pro Sekunde" und "Megabit pro Sekunde“. Da diese Einheiten der Informationstheorie entstammen, bei der grundsätzlich von Zehnerpotenzen ausgegangen wird,
bezeichnet die Potenz "Kilo" hier einen Faktor von 1000. Taucht hingegen der Großbuchstabe "B“
in den Kürzeln [kBps] und [MBps] auf, so muß mit Werten von „Kilobyte pro Sekunde" oder "Megabyte pro Sekunde“ gerechnet werden. Diese Einheitenbezeichnungen entstammen der Datenverarbeitung und sind auf das duale Zahlensystem zur Basis 2 bezogen. Daher wird in diesem Fall mit
Vielfachen von 1024 gerechnet.
Die Bezeichnungen richten sich nach folgenden Gesetzmäßigkeiten:
1
1
1
1
kbps
Mbps
kBps
MBps
[kilobit per second]
[megabit per second]
[kilobyte per second]
[Megabyte per second]
=
=
=
=
1000 bps [bits per second] = 1000 baud [symbols per second]
1000 kbps = 1.000.000 bps
1024 Bbps [bytes per second] = 1024*8 bps [bits per second]
1024*1024*8 bps
Im Gegensatz zu einem einzelnen stehenden Bild trägt ein Teilbild im Kontext einer
bewegten Bildfolge die Bezeichnung "Frame"2. Eine Bildfolge ist gleichbedeutend mit dem Begriff
Sequenz. Für die Wiederholrate3 von Bildfolgen wird nach der englischen Bezeichnung "Frames
per second" das Kürzel [fps] verwendet.
2.2
Digitale Verarbeitung bewegter Bilder
2.2.1 Generierung von digitalen Bilddaten
Wenn in der Umgangssprache von "Video" oder "Film" die Rede ist, wird damit üblicherweise die Kombination aus einer zeitlichen Abfolge von natürlichen Bildern und dem dazu synchron ablaufenden Ton gemeint. Sowohl der Ton als auch die Bilder können einem synthetischen
Prozeß, genannt Animation, oder einer realen Szene entstammen. Die Animation ensteht durch
einen als "Rendering" bezeichneten rechnerischen Prozeß, der nach vorgegebenen Gesetzmäßigkeiten wahlweise in Echtzeit oder berechnet wird. Während das Rendering in einem
Rechner stattfindet, wird für die Abbildung von realen Bilddaten zusätzliche Hardware benötigt. Um
eine Videoszene aus der Realität in digitaler Form auf den Rechner zu transferieren, wird eine
Videoquelle, also ein Abspielgerät oder eine Kamera und eine Schnittstelle benötigt. Diese als
Capturedevice bezeichnete Baugruppe wandelt das analoge Signal der Quelle in eine digitale, für
den Computer verständliche Form um. Sie muß in der Lage sein, schnell genug auf Veränderungen einer Szene reagieren zu können, um die optische Täuschung eines fließenden Filmablaufs
aufrechtzuerhalten. Diese Forderung wird in der Datentechnik als "Echtzeitfähigkeit" bezeichnet.
Üblicherweise kommen Einsteckkarten zum Einsatz, die über mehrere analoge und digitale
Schnittstellen eingehende Bilddaten vom PCI-Bus4 des Rechners auf ein Speichermedium über1
auch "On-Demand"
engl. "Rahmen" für Einzelbild einer Bildfolge
auch "Refreshrate" oder "Framerate"
4
Abk. Peripheral Component Interconnect Bus
2
3
-3-
Digitale Übertragung von Multimediainhalten
tragen. Um Kompatibilität zwischen verschiedenen Schnittstellen zu gewährleisten, wird in genormten Standards neben den physikalischen Spezifikationen für Stecker, Buchsen und Verbindungskabel auch die Art der digitalen Übertragung mittels Übertragungsprotokollen festgelegt.
2.2.2 Digitale Speicherung von Bildfolgen
Im Heimbereich kommen Videostandards5 wie NTSC, PAL, S-VHS, DV, HF, FBAS und
RGB zum Einsatz, wohingegen sich auf der Produktionsseite BetaCam, DVC-Pro, D1 bis D6 und
SDI etabliert haben. Ein Devicetreiber steuert die Übertragung des Videodatenstroms von der
Peripherie auf ein sequentielles Speichermedium im Rechner. Die lokale Speicherung wird durch
das Betriebssystem geregelt. Wird eine analoge Schnittstelle benutzt, erfolgt die Analogdigitalwandlung während des Capturing auf der Schnittstellenkarte. Im Heimbereich sind bis auf das zum
Digital Video System (DV) gehörende Firewire6 alle Schnittstellen analog, wohingegen auf der
Produktionsseite ausschließlich auf digitale Bandsysteme gesetzt wird. Wie eingangs schon erwähnt, ist die Datenrate in der digitalen Videoverarbeitung ein wichtiger Parameter. Sie bewegt
sich in einem Bereich von 2 Mbps im Heimbereich bis zu 2 Gbps beim professionellen D6 System.
Dieser Größenunterschied um drei Zehnerpotenzen kommt sowohl durch verschiedene Videoparameter als auch durch unterschiedlich hohe Komprimierungsstufen zustande. Zu den Videoparametern zählen typischerweise die Bildauflösung, Bildwiederholraten und die Farbwiedergabe.
Auf der analogen Seite wird die Auflösung von der Anzahl der sichtbaren Bildzeilen fixiert.
Die maximale Bildwiederholrate eines Systems drückt sich in der horizontalen und vertikalen Synchronisationsfrequenz aus. Die Anzahl der wiederzugebenden Farben wird durch den SignalRauschabstand7 des übertragenen Signals bestimmt. Bei digitalen Bildern drückt sich die Auflösung hingegen in der Anzahl von Bildschirmpunkten8 in horizontaler und vertikaler Richtung aus.
Die Bildwiederholrate wird durch die Anzahl an nachgeladenen Frames in jeder Sekunde festgelegt. Die Anzahl an darstellbaren Farben, auch Farbraum genannt, ergibt sich aus der bei der
Digitalisierung angewendeten Quantisierungstiefe. Nach ihr richtet sich auch die Samplegröße des
zu einem Pixel gehörenden Farbwerts. Dieser kann in mathematisch unterschiedlichen Komponentenschreibweisen9 wie RGB, YUV, CYMK, DIB, HSB und LAB notiert werden. All diese Parameter zusammen ergeben eine Bandbreite oder äquivalente Bitrate, die zur Übertragung einer
Bildfolge erforderlich ist. Aus Gründen des Umfangs soll hier nicht näher auf die vielen unterschiedlichen Videoformate im Detail eingegangen werden. Vielmehr wird im Folgenden von einem
digitalisierten Bild- und Tonsignal ausgegangen, das lediglich aufgrund seiner eigenen Parameter,
jedoch unabhängig vom verwendeten Videosystem betrachtet wird. Des weiteren werden in erster
Linie Signale und Systeme betrachtet, die auch auf herkömmlichen Personal-Computern einsetzbar sind.
2.3
Für die Verbreitung und die verteilte Produktion von Video- und Audioinhalten bieten sich
vorhandene digitale Netzwerke an. Bereits installierte lokale Netze10 in Firmen ermöglichen eine
5
siehe Abkürzungsverzeichnis
auch Norm IEEE1394, mit bis zu 800 Mbps Übertragungsdatenrate
7
auch Signal to Noise Ratio (SNR)
8
auch "Pixel" für Picture Element
9
siehe Abkürzungsverzeichnis
10
auch Lokal Area Network (LAN)
6
-4-
effiziente Produktion, und Weitverkehrsnetze11 wie das Internet sorgen für die Übertragung zum
Endkunden. Dabei muß für die vom Videostandard geforderte Bandbreite jeweils ein entsprechender Netzwerkstandard gefunden werden.
Abbildung 1: Netzwerke & Videostandards, typische Datenraten12
Vergleicht man die bestehenden Videosysteme und deren typische Bitrate mit den verfügbaren Netzwerktechnologien in Abbildung 1, so taucht eine Lücke auf. Die zur Verfügung stehenden Systeme für Videoanwendungen reichen nur bis auf 1500 kbps an die untere Grenze heran.
Heutigen Glasfasernetzen sind mit Übertragungsbandbreiten von 10 Gbps und mehr nach oben
hingegen offensichtlich keine Grenzen gesetzt. Die Bedienung von Videotechnologien durch lokale
Netzwerke wie Ethernet, Firewire oder dem Asynchronous Transfer Mode Protokoll (ATM) ist
weitgehend gedeckt, wie auch aus einem Projekt "SDIoverATM" [5] des IRT hervorgeht. Auch
aktuelle Computer, die in der Wirtschaft Standard sind und sich wachsender Beliebtheit in Privathaushalten erfreuen, sind den Aufgaben des Desktopvideo gewachsen. Das zeigt die Einordnung von CD-Rom-Systemen oder der BUS-Architektur in die obige Abbildung.
Es wird deutlich, daß für Netzwerke mit niedrigen Bandbreiten, wie zum Beispiel DSL, ISDN
oder dem Groupe Spécial Mobile System (GSM), bislang kaum verbreitete Videosysteme existieren. Genau diese Lücke soll durch effiziente Videocodierung geschlossen werden. Die Notwendigkeit für den Einsatz neuer Verfahren wird noch deutlicher, wenn man deren Häufigkeit
betrachtet. Sind auf der Videoseite im Heimbereich Technologien wie VHS und die Digitale Video
Disc13 (DVD) weit verbreitet, so erfreuen sich GSM im Handysektor oder ISDN und DSL bei Festnetzen wachsender Beliebtheit. Da die Parameter dieser beiden Systeme jedoch nicht konform
sind, müssen Verfahren entwickelt werden, die eine zusätzliche Vermarktung der für DVD und
11
genannt: Wide Area Network (WAN)
Hinweis: mögliche Übertragungsraten der Netzwerkprotokolle variieren in verschiedenen Versionen und Implementierungen
teils erheblich, daher wurden hier jeweils ein Mittel der erreichbaren Eckwerte zugrunde gelegt.
Bei analogen Videosystemen wurde eine zur Bildqualität äuquivalente Datenrate ermittelt.
13
auch Digital Versatile Disc (DVD)
12
-5-
Verfahren zur Datenreduktion
DVB produzierten Inhalte auf Weitverkehrsnetzen einer solchen Technologie ermöglichen. Diese
Verfahren werden in naher Zukunft einen weiteren Schub durch die Verbreitung von Universal
Mobile Telecommunication Service (UMTS)-Geräten erfahren, die für Multimediaapplikationen
vorbereitet sind. Die folgenden wird daher ein Überblick über bestehende Verfahren zur Videokompression und deren Fähigkeit zur Übertragung über digitale Netze bei niedrigeren Bitraten
geben.
2.4
Ein Standard Videosignal [3] hat eine Datenrate von über 20 MByte pro Sekunde. Durch
eine Komprimierung vor der Übertragung und Speicherung werden die Daten kompakt genug, um
Hardwarebausteine nicht zu überlasten, und ein effektiver Transport ist gewährleistet. Es müssen
Wege gefunden werden, die Datenrate einer Videosequenz niedrig zu halten und dabei keine oder
sowenig Qualitätsverluste wie möglich zu erzeugen. Dazu kommt die Datenreduktion zum Einsatz.
Sie nutzt den Umstand, daß ein Signal, ein Bild oder eine Nachricht sich in vier Bereiche unterteilen läßt. Einen irrelevanten (unwichtigen), einen relevanten (wichtigen), einen redundanten
(bekannten) und einen den nichtredundanten (unbekannten) Teil. Die Grundidee der Datenreduktion besteht darin, die Irrelevanz und Redundanz, also unwichtige und bereits bekannte Informationen aus dem Informationsfluß zu eliminieren.
Abbildung 2: Kompressionsarten
2.4.1 Redundanzreduktion
Die Redundanzreduktion ist ein umkehrbarer und nicht verlustbehafteter Prozeß. Reduziert
wird nicht die im Signal enthaltene Information, sondern lediglich die zu übertragende Datenmenge. Das Bild, das bei einem Kodierungszyklus nach der Dekompression ensteht, ist identisch
mit dem Ausgangsbild. Dabei wird der Umstand ausgenützt, daß bestimmte Werte bzw. Farben
gehäuft vorkommen. Außerdem werden Informationen, die der Empfänger bereits kennt, nicht
wiederholt übertragen. Verändert sich der Bildinhalt nicht, so genügt es beispielsweise, ein einziges stehendes Bild zu übertragen. Eine wiederholte Übertragung mit 25 Bildern pro Sekunde ist
nicht notwendig. Erst eine Bildänderung muß dem Empfänger mitgeteilt werden. Ändert sich das
Bild wiederum nur in Teilaspekten, brauchen nur die relevanten Bildteile als Änderung übertragen
zu werden. Die wichtigsten Verfahren zur Redundanzreduktion werden im nächsten Kapitel
beschrieben. Dort wird jedoch zu diskutieren sein, daß mit solchen Verfahren nur sehr geringe
-6-
Kompressionsfaktoren erreicht werden können. Als sinnvolle Anwendung kommen Szenen mit
sehr geringem Farbumfang und wenig Bewegung wie zum Beispiel Animationen in Frage. (vgl. [6])
2.4.2 Irrelevanzreduktion
Die Irrelevanzreduktion entfernt aus dem Signal die Information, die vom Empfänger nicht
wahrgenommen werden kann und damit überflüssig ist. Sie ist ein irreversibler und verlustbehafteter Prozeß, da Information, die im Original vorhanden ist, durch die Reduktion verloren geht und
sich damit das decodierte Bild vom Original unterscheidet. Diese Reduktion findet im Videobereich
seit jeher Anwendung. So ist das Spektrum eines analogen Videosignals begrenzt auf 5 MHz, 575
sichtbare Zeilen pro Bild und 25 Bilder pro Sekunde. Da das Auge empfindlicher auf Helligkeitsunterschiede reagiert als auf Farbunterschiede, wird die Farbinformation mit einer geringeren
Bandbreite übertragen als die Helligkeit. In der digitalen Videotechnik muß die Abtastfrequenz und
die Quantisierungsstufenzahl festgelegt werden. Auch damit wird Irrelevanz reduziert. Aus der
Tontechnik ist bekannt, daß ein lauter Ton einen leisen Ton verdeckt. Damit braucht der leise Ton
nicht mehr aufgezeichnet oder übertragen zu werden. Das Kriterium dafür, in welchem Maße
Irrelevanzreduktion angewendet werden darf, liegt beim Empfänger. Die Fernsehtechnik bezieht
sich deshalb auf das menschliche Auge und Ohr. Informationen, die von ihnen nicht wahrgenommen werden, brauchen nicht übertragen zu werden. (vgl. [6])
Nicht wahrnehmbare Kompression
Systeme, bei denen der Betrachter den Unterschied zwischen dem ehemals komprimierten
und dem originalen Bild nachweislich nicht mehr wahrnehmen kann, werden in der Fachliteratur oft
als "perceptually lossless" bezeichnet. Ein solches System setzt eine entsprechend hohe
Qualitätsstufe voraus. Die Verfahren der Joint Picture Experts Group (JPEG) und der Moving
Picture Experts Group (MPEG) sind skalierbar und ermöglichen es, die Grenze der
Wahrnehmbarkeit zu variieren. Es gilt daher, den Kompressionsgrad, oft auch als Qualitätsfaktor
bezeichnet, so zu wählen, daß das menschliche visuelle System keinen Unterschied zum Original
feststellen kann.
Natürliche verlustbehaftete Kompression
Der Detailliertheitsgrad eines Seheindrucks hängt immer vom Betrachtungsabstand und
vom Blickwinkel auf ein bestimmtes Objekt ab. Daher ist im übertragenen Sinne ein Verlust von
feinen Details durch höhere Kompression durchaus akzeptabel, wenn der Betrachtungsabstand
vergrößert wird. Ein direkter Blick auf ein Objekt ist mit hoher Auflösung im Zentrum und mit
niedriger Auflösung im weiteren Umfeld gleichzusetzen. Auch ist das menschliche System an
bestimmte natürliche Störeinflüsse wie Regen, Schnee und Nebel gewöhnt. Diese Störeinflüsse
hindern den Mensch nicht, bestimmte Objekte nach wie vor zu erkennen. Erzeugt ein technisches
System also Störungen, die im Rahmen dieser psychooptischen Eigenschaften des Menschen
liegen, spricht man von einer natürlichen Kompression.
Unnatürliche verlustbehaftete Kompression
Trotz dieser Fähigkeit wird ein sehr hoher Kompressionsfaktor unterhalb einer bestimmten
Qualitätsschwelle dem menschlichen Betrachter als sehr störend erscheinen. Ab einem bestimmten Punkt der verlustbehafteten Kompression werden neu enstandene Objekte wahrgenommen, die eine Erkennung der ursprünglichen Szene unmöglich machen. Diese "Artefakte"
genannten Bildveränderungen werden in Abschnitt 3.3.4 detaillierter behandelt. Das menschliche
System ist sehr sensibel bezüglich Linien und Ecken. Es ist darauf ausgelegt, physikalische Ob-7-
Darstellung von Videokompressionsalgorithmen
Information und Kodierung
jekte wie Menschen, Nahrung oder mögliche Gefährdungen zu identifizieren und zu charakterisieren. Objekte werden von der Umgebung subjektiv durch Linien getrennt. Wenn nun ein Algorithmus diese Umrisse zerstört oder neue hinzufügt, wird der ursprüngliche Seheindruck verfremdet. Wie sich später zeigen wird, haben alle Verfahren bei ausreichend hoher Kompression Probleme mit den Ecken eines Bildes. Die Vektor-Quantisierung, Block-Diskrete-Kosinustransformation
oder die Wavelettransformation haben beispielsweise alle keine mathematische Entsprechung für
die intuitive Wahrnehmung von Ecken und Linien. (vgl. [7])
3
3.1
DARSTELLUNG VON VIDEOKOMPRESSIONSALGORITHMEN
Information und Kodierung
Bevor die einzelnen Algorithmen zur Videokomprimierung im Detail dargestellt werden, soll
hier kurz auf das allen gemeinsame Prinzip eingegangen werden. Ein Kompressionszyklus besteht
aus mehreren Stufen. Die eingangs im Capturingprozess digitalisierten Daten werden nach einer
möglichen Speicherung der Haupttransformation unterzogen. Die am häufigsten verwendeten
Transformationen nach Fourier, mit Kosinus oder das neuere Wavelet-Verfahren sind in Abbildung
3 aufgeführt.
Abbildung 3: Kompression und Kodierung
Durch die anschließende Quantisierung der Transformationsprodukte wird eine Kompression erreicht. Bleibt die Quantisierung der Koeffizienten aus, handelt es sich um einen verlustlosen
Prozeß. Bei der anschließenden Kodierung kann, abhängig vom Signal, eine weitere, verlustlose
Reduzierung des Datenvolumens erreicht werden. Die so reduzierten Inhalte können übertragen
oder lokal gespeichert werden. Bevor sie nun beim Empfänger wieder ausgegeben werden können, muß der gesamte Prozeß wieder umgekehrt werden. Es ist eine Dekodierung und Rekonstruktion mit anschließender inverser Transformation notwendig.
3.1.1 Entropiekodierung
Zunächst soll ein Überblick über die als Entropiekodierung bezeichneten Verfahren zur
Reduzierung der Kodewortlänge gegeben werden. Dabei werden die Wahrscheinlichkeiten, mit
denen ein Symbol oder eine Symbolfolge auftritt, ausgenützt. Die Idee der Huffman-Kodierung
geht auf das Prinzip des Morsealphabets zurück. Dort werden den häufig vorkommenden Symbolen kürzere Codes zugeordnet als den seltener vorkommenden. Dabei werden alle Symbole
nach ihrer Häufigkeit in einer Tabelle sortiert. Viele Kompressoren und Grafikformate wie zum
-8-
Kompression stehender Bilder
Beispiel das Graphics Interchange Format (GIF) verwenden das LZW-Verfahren, benannt nach
Lempel, Ziv und Welch. Diese auch als Lauflängenkodierung14 bezeichnete Technik faßt eine
aufeienanderfolgende Sequenz von gleichen Symbolen oder Pixeln gleicher Farbe als ein Codewort zusammen. Zum Beispiel könnte man eine Folge aus den Pixelwerten 77 77 77 77 77 77 77
als 7 mal 77 auffassen.
Häufiger vorkommende Symbolfolgen werden dabei in Teilketten zerlegt. Jede Teilkette
erhält einen Index, der in einer Tabelle abgelegt wird. Der Ausgabecode besteht nur aus den
Indizes dieser Tabelle. Diese wird nicht mit abgespeichert und muß bei jeder Kompression und
Dekompression erst erzeugt werden. Ihre Größe wird bei konkreten Implementierungen
beschränkt. Im Unterschied zum Huffman-Verfahren werden hier ganze Symbolfolgen zu jeweils
einem neuen Symbol zusammengefaßt.
Bei der arithmetischen Kodierung werden die Symbole ihrer Wahrscheinlichkeit nach in
Unterintervalle angeordnet. Je kleiner das zu einem Symbol gehörige Unterintervall ist, desto
länger wird sein Codewort, und umgekehrt. Die Kodierung erfolgt dadurch, daß jedem Symbol eine
binäre Fließkommazahl zugeordnet wird, die dem Anfang der Position des Unterintervalls entspricht. Im Vergleich zur Huffman-Kodierung, die jedem Zeichen einen Code zuordnet, ist die
arithmetische Kodierung für Zeichenfolgen effizienter. (vgl. [8])
3.1.2 Transformationskodierung
Bei dem als Transformationskodierung bezeichneten Verfahren wird nur eine Beschreibung
übertragen anstatt das Signal selbst. Dabei findet meist eine Transformation in den Frequenzbereich mit der Übertragung der spektralen Koeffizienten statt. Für Bilder funktioniert diese
Transformation zweidimensional. Alle im Folgenden beschriebenen Algorithmen benutzen Kombinationen aus Entropiekodierung und unterschiedlichen Transformationen.
3.2
Bei dem nun folgenden Überblick über die derzeit und in naher Zukunft verfügbaren Kompressionsverfahren werden zunächst die verbreiteten Algorithmen geschildert. Anschließend werden Implementierungen dargestellt, in denen einzelne oder auch Kombinationen dieser Verfahren
realisiert wurden.
Die Reduzierung des Datenvolumens von natürlichen Bildfolgen ist gekennzeichnet
dadurch, dass grundsätzlich zwischen einer Kompression jedes einzelnen stehenden Bildes für
sich und der Kompression einer Gruppe aufeinanderfolgender Bilder unterschieden wird. Beide
Verfahren werden hintereinander angewendet. Die räumliche Kompression von Einzelbildern, wie
auch die zeitliche Kompression einer Bildfolge nutzt bestimmte psychooptische Eigenschaften des
menschlichen Sehapparates aus.
14
engl. Run Length Encoding (RLE)
-9-
Abbildung 4: Videokompressionsalgorithmen, Übersicht
3.2.1 Vektorquantisierung
Die Vektorquantisierung teilt ein Bild in ein Schachbrettmuster zu Blöcken von je 4 mal 4
Pixeln ein. Mit einer gewissen Wahrscheinlichkeit befinden sich bestimmte Blöcke im Bild, die
mehrfach auftauchen, oder zumindest ähnliche Repräsentanten haben. Der Encoder identifiziert
eine Klasse von gleichartigen Blöcken und ersetzt diese durch einen "generischen" Repräsentanten. Typischerweise wird dann der am häufigsten auftretenden Klasse der kürzeste Binärcode
zugeordnet. Aus mehreren solcher Codes wird eine Tabelle, "Lookuptable" oder "Codebook"
genannt, zusammengestellt, aus welcher der Decoder anschließend in der Lage das approximierte
Bild wieder zusammensetzt . Dieses Verfahren ist nicht verlustlos, da die realen Blöcke durch
möglichst ähnliche ersetzt werden. Der Enkodierungsprozeß ist langsam und rechenintensiv, da
eine Statistik über Häufigkeiten von Blöcken geführt und die Ähnlichkeit ständig neu berechnet
werden muß. Der Dekodierungsprozeß hingegen geht auf Grund der bereits vorhandenen Lookuptable schnell vonstatten. Der Kompressionsgrad kann durch die Menge der unterschiedlichen
abspeicherten Blöcke variiert werden. Je weniger verschiedene Blöcke abgespeichert werden,
desto geringer ist die Genauigkeit der Übereinstimmung zwischen ähnlichen Blöcken. Damit sinkt
die Qualität des rekonstruierten Bildes. Die Schachbretteinteilung bedingt bei höheren Kompressionsgraden Artefakte, die sich in einer sichtbaren Blockbildung äußern (➜3.3.4).
3.2.2 Diskrete Kosinustransformation
Eine weitere Möglichkeit, Bilder zu komprimieren, ist die von der Signalverarbeitung her
bekannte Kosinustransformation. Die internationalen Standards MPEG, ITU-T H.263 [9], und
JPEG basieren auf der diskreten Kosinustransformation (DCT). Grundlage ist die Fouriertransformation, die beliebige Signale als Überlagerung von Sinuswellen verschiedener Frequenzen und
Amplituden darstellt. Aus der örtlichen Verteilung von Pixelwerten in einem Bild wird nach der
Transformation eine Frequenz und Amplitudenverteilung. Große regelmäßige Flächen im Bild
schlagen sich dabei in niedrigen Frequenzanteilen nieder, feine Details hingegen in hohen. Der
überwiegende Anteil an visueller Information in einem realen Bild liegt im Bereich niedriger Fre- 10 -
quenzen. Kompression wird erreicht, indem höherfrequente Anteile des Bildes geringer gewichtet
werden.
In den genannten Standards kommt eine zweidimensionale DCT zum Einsatz, die auf
Blöcke zu je 8 mal 8 Pixeln des Bildes angewendet wird. Die sich daraus ergebenden 64 Koeffizienten je Block werden anschließend quantisiert. Üblicherweise werden sehr kleine Koeffizienten
zu null gesetzt. Psychooptische Tests haben ergeben, daß das menschliche Auge auf hohe Frequenzkomponenten weniger sensibel reagiert als auf niedrige. Daher werden diese mit größeren
Faktoren quantisiert. Es wird so eine nichtlineare Quantisierungskennlinie eingesetzt, die sich in
den unterschiedlichen Quantisierungsfaktoren einer Quantisierungsmatrix niederschlägt. Sie enthält 64 Einträge, mit jeweils einem Faktor für jeden der 64 DCT Koeffizienten. Nach der Quantisierung werden alle Koeffizienten lauflängenkodiert, wodurch Codes variabler Länge entstehen.
Vor der Übertragung können diese Codes wiederum einer Huffmannkodierung unterzogen werden.
Auf diese Weise kann eine beachtliche Kompression erreicht werden.
3.2.3 Diskrete Wavelettransformation
Die diskrete Wavelettransformation (DWT) besteht vereinfacht dargestellt aus zwei Filtern,
einem Hochpaß und einem Tiefpaß. Der Tiefpaßfilter gibt eine Version des eingehenden Bildes mit
niedriger Auflösung, der Hochpaßfilter ein zusätzliches Detaildifferenzsignal aus. Die Produkte
dieser Filter werden auf ihre halbe Auflösung interpoliert. Die Summe der Ausgangsprodukte entspricht in diesem Stadium der Anzahl an Bits des Eingangssignals. Die Parameter der beiden Filter
werden so gewählt, daß bei einer Addition der Filterprodukte wieder das exakte Original entsteht.
Anschließend kann das Ausgangssignal des Hochpaßfilters und das addierte Detailsignal wieder
einem weiteren Filterpaar zugeführt werden, und der Prozeß wird wiederholt. Das Ausgangssignal
des Tiefpaßfilters stellt eine grobe Approximation des ursprünglichen Eingangssignals dar. Wenn
das Eingangssignal ein Bild ist, entsteht dabei eine grob aufgelöste verschwommene Ansicht des
Bildes. Dagegen ist der Ausgang des Hochpaßfilters ein Detaildifferenzsignal. Das grobe Signal
wird auch als "basis layer" und das detaillierte als "enhancement layer" bezeichnet. Die zur Bild
und Videokompression verwendeten Waveletalgorithmen wiederholen diesen Prozeß mehrere
Male. Die Ausgangswerte werden als Waveletkoeffizienten bezeichnet.
Bis hierhin hat allerdings noch keine Kompression stattgefunden, da die Transformation die
gleiche Anzahl Bits produziert, die im Eingangssignal enthalten sind. Kompression wird auch hier
durch eine bestimmte Quantisierungsart erreicht. Dabei kommen in einfachen Implementierungen
die skalare Quantisierung und in komplexeren die Vektorquantisierung zum Einsatz. Reale Objekte
haben normalerweise eine gleichmäßige Oberfläche mit einer bestimmten Reflexion, der sogenannten Textur. Diese Textur kann eine einheitliche Farbfläche oder ein komplexes quasiperisisches Muster sein, wie dies bei Tapetenmustern oder Marmorstrukturen der Fall ist. Aus diesem
Grund läßt man in der Praxis das Tiefpaßsignal g[n] mit vorangegangenen Werten g[n-1] korrelieren. Dabei wird g[n] meistens beinahe gleich g[n-1] sein. So wird das Tiefpaßsignal g[n] als eine
Differenz von vorhergehenden Werten g[n-1] kodiert, um eine höhere Kompression zu erreichen.
Auf diese Weise wird die Besonderheit des menschlichen visuellen Systems berücksichtigt, für
feine Details weniger sensibel zu sein als für grobe Strukturen.
3.2.4 Konturbasierte Bildkodierung
Eine Kontur ist eine Linie, die den Umriß einer Figur oder eines Körpers darstellt. Eine
Textur repräsentiert dagegen die Oberflächenstruktur des Körpers. Bei der konturbasierten Bildkodierung werden Bilder aus mehrern Konturen, die jeweils eine Texturfläche zur nächsten ab- 11 -
Kompression bewegter Bilder
grenzen, dargestellt. Da Konturen sehr häufig mit den Umrissen von Objekten übereinstimmen,
existiert ein enger Zusammenhang zwischen konturbasierter und objektbasierter Bildkodierung.
Bei letzterer wird ein Bild aus mehreren Objekten zusammengesetzt, die ihrerseits aus mehreren
Konturen aufgebaut sein können. Beim Enkodierungsprozess werden Konturen und Texturen aus
dem Gesamtbild extrahiert. Anschließend werden die Konturen als Kontrollpunkte einer polynomialen "Spline" Kurvenfunktion abgespeichert und mit der Textur ausgefüllt. Texturen selbst können
als Koeffizienten einer räumlichen Frequenztransformation wie der DCT oder der Wavelettransformation abgespeichert werden. Kompression wird durch skalare oder Vektorquantisierung der
Splineparameter und der Texturkoeffizienten erreicht.
Das Hauptproblem bei diesem bislang selten realisierten Verfahren ist die Detektion von
Ecken und Linien. Sie ist sehr rechenintensiv, und die Erkennungsrate ist begrenzt. Im schlechtesten Fall werden dort Konturen erkannt, wo in Wirklichkeit keine sind. Die Konturextraktion ist
eine typische Mustererkennungsaufgabe, die dem Menschen subjektiv keine Schwierigkeiten
bereitet, sich im Rahmen einer Rechnersimulation jedoch als äußerst komplex erwiesen hat. Im
Prinzip könnte das konturbasierte Kodierungverfahren viele Probleme lösen, die bei der Kosinustransformation und den Waveletverfahren bestehen und dabei eine höhere Komprimierung erreichen. Derzeit ist jedoch nur ein als Surface Fitting Method (SFM) bezeichnetes Verfahren der
Firma Crystal Net15 bekannt, das der konturbasierten Kodierung am nächsten kommt. Einige Teile
des ISO Standards MPEG 4 enthalten zwar solche Prinzipien, eine Umsetzung läßt jedoch bislang
noch auf sich warten.
3.3
Bisher wurde die Komprimierung von stehenden Einzelbildern besprochen. Im folgenden
wird erörtert, welche zusätzlichen Maßnahmen bei einer Folge von abhängigen Frames durchgeführt werden können.
3.3.1 Framedifferenzierung
Bei diesem in der englischsprachigen Literatur als Frame Differencing (FD) bezeichneten
Verfahren wird die Tatsache ausgenützt, daß in Videosequenzen von einem zum nächsten Bild nur
wenig Veränderungen stattfinden. Als Beispiel könnte eine Szene genannt werden, in der sich ein
Ball vor einem stehenden Hintergrund bewegt. Der größte Teil des Bildes ist von Frame zu Frame
gleich. Das vorher besprochene Vektorquantisierungsverfahren wird bei der Framedifferenzierung
auf zwei aufeinanderfolgende Frames angewendet. Die Anwendung dieses Verfahrens ermöglicht
grundsätzlich eine höhere Kompression bei gleichbleibender Bildqualität als ein unabhängiges
Einzelbildverfahren. Kommt es bei der Übertragung jedoch zu Fehlern, so summieren sich diese
solange auf, bis der Prozeß neu gestartet wird. Dadurch können schnell ganze Bildregionen
verschwinden. Daher werden spezielle Frametypen eingeführt, die einen periodischen Neustart
des Verfahrens erzwingen (➜3.3.3). Ohne diese wäre bei einer nach dem FramedifferencingAlgorithmus kodierten Sequenz ein Aufsuchen bestimmter Bilder innerhalb der Folge unmöglich.
Jeder Übertragungsfehler würde stets einen Neustart der Dekodierung erzwingen.
3.3.2 Bewegungskompensation
Das auch unter dem Begriff Motion Compensation (MC) bekannte Verfahren ist objektorientiert. Es ist auf Szenen anwendbar, in denen sich klar abgegrenzte Objekte über einen sta15
Internet: http://www.crystalnet.com
- 12 -
tischen Hintergrund bewegen. Im Gegensatz zur Framedifferenzierung wird anstatt der Pixelwerte
eines ganzen Blocks lediglich ein Bewegungsvektor abgespeichert oder übertragen. Zunächst ist
eine Detektion von Objekten, wie zum Beispiel einem fliegenden Ball in einer Szene durchzuführen. Dazu wird auch hier das gesamte Bild in Teilblöcke strukturiert. Es wird für jeden
Block ein Bewegungsvektor erzeugt, der auf einen Block gleicher Größe in einem vorangegangenen oder zukünftigen Frame verweist. Ohne Bewegung ist dieser Block der gleiche wie der
vorhergehende und der Vektor bleibt "0". So muß der Encoder nicht das eigentliche Objekt an sich
verfolgen. Ein Vergleich von Pixelblöcken des dekodierten Frames mit solchen im Referenzframe
ist ausreichend. Dabei kann sich der Referenzblock irgendwo im Bild befinden, und die
vorhergesagten Blöcke sind ein Teil des Frames, welches gerade dekodiert wird. Diese Reihenfolge muß jedoch nur beim Enkodierungsprozeß eingehalten werden. Beim Abspielen kann das
Referenzframe auch ein zukünftiges sein. Dieser Vorgang wird im MPEG-Standard als "bidirectional-predicted" Verfahren bezeichnet. Anschließend werden die Vektoren noch lauflängenkodiert,
um die Kompression zu erhöhen. Der Enkodierungsprozess wird als Bewegungsvorhersage (Motion Estimation) und der Dekodierungsprozess als Bewegungskompensation (Motion Compensation) bezeichnet.
Beim zuletzt betrachteten Beispiel eines bewegten Balles vor einem statischen Hintergrund
bewegen sich die meisten Blöcke nicht. Die Bewegungsvektoren sind also fast alle null. In diesem
Fall ist die Motion Compensation äquivalent zum Frame Differencing, wo die Differenz zwischen
einem Block und dem selben Block im vorhergehenen Bild eine Rolle spielt. Betrachtet man die
Blöcke, die die Bewegung des Balles enthalten, so werden deren Bewegungsvektoren nicht null
sein. Sie werden die Referenz auf ein vergangenes oder zukünftiges Frame enthalten, in dem der
Ball auftaucht. Der verschobene Block wird von dem aktuellen subtrahiert. Mit der Motion Estimation können höhere Kompressionsraten als beim Frame Differencing erreicht werden. Die Enkodierung ist jedoch rechenintensiver.
Das Motion Compensation Verfahren, welches in MPEG und den verwandten Standards
H.261 und H.263 verwendet wird, funktioniert nur mit translatorischen Bewegungen. Gute Ergebnisse werden bei bewegten Objekten mit festen Hintergründen oder Kameraschwenks erzielt.
Es ist jedoch ungeeignet für sich drehende oder die Größe verändernde Objekte und bei Kameravergrößerungen16. Auch findet keine Objekterkennung statt, es kommt die blockorientierte
Detektion zum Einsatz. Als Entscheidungswert dient das mittlere Fehlerquadrat der Einzelblöcke.
Der Encoder identifiziert dabei einen verschobenen Block am kleinsten Wert des auftretenden
Fehlerquadrates. Die im Kapitel 5 genauer beschriebenen internationalen Video Standards MPEG
1, MPEG 2, MPEG 4, H.261, und H.263 benutzen die DCT zusammen mit Motion Compensation.
Die Verfahren ClearVideo von Iterated Systems, VDOWave von VDONet und der VxTremekompressor benutzen abgewandelte Formen der Motion Compensation. (vgl. [7])
3.3.3 Frametypen
Eingangs wurde der Unterschied zwischen einem stehenden Bild und einem Einzelframe
aus einer Bildfolge definiert. Da bei der Kompression von Videos Teilsequenzen, bestehend aus
mehreren Frames, zusammengefaßt werden, existiert eine weitergehende Klassifikation mehrerer
Frametypen. Als "keyframe" werden Frames bezeichnet, die Basis für auf sie folgende Differenzinformationen sind. Sie sind in sich räumlich komprimiert, stellen aber die Information eines kompletten Bildes dar. Keyframes werden in äquidistanten Zeitabständen übertragen und ermöglichen
16
genannt: Zoom
- 13 -
so eine regelmäßige Korrektur von angehäuften Übertragungsfehlern im Bild. Sucht der Benutzer
eine bestimmte Stelle im Videostrom auf, so springt der Decoder immer auf das nächste vorhandene Keyframe. In der Quicktimearchitektur sowie bei Video for Windows werden diese als Intraframes und im MPEG Standard als I-Frames bezeichnet. Auf die Vollbildinformation solcher Keyframes folgen "Interframes", die nur noch Differenzinformationen zum jeweiligen Vorgänger
enthalten. Diese auch als "differential frames" oder "Deltaframes" bezeichneten Bilder gehen aus
einer temporären Kompression wie dem der Bewegungskompensation oder der Framedifferenzierung hervor. Im MPEG-Standard existieren wiederum zwei verschiedene Typen dieser Interframes. Dort sind bidirektionale "B-Frames" definiert, die auf einem vorangegangenen und einem
nachfolgenden Frame basieren, sowie vorhergesagte "predicted frames", die Informationen aus
weiter in der Vergangenheit liegenden Frames enthalten. Eine typische MPEG Framefolge wird
auch als Group of Pictures (GOP) bezeichnet. Sie startet mit einem I-Frame, gefolgt von B- und PFrames, wobei ein letztes P-Frame den Abschluß bildet.
3.3.4 Artefakte
Räumliche Komprimierung
Bei einer verlustbehafteten Kompression von Bildern verliert das ursprüngliche Bild mit
jedem Kodierungsprozeß Informationen. Durch die endliche mathematische Genauigkeit bei der
Quantisierung entstehen Fehler in der Abbildung. Bei einer unnatürlichen Kompression können
diese vom menschlichen Auge wahrgenommen werden. Haben durch solche Fehler sichtbare
Veränderungen am Bild stattgefunden, so nennt man diese Artefakte. In Tabelle 1 sind typische
Artefakte dargestellt, wie sie bei der Kompression stehender Bilder auftreten.
digitalisiertes Original
Wavelet Transformation
Diskrete Kosinus Transformation
Reduzierte Auflösung
Konturbasierte Vektorgrafik
binäre/reduzierte Lauflängenkodierung
Tabelle 1: Transformationen und Artefakte17
17
Hinweis: Der Kompressionsgrad wurde individuell eingestellt, so daß sichtbare Verfremdungen auftreten
- 14 -
Verluste präsentieren sich bei der diskreten Kosinus-Transformation als sogenannte
"Blocking Artefakte". Dabei kann es zu einer Verschleifung von spitzen Ecken und unscharfen
Linien kommen. Blocking ist sehr gut an flächigen, wenig detailreichen Stellen zu beobachten. Mit
der diskreten Wavelet Transformation kodierte Bilder erzeugen keine unscharfe, kreisförmige
Überlagerungen im Bild. Sie treten vorzugsweise an kantigen Objektabgrenzungen auf. Bei einer
konturbasierten Vektorisierung, einer Reduzierung des Farbraums oder der Auflösung spricht man
nicht mehr von Artefakten im eigentlichen Sinn. Sie bewirken meist eine tatsächliche Reduzierung
des Informationsgehalts eines Bildes und keine Redundanzreduzierung.
Die Häufigkeit von sichtbaren Artefakten bestimmt maßgeblich über die Qualität eines
Bildes. Zur Beurteilung stehen subjektive und objektive Verfahren zur Verfügung. Ein objektives
Verfahren sind die Standardmessungen Peak Signal to Noise Ratio (PSNR) oder Mean Squared
Error (MSE). Durch diese Messungen wurde gezeigt, daß die DWT die DCT an Qualität übertrifft.
Bei subjektiven Qualitätstests, wie sie die European Broadcasting Union (EBU) im Hinblick auf das
zukünftige digitale Fernsehen DVB durchgeführt hat [10], müssen Versuchspersonen solche
Störungen einer Skala von sechs Kategorien zuweisen. Sie reicht von "kaum wahrnehmbaren"
über "akzeptable" Bildveränderungen bis hin zu "sehr störenden" Veränderungen. Die subjektive
Bildqualität der DWT ist auf Grund einer besseren Anpassung an das menschliche System oft
höher, als die von DCT basierten Verfahren bei gleicher Kompressionsrate.
Streifenbildung
bei fehlender Interlacingfilterung
Phantombild
bei fehlender Interlacingfilterung
Zeitliche Komprimierung
Durch eine zeitliche Komprimierung nach dem Motion Compensation oder dem Framedifferencingverfahren entstehen weitere zusätzliche Artefakte. Da sie je nach verwendetem Verfahren sehr unterschiedlich sein können, wird hier an Hand von Stichproben versucht, eine Klassifizierung durchzuführen. Zur besseren Übersicht wird in den folgenden Bildschirmfotos jeweils der
interessante Bereich rechts oben als Ausschnitt gezeigt.
Bildung von Farbflächen
Verschmieren von Details
Tabelle 2: Artefakte (I)
- 15 -
In der oberen Zeile von Tabelle 2 sind Effekte zu sehen, die auftreten, wenn vor der
Kodierung von PAL- oder NTSC-Material keine Deinterlacingfilterung vorgenommen wird. Die
untere Hälfte zeigt eine Verminderung der Detailstreue, hervorgerufen durch eine Zusammenfassung quasigleicher Farbbereiche. Das Bild rechts unten wurde mit einigen Hauptkonturen auf
wenige einheitliche Farbflächen reduziert.
Konturbildung
durch Objektabgrenzung
Vermischung von Details,
getrennter Objekte
Tabelle 3: Artefakte (II)
In Tabelle 3 ist eine Verfremdung detailreicher Regionen gezeigt. Nachdem im linken Bild
eine zu kantige Abgrenzung der bewegten Haare stattfindet, sind die Details im rechten Bild zu
einem undefinierbaren Farbgemenge geworden.
Verschmieren
bei schneller Bewegung
Farbrauschen an Grenzflächen
Farbrauschen an Linien
Farbrauschen
kontrastreicher Konturen
Tabelle 4: Artefakte (III)
Tabelle 4 zeigt unterschiedliche Ausprägungen von einem, als "Mosquito Noise" bezeichneten Farbrauschen. Dieses Rauschen tritt vorwiegend an Linien und Kanten auf, die geringer
Bewegung unterliegen. Ein Verschmieren einer bewegten Partie ist rechts unten zu erkennen.
- 16 -
Verwischen und
kantige Objektbildung
Farbstufen durch übermäßige
Blockbildung
Phantomfarbfläche
bei Bewegung
Blockbildung an weichem
Farbübergang
Tabelle 5: Artefakte (IV)
In Tabelle 5 sind verschiedene Ausprägungen der, für das DCT-Verfahren typischen Blockbildung zu erkennen. Links oben wird der kontinuierliche Farbübergang des Himmels in wenige
Farbzeilen abgestuft. Im Bild rechts oben taucht eine Phantomfarbfläche auf, die einen Überrest
eines bereits vergangenen Frames darstellt. Beim Bild links unten hat der Codec die
Farbabstufung übertrieben. Rechts sind zwar die Farbübergänge gut angepaßt, bestimmte Objekte
hingegen wurden zu hart abgegrenzt.
- 17 -
Analyse der Komplexität verschiedener Verfahren
4
Capturing
ANALYSE DER KOMPLEXITÄT VERSCHIEDENER VERFAHREN
Bisher wurden Eigenschaften der unterschiedlichen Algorithmen besprochen, die zur Kompression von bewegten Bildern herangezogen werden. Nun soll die Realisierung solcher Verfahren
auf aktuellen Rechnerarchitekturen dargestellt werden. Aus Gründen des Umfangs wird hier nur
das Betriebssystem Microsoft Windows zur Erläuterung herangezogen. Die nun zu besprechenden
Systeme finden jedoch auch zunehmend auf anderen Plattformen wie MacOS oder Linux Verbreitung.
Peripherie
Schnittstelle
Dbquvsjoh
Encoder
Playout
Dpnqsfttjpo Ejtusjcvujpo Efdpnqsfttjpo
Remote
Interaction
Raw A/V
interleave
Decoder
Server
Raw A/V
Content
Local
Interaction
Media
Stream
Transport
Stream
Media
Stream
Raw A/V
Interactive
temp
Storage
Stream Frames
H A H V H A H V
Content Provider Broadcast Provider
Network Packets
H A H V H A
Media Stream
HD
Audio
Video
Archiv
HD
File
HEAD
Kopie
Network Provider
Client
Abbildung 5: Netzwerk Broadcasting, Ablauf
Bei der Multimediadistribution spielen verschiedene technische Komponenten eine Rolle,
die häufig durch verschiedene Dienstleister betreut werden. Die vom Contentprovider bereitgestellten Bild- und Tondaten müssen nach der Aufzeichnung durch ein Peripheriegerät wie einer
Kamera zunächst in digitale Signale umgewandelt werden. Dieser hochratige digitale Datenstrom
kann zur Nachbearbeitung temporär gespeichert werden. Anschließend erfolgt die Kompression
durch den Encoder, welcher über eine Netzwerkverbindung mit einem Server verbunden ist. Dieser ist für die globale Verteilung der Inhalte an ein entferntes Publikum18 zuständig. Zur Archivierung für einen späteren "OnDemand" Betrieb (➜6.5) kann dieser komprimierte Datenstrom
lokal bei einem Service Provider archiviert werden. Schließlich wird der Datenstrom beim Client auf
einem Player dekodiert und visualisiert. Sowohl die dekodierten Videoinhalte als auch der kodiert
abgespeicherte Datenstrom kann nachträglich weiterverarbeitet und verändert werden.
4.1
Capturing
Der Capturingprozeß läuft in einer Schnittstellenkarte ab, welche durch spezielle Hardwarekomponenten das System entlastet. Die dafür in der Systemsteuerung eingerichteten Eingabe- und Ausgabetreiber regeln den Datentransport. Dort werden die Eingabeparameter
eingestellt, die die Bildqualität maßgeblich beeinflussen. Diese Komponenten müssen echtzeitfähig
sein, da es sonst zu Bildaussetzern oder Tonstörungen kommen kann. Im Livebetrieb muß der
Encoder den Datenstrom in Echtzeit übernehmen, dagegen erfolgt im Offlinebetrieb eine zeitver-
- 18 -
Codecs
setzte dateiorientierte Abarbeitung. Für den Encoder kommen zwei mögliche Implementierungsformen in Betracht. Er kann als als fester Programmbestandteil in eine Encoderapplikation
integriert sein oder als Systembestandteil im Betriebssystem integriert werden.
4.2
Codecs
Für die Implementierung der beschriebenen Verfahren und Algorithmen zur Kompression
wird eine als Compression Manager bezeichnete Softwareschnittstelle im Betriebssystem bereit
gestellt. Sie gliedert sich in die Bereiche Audio Compression Manager (ACM) und Video Compression Manager (VCM), die der Benutzer über die Multimediasteuerung der Oberfläche einsehen
kann. Wie aus Abbildung 6 hervorgeht, kann der Algorithmus als eigene Anwendung laufen, oder
er ist als Compressor-Decompressor-Pärchen (CoDec) im Compression Manager installiert.
Abbildung 6: Multimedia Architekturen & Codecs, Struktur
Als Codec stehen dessen Funktionalitäten für verschiedenste Applikationen zur Verfügung.
Deren Programmcode wird als Dynamic Link Liberary (DLL) beim Start des Betriebssystems geladen. Da viele verschiedene Codecs von verschiedenen Firmen existieren, werden von Microsoft
zur genauen Identifizierung Codes vergeben, die aus vier ASCII-Charaktern bestehen und daher
Four Character Codes (FCC) genannt werden. Ist der Komprimierungsalgorithmus hingegen Bestandteil einer Applikation, so ist der Benutzer auf diese festgelegt. In diesem Fall müssen alle
anderen Komponenten an dieses Programm angepaßt werden. Oft ist zusätzlich eine Netzwerkanbindung sowie ein universeller Capturetreiber Bestandteil einer Encoderanwendung. Zu Kontrollzwecken steht in den meisten Encodern auch eine Monitoringfunktion zur Verfügung, bei der
gleichzeitig eine Dekodierung stattfindet. Beim Endbenutzer wird zu diesem Zweck ein meist
kostenfreier, separat verfügbarer Mediaplayer installiert. Dieser ist Bestandteil einer Multimediaarchitektur und kann bei Bedarf auf bereits im Compression Manager installierte Codecs zurückgreifen. Dabei findet die Zuordnung einer Streamingmediadatei in zwei Instanzen statt. Nachdem
der Benutzer das Betriebssystem aufgefordert hat, die Datei zu öffnen, sucht dieses zunächst
anhand der Dateiendung nach dem zum Dateityp assoziierten Abspielprogramm. Danach wird die
Datei an die gestartete Decoderanwendung übergeben. Diese entscheidet sich auf Grund eines im
Header der Datei enthaltenen FCC-Codes für die Benutzung eines externen Codecs oder für einen
integrierten Dekodierungsalgorithmus. Erst jetzt kann mit der Visualisierung des kodierten Datenstromes begonnen werden.
18
genannt: Clients
- 19 -
4.3
Multimedia-Architekturen
Mit Multimedia-Architektur wird der gesamte Komplex an Software bezeichnet, der für das
Broadcasting von Audio, Video und Zusatzdiensten notwendig ist. Dazu zählen nicht nur Player
und Encoder, sondern auch Streamingtools oder Nachbearbeitungswerkzeuge. Drei spezielle
Architekturen sind weit verbreitet: das "Real System G2" der Firma Real Networks, "Windows
Media" von Microsoft und "Quicktime Video" aus dem Softwarehaus von Apple. Der Funktionsumfang dieser Architekturen soll im Folgenden näher erläutert werden. Es sei angemerkt, daß der
Name Codec oft mißverständlich gebraucht wird. Viele im System installierte Codecs sind nämlich
auf die Dekodierung beschränkt. Versucht man hingegen, diese in eine Encoderapplikation einzubinden, erhält man eine Fehlermeldung beim Start des Enkodiervorganges, oder das Programm
stürtzt ab. Das liegt daran, daß die als Codecs installierten Programmteile den Algorithmus zum
Enkodieren überhaupt nicht oder nur in der lizensierten Entwicklerversion enthalten.
Mit einer Multimediaarchitektur können Videosequenzen komprimiert, dekomprimiert und
dargestellt werden. Ihnen werden die im Capturingprozess enstandenen Dateien mittles Importfunktionen übergeben und anschließend unter Verwendung eines Codec in das architektureigene
Dateiformat überführt. Teilweise bestehen zusätzlich Bearbeitungsmöglichkeiten für Bildbeschneidungen oder Filterfunktionen. Die Bildqualität und -größe sowie Parameter für die spätere
Netzwerkübertragung oder Dateigröße einer Sequenz werden hier festgelegt.
Zusatzlfunktionalitäten
Alle im Folgenden aufgeführten Architekturen unterstützen neben reinen Videosequencen
eine Vielzahl an zusätzlichen multimedialen Möglichkeiten. Genannt sei hier zum Beispiel die
Möglichkeit, langsame Standbildfolgen, genannt Slideshows, mit der Bewegung von getrennt
abgespeicherten Bildobjekten (Sprites) zu koppeln. Textstreaming ermöglicht es, Laufschriften in
eine Videosequenz einzublenden. Außerdem kommen neuerdings Benutzerschnittstellen für interaktive Inhalte dazu. Browserähnliche Bedienelemente können im Bildfenster plaziert werden,
über die der Benutzer in den Ablauf eingreifen kann. Für die Implementiering dieser Funktionalitäten haben die Hersteller eigene Interpretersprachen19 entwickelt, die meist an gängige Internetprotokolle wie HTTP angelehnt sind. Der Vorteil in diesen sehr speziellen Funktionalitäten liegt
darin, daß eine Medienpräsentation vor der Übertragung nicht mehr in eine Videosequenz verwandelt werden muß. Es besteht die Möglichkeit, Objekte mit dem Ablaufplan und den Eigenschaften
ihrer Darstellung direkt zu versenden. Dadurch kann bei höchstmöglicher Qualität sehr viel
Netzwerkbandbreite eingespart werden. In Bezug auf die Videokodierung wird hier genau der
umgekehrte Weg beschritten, den die eingangs geschilderten Komprimierungsalgorithmen
durchführen.
4.3.1 Real Video
Das Real System G2 beinhaltet die zweite Generation von Video und Audiocodecs der
Firma RealNetworks. Sie besteht aus den drei Komponenten Producer, Server und Player, wobei
die Enkodieralgorithmen Bestandteil der Producerapplikation sind. Fremde Codecs können nicht in
die Produktion eingebunden werden. Der Player ist lediglich zum Dekodieren in der Lage und ist
auch als Plugin für HTML-Browser verfügbar. Eine RealPlayer Plus genannte Version bietet
weitere Zusatzfunktionen und muß kostenpflichtig bei Real Networks bezogen werden. Der Real
Server wird für Life-Streaming und verbindungsloses HTTP-Streaming, auch als progressiver
19
Abk. Synchronized Multimedia Integrated Language (SMIL)
- 20 -
Download bezeichnet, benötigt (➜6.5). Außer den Produkten der Firma RealNetworks gibt es
keine weiteren Applikationen, die Realdatenströme verarbeiten können. Mit dem Real System G2
können neben Audio- und Videoinhalten auch andere Medien wie Text oder Flashanimationen
über Netzwerke übertragen werden. Es ist für Datenraten bis 768 kbps konzipiert. Für CD-Rom
und DVD Distributionen ist es auf Grund der hohen geforderten Rechenleistung bei höheren
Qualitätsstufen nicht geeignet. Wie die meisten anderen verlustbehafteten Verfahren ist auch Real
unidirektional. Das heißt, sich einmal im komprimierten Zustand befindende Realdateien können
mit Ausnahme einer Videoschnittbearbeitung nachträglich nicht bearbeitet werden.
Der Real Server ist in der Lage, einen skalierten Datenstrom zu senden. Dieses als SureStream bezeichnete Verfahren ermöglicht es, bis zu 6 Video- und Audiodatenströme, die speziell
für bestimmte Netzwerkanbindungen optimiert wurden, parallel auszusenden. Dazu findet während
der Übertragung eine permanente bidirektionale Kommunikation zwischen dem RealPlayer und
dem RealServer statt, bei der unter anderem Parameter über die aktuelle Qualität der Verbindung
ausgetauscht werden. Verändert sich diese, so kann während der Übertragung auf einen Datenstrom unterschiedlicher Datenrate umgeschaltet werden. Dabei werden die Audio und Videoströme
getrennt behandelt. Eine Prioritätenregelung legt fest, ob beim Einbruch der Datenrate ein Videostandbild gezeigt oder lediglich die Audiospur gespielt werden soll. Das RealSystem G2 unterstützt
SMIL [I] und ermöglicht es so, Audio- und Videoinhalte innerhalb einer HTML-Seite mit anderen
Medien und Aktionen zu synchronisieren. Beispielsweise können mit SMIL mehrere Filme zu
bestimmten Zeiten geladen werden, einfache Objektbewegungen und Laufschriften realisiert werden. Auch ein Austausch von Internetadressen mittels Uniform Resource Locator (URL) ist
möglich. Der Player ist frei verfügbar und enthält Werbung. Server und Encoderanwendung sind
kostenpflichtig wobei bei Liveübertragungen für jeden übertragenen Stream Zusatzkosten entstehen. Es stehen gegenwärtig Versionen für Windows und MacOS zur Verfügung.
4.3.2 Apple Quicktime
Quicktime ist eine plattformübergreifende Multimediaarchitektur für Windows und MacOS.
Zu den Medieninhalten gehören Graphiken, Sound, Video, Text, Musik, virtuelle Simulationen und
dreidimensionale Darstellung20. Apple liefert neben dem Player selbstentwickelte und zugekaufte
Video- und Audiocodecs mit und ist in der Lage fremde Codecs mit einzubinden. Encoder und
Player sind hier in einer Anwendung implementiert, wobei der Zugriff auf die Komprimierungsfunktionen als Dateiimport und -export realisiert ist. Für aufwendigere Videoproduktionen bieten
sekundäre Hersteller wie Terran Interactive und Sorenson getrennte Lösungen an. In Zusammenarbeit mit einem dezidierten Medienserver bietet Quicktime Live-Streaming nach dem RTSP Protokoll (➜6.3). Apple und weitere Firmen21 haben Server für die Linuxplattform und andere
Plattformen angekündigt [16]. Es wird zur Verbreitung von interaktivem Video auf CD-Rom und
DVD, wie für CD Interactive (CD-I) Präsentationen verwendet. Diese Anwendungen werden in
Fachkreisen der sogenannten Kioskpräsentation zugeordnet. Die Bearbeitung und Produktion wird
durch Software verschiedener Hersteller unterstützt. Mit verschiedenen Tools ist ein vielseitiger
Einsatz möglich [U]. Die Playeroberfläche kann in HTML-Seiten integriert werden. Bei einer als
"alternate movie" bezeichneten Funktion ermöglicht ein PlugIn22 die Benutzung skalierbarer
Datenströme. Bei der Enkodierung können mehrere Datenströme mit unterschiedlichen Kriterien
erzeugt werden. Dadurch kann die Wiedergabe an die Bandbreite der bestehenden Netzwerkver20
21
hier: Quicktime VR (Virtual Reality)
z.B. SGI, IBM, Cisco
- 21 -
bindung, das verwendete Betriebssystem, die aktuelle Programm- und Sprachversion des Players
und an die Rechengeschwindigkeit des Clientcomputers angepaßt werden. Die Import- und Exportfunktionen werden durch den Bezug einer Seriennummer bei Appel ermöglicht. Der kostenlosen Player wird so gegen ein verhältnismäßig geringes Entgeld zur "Quicktime Pro" Version
aufgerüstet.
4.3.3 Windows Media Technologies
Windows Media Technologies ist eine von Microsoft entwickelte Architektur. Windows Media ist spezialisiert auf die Netzwerkübertragung von Video- und Audioinhalten. Die Encoderanwendung kann alle Codecs einbinden, die im Compression Manager registriert sind. Auch bei der
Installation der Windows Media Tools werden wie bei Quicktime mehrere eigene und fremdentwickelte Codecs installiert. Als Streamingmethoden stehen ein serverorientiertes "true
streaming", sowie serverloses "HTTP streaming" zur Verfügung (➜6.5). Ein von Microsoft als
"intelligent streaming“ bezeichnetes Verfahren soll eine unterbrechungslose Übermittlung des
Mediendatenstromes garantieren. Im Falle eines Übertragungsdefizits sendet der Windows Media
Server automatisch weniger Daten, wodurch sich die Qualität gegebenenfalls so weit reduziert,
daß nur noch Audioinformationen übertragen werden. Durch die parallele Erzeugung mehrerer
Versionen des Videostromes mit unterschiedlichen Bitraten und Frameraten wird eine begrenzte
Skalierbarkeit erreicht. Die Bilddimensionen und Parameter der Audiodaten sind hingegen für den
Gesamtdatenstrom festgelegt. Da die Audioübertragung so auf eine einzelne Spur festgelegt ist,
erhalten in der Praxis beispielsweise Zuhörer mit einer DSL-Verbindung die gleiche Tonqualität wie
ISDN-Benutzer. Der Windowsplayer ist in der Objekthierarchie von Windows über DirectShow
(➜4.3.4) angesiedelt, wodurch er in der Lage ist, neben seinen eigenen Codecs auch die dort
installierten zu benutzen. Der Macintoshclient kann neben seinen eigenen auch QuickTime
Codecs einbinden. Vor Beginn des Abspielens werden die optimalen Übertragungsparameter
zwischen Server und Client festgelegt. Der Player ist zusätzlich in der Lage, Frames zu überspringen oder die Bildqualität zu verringern, um ein Abspielen in Echtzeit zu ermöglichen. Der Windows
Media Player ist für eine Reihe von mobilen Systemen wie WindowsCE und PalmOS , sowie in
einer beta-Version für das MacOS verfügbar. Die Vorgängerversion der aktuellen Windows Media
7 Architektur trug den Namen NetShow. Alle Komponenten von dieser Architektur werden kostenlos zum Download angeboten. Für Live-Streaming werden jedoch die kostenpflichtigen professionellen Netzwerkversionen von Microsoft Windows 2000 oder NT benötigt.
4.3.4 Direct Show
DirectShow ist hierarchisch an der Spitze von DirectX23 anzusiedeln und unterstützt Multimediastreaming über Netzwerke, CD-Rom, DVD-Rom sowie den Digital Video Standard. Es
handelt sich dabei um eine API-Schnittstelle24, die clientseitiges Playback, Transkodierung und
Capturing einer Vielzahl von Formaten ermöglicht. Sie ist der Nachfolger der Architekturen Video
for Windows und Active Movie. Zusatzkomponenten wie DirectDraw, DirectSound und Direct3D
von DirectX sollen dabei einen maximalen Zugriff zu beliebiger Audio- und Videohardware auf
windowsbasierten Computern garantieren. DirectShow macht dabei Gebrauch vom Windows
Media Player, der als ActiveX25-Control-Komponente in andere Anwendungen wie dem Internet
Explorer oder als PlugIn im Netscape Navigator eingebettet werden kann. Als zusätzliche Ab22
zur Laufzeit integrierbares Softwaremodul für funktionale Erweiterungen
Softwarepaket für die Erweiterung von Audio, Video und 3D-Fähigkeiten ab Windows95
24
Abk. Application Programming Interface (API)
23
- 22 -
Dateiformate
spielmöglichkeit steht auch eine OCX-Komponente25 zur Verfügung. DirectShow selbst beinhaltet
allerdings noch keine Streamingkomponenten für Netzwerke. In der neuesten Version von DirectX
wurden DirectShow und DirectDraw unter dem Namen DirectMedia zusammengefaßt und sind um
die Fähigkeit eines DVD-Playbacks von MPEG2 erweitert worden.
4.3.5 Video for Windows
Video for Windows war ursprünglich für Distribution auf CD-Rom entwickelt worden und
setzte sich später teilweise im Internet durch. Mit DirectShow wurde das Audio Video Interleave
(AVI) Dateiformat definiert (➜4.4), das man heute vorwiegend in der lokalen Videobearbeitung
einsetzt, da es eine framegenaue Synchronisierung der Audio- zur Videospur ermöglicht. In Video
for Windows verwendete Codecs können mit DirectShow, NetShow oder anderen Anwendungen
verwendet werden.
4.3.6 Andere Architekturen
Zusätzlich zu den genannten Multimedia Architekturen der führenden Hersteller gibt es
auch noch eine Hand voll Konkurrenten. BinkVideo ist zum Beispiel eine Videoarchitektur für 16-Bit
Echtfarben und soll an die Bildqualität von MPEG2 heranreichen. Smacker kommt aus der Spielebranche und ist optimiert für Systeme mittlerer Leistung. Es benutzt intern eine 8-Bit-Kodierung
und wird häufig für animierte Zwischensequenzen von Actionspielen auf CD-Rom-Datenträgern
eingesetzt. VivoActive wird nicht mehr weiterentwickelt. Emblaze ist eine auf JAVA basierende
Architektur, welche ohne PlugIntechnik auskommt. Sie benötigt aber generell die jeweils neueste
Version der Javasystemumgebung und ist sehr rechenintensiv.
4.4
Dateiformate
In der Datenverarbeitung existiert eine Vielfalt von teils offiziellen, teils firmeneigenen
Dateiformaten auf unterschiedlichen Plattformen. Im Zusammenhang mit Desktopvideo relevante
Formate sollen hier kurz genannt werden. Grundsätzlich erfolgt die Identifizierung eines Medienformats in zwei Schritten. Nach der Benutzeraufforderung zum Öffnen wird im ersten Schritt die
zugehörige Anwendung durch das Betriebssystem gestartet. Deren Auswahl erfolgt über das
Dateikürzel anhand einer, in der Registrierungsdatenbank abgelegten Zuweisungsliste. Ist mit dem
Kürzel noch keine Anwendung assoziiert, wird der Benutzer aufgefordert, eine vorhandene auszuwählen. Nach dem erfolgreichen Start, übergibt das Betriebssystem die referierte Datei an die
Anwendung. Im zweiten Schritt öffnet nun die Anwendung selbst die ihr übergebene Datei. Die
meisten Dateien enthalten eine sog. Kopfstruktur (Header26), in der zusätzliche, das Format
beschreibende Verwaltungsinformationen enthalten sind. Der Header wird beim Anlegen der Datei
automatisch durch das erstellende Programm vergeben. Multimediadateien enthalten meist
zusätzlich noch sogenannte Metadaten, die eine benutzerdefinierte, oft datenbankgestützte
Beschreibung des Inhalts, der Quellen und Eigenschaften ermöglichen. Erst wenn durch diese
Schritte eine erfolgreiche Identifizierung stattgefunden hat, beginnt beispielsweise ein Videoplayer
mit der Dekodierung des Inhalts. Im Falle von Video- und Audiodateien, die einen kontinuierlichen
sequentiellen Datenstrom darstellen, existiert jedoch noch eine weitere dateiinterne Paketstruktur.
Die Datei besteht dann aus einer Kette mehrerer Pakete, die ihrerseits eine eigene Headersektion
und einen Datenteil (Payload) enthalten. Eine ähnliche Struktur wird auch einer normalen Datei
aufgeprägt, bevor sie über ein paketorientiertes Netzwerk übertragen werden kann. Enthält zum
25
26
Steuerelement für die Entwicklung von C++ Applikationen
Verwaltungsstruktur im Kopf eines Datenpaketes oder einer Datei
- 23 -
Übersicht verfügbarer Implementierungen
Dateiformate
Beispiel ein Internetpaket im Header Informationen über Zielort, Route und Fehlerkorrektur, so sind
im Header jedes MPEG-Audio-Paketes Angaben zur Abtastfrequenz, Bitrate oder zum Kopierschutz enthalten.
Die Hauptformate der drei Multimediaarchitekturen tragen die Kürzel [MOV] für Quicktime
Movie, [RM] für Real Media und [WMV] für Windows Media Video. Mit der Vorgängerversion Video
for Windows wurde das Audio Video Interleave [AVI] Format definiert, welches in NetShow durch
das Advanced Streaming Format [ASF] ersetzt werden sollte. Aktuelle WMV-Dateien haben intern
jedoch das gleiche Format wie ASF-Dateien. Sie unterscheiden sich lediglich durch einen am
Anfang angefügten Suchindex. Dieser kann auch nachträglich mittels Windows Media SDK an eine
ASF-Datei angefügt werden. Nach einer simplen Umbenennung ist ASF dann in eine WMV-Datei
konvertiert worden. Die Architekturen halten weitere Dateitypen für die Integration in HTML-Seiten
und zu Steuerung ihrer multimedialen Zusatzfunktionen bereit, die bei Real und Windows Media
als XML-Applikationen27 realisiert sind. Bei Microsoft stehen Advenced Stream Redirector [ASX]
Dateien28 zur automatischen Ablaufsteuerung von Multimediainhalten zur Verfügung. Das Realsystem verarbeitet neben RealAudio [RA] und RealVideo [RV] Dateien auch SMILSteuerdokumente. Zu diesen zählen RealText [RT], RealText3D [R3T] und [RP] Dateien für
Diashows [33]. AVI wird heute hauptsächlich in der lokalen Videobearbeitung eingesetzt, da es
eine framegenaue Synchronisierung der Audio- und Videospur ermöglicht. Bilder und Gruppen von
Tonsamples29 sind in einer AVI-Datei segmentorientiert abgelegt. Sie kann neben unkomprimierten
Daten auch eine voneinander unabhängig komprimierte Stereo-Audio- und Videospur enthalten.
Eine AVI-Datei hat einen Header, in dem neben dem FCC des Codec auch Informationen über die
Dauer und die Abtasteigenschaften der Audio- und Videospur abgelegt sind. Sofern die bei der
Kodierung verwendeten Codecs dem Compression Manager des Betriebssystems bekannt sind,
können diese durch Video for Windows, DirectShow oder andere Anwendungen identifiziert werden.
5
ÜBERSICHT VERFÜGBARER IMPLEMENTIERUNGEN
Da eine Vielzahl von Codecs für verschiedenste Einsatzzwecke existiert, wurde hier eine
Auswahl getroffen. Sie richtet sich nach der Fähigkeit, bewegte Bilder mit einer möglichts niedrigen
Bitrate zu übertragen. Ziel ist also, bei kleiner Bandbreite möglichst viele Bild- und Bewegungsinformationen übertragen zu können. Da der Focus dieser Arbeit auf der Übertragung von Videos
über das Internet liegt, werden die Verfahren MPEG1 und MPEG2 auf Grund ihrer hohen Bitrate
nur zu Vergleichszwecken herangezogen. In Tabelle 6 ist ein Überblick über die Eigenschaften
und Technologien der Codecs abgedruckt, die im Folgenden erläutert werden. Dabei sind mit
"skalierbar" Codecs bezeichnet, die einen Mechanismus zur benutzerdefinierten Begrenzung der
durchschnittlichen Datenrate im Enkodierungsprozeß implementiert haben.
27
Abk. Extended Markup Language (XML), Weiterentwicklung von HTML
für Audio auch [WAX] und Video [WVX]
29
Sample: engl. Abtastwert
28
- 24 -
Codec
Apple Video
Aware Motion Wavelets
Cinepak
Clear Video
Crystal Net (SFM)
Digital Video (DV)
DivX
Escape Videostudio
H. 261
H. 263
Indeo Video Interactive 5.x
Intel Indeo 3.x
Microsoft RLE
Motion JPEG
MPEG 1
MPEG 2
MPEG 4
Sorenson Video
VDOWave
VxTreme
x
X
x
x
x
x
x
x
x
x
x
x
x
x
x
X
?
X
?
?
X
?
X
X
X
x
X
x
x
x
x
x
x
x
x
x
x
x
x
x
t
x
x
x
x
Plattform
Technologie
Architektur
Unkomprimiertes Video
Lauflängenkodierung
Vektor
Quantisierung
Diskrete
Kosinustrafo.
Diskrete
Wavelettrafo.
Kontourbasierte
Bildkoding
Frame
Differenzierung
Fraktale
Kompression
Bewegungs
Kompensation
Skalierbar
QT
WIN,MAC
WfW
WIN
WfW
WIN
WfW
WIN
WfW
WIN
WfW,QT
WIN,MAC
WfW
WIN,MAC,UNX,BeOS
WfW
WIN
WfW,QT
WIN,MAC
WfW,QT
WIN,MAC
WfW
WIN
WfW
WIN
WfW
WIN
X
WfW,QT
X WM,WfW,QT,RL
X WM,WfW,QT,RL
X WM,WfW,QT,RL
X
QT
X
WfW
?
WfW
WIN,MAC
WIN,MAC
WIN,MAC
WIN
WIN,MAC
WIN
WIN
Tabelle 6 : Codecüberblick, Merkmale
5.1
Unkomprimiertes Video
Die Datenmenge eines unkomprimierten Filmes ist extrem hoch. Für eine Sekunde Video
werden im PAL-Format rund 20 MB Speicherplatz benötigt, wenn man bei einer Farbquantisierung
mit 24 Bit 720 Bildpunkte je Zeile abtastet.
720 Bildpunkte ⋅ 576 sichtbare Bildzeilen ⋅ 25 Bilder ⋅ 24
Bit Farbe
MByte
MBit
= 29,6
≈ 250
je Pixel
sec
sec
Zur unkomprimierten Speicherung von Videomaterial wird kein Codec benötigt. Für die lokale
Speicherung wird das mit Video for Windows eingeführte AVI-Dateiformat verwendet. Als FCC für
unkomprimiertes Video tauchen die vier verschiedenen Varianten $0DIB, $0RGB, $0RAW und
$0000 als hexadezimale Werte auf. In aktuellen Videocodecs für Windows werden eine Reihe
verschiedener Verfahren auch in Kombinationen verwendet. Unkomprimiertes Video wird meist nur
lokal auf einer Workstation bearbeitet und verläßt diese erst als fertiger Videoclip. In diesem als
"nichtlinearer Videoschnitt" oder "offline editing" bezeichneten Verfahren wird also nur die interne
BUS-Architektur des Computers benutzt. Als Schnittstelle auf der Videoseite kommt das Serial
Digital Interface (SDI) zum Einsatz, welches eine Übertragungsrate von bis zu 270 Mbps zuläßt. In
ersten Tests am IRT [5] ist bereits die Übertragung eines unkomprimierten SDI-Videosignals über
eine ATM-Netzwerkverbindung gelungen.
- 25 -
5.2
Dieses auch als Run Length Encoding (RLE) bezeichnete Verfahren verwendet eine verlustlose Kodierung, wie sie auch bei GIF oder dem neueren Portable Network Grafiks (PNG) Format für stehende Bilder verwendet wird. GIF ist wegen einer zusätzlichen Animationsmöglichkeit
für Bannerwerbung im Internet sehr beliebt. RLE wird auch für die zweifarbige Kodierung von FAXDokumenten verwendet. Nachdem der Farbraum der Ausgangsbilder auf einen bestimmten Bitwert
reduziert wurde, werden hier nebeneinanderliegende gleichfarbige Pixel zu einem Codewort
zusammengefaßt. Je größer der benutzte Farbraum ist, desto geringere Kompressionsfaktoren
werden bei reellen Bildern und Videos erzielt. Die Kodierung beschränkt sich auf Inhalte innerhalb
eines einzelnen Frames. Es findet also keine zeitliche Komprimierung statt. Verfügbare RLECodecs beschränken sich daher meist auf 256 Farben oder 8 Bit. Ein sinnvoller Einsatzbereich für
Videoanwendungen ergibt sich zum Beispiel bei künstlich erzeugten Animationen.
5.3
Cinepak
Cinepak wurde ursprünglich für das Abspielen von kleinformatigem Video auf 386er und
030er Systemen oder dem PowerMac mit singlespeed CD-Roms entwickelt. Damit stellt sein
Hauptvorteil die geringen Anforderungen an Rechenkapazität der Hardware dar. Mit einer Weiterentwicklung der Hardware ging auch eine Benutzung von Cinepak für höhere Datenraten als ursprünglich geplant einher. Bei der erstmaligen Erscheinung von Cinepak war man über die Qualität
und Datenrate erstaunt. Mittlerweile stehen jedoch für die meisten Anwendungen hochwertigere
Verfahren zur Verfügung. Wenn allerdings eine weitreichende Hardwarekompatibilität gefordert
wird, kann Cinepak nach wie vor eine sinnvolle Entscheidung sein. Cinepak läßt sich mit den
Architekturen Quicktime und Video for Windows verwenden. Eine Transkodierung zwischen diesen
Architekturen ermöglicht den verlustlosen Übergang zwischen der Windows- und Macintosh
Plattform. Für Netzwerkübertragungen bei Internetdatenraten unter 240 kbps ist dieser Codec nicht
geeignet. Da der geringstmögliche Komprimierungsfaktor bei 10:1 liegt, sind die Datenraten auf
wenigstens 5000 kbps festgelegt. Wenn bei der Produktion die Datenratenlimitierung abgeschaltet
wird, erzeugt ein bekannter Programmierfehler in gleichfarbigen Regionen sichtbare Blockingartefakte. Trotz der Unterstützung von 8 Bit Videoinhalten, erzeugt eine reduzierte Farbpalette mit 24
Bit bessere Ergebnisse.
5.4
Indeo
Indeo wurde 1980 von Intel in der Version 3.2 veröffentlicht und trug ursprünglich den Namen RealTime Video 2.1. Der Codec ist dem von Cinepak sehr ähnlich und eignet sich gut für CDRom Datenraten. Er wird von einer Reihe von Rechnern unterstützt. Indeo 3.2 ist ein Vorgänger
von Indeo Video Interactive, benutzt jedoch ein gänzlich anderes, auf der DCT basierendes Kompressionsverfahren. Zu den unterstützten Architekturen zählen Quicktime und Video for Windows.
Ein Vorteil dieses Codecs ist die um den Faktor 3 geringere Rechenintensität gegenüber Cinepak.
Es besteht ein bekannter Implementierungsfehler, der verhindert, Material zu kodieren, dessen
Bildhöhe größer ist als die Bildbreite. Außerdem wird empfohlen, das Keyframe Intervall unabhängig von der Wiederholfrequenz auf den festen Wert 4 zu setzen. Und in Zusammenhang mit
Quicktime die codeceigene Farbpalette mit 8 Bit zu verwenden. Bei festgelegter Datenrate werden
alle Qualitätseinstellungen ignoriert.
- 26 -
5.5
Indeo Interactive
Indeo Interactive
Indeo Video Interactive (IVI) ist ein hochwertiger waveletbasierter Codec. Die Version 4
wurde mit Quicktime 3 ausgeliefert, dagegen muß die neue Version 5 als getrenntes Paket installiert werden. IVI produziert gute Bildqualitäten, benötigt zum Abspielen aber mindestens einen
Pentium oder PowerMac. Zusätzlich zu den üblichen Funktionen bietet dieser Codec eine Reihe
zusätzlicher Möglichkeiten. Dazu zählt eine Chromakey-Funktion, die transparentes Video ermöglicht, und eine nicht näher dokumentierte, sogenannte Hotspot-Unterstützung. Indeo wird von
der Quicktime-Architektur sowohl auf der Macintosh, als auch auf der Windowsplattform unter
DirektShow und Video for Windows unterstützt. Da die Windowsversionen leistungsfähiger sind als
die für den Macintosh, ist die plattformübergreifende Nutzung eingeschränkt. Version 5 stellt eine
Verbesserung bezüglich der Bildqualität gegenüber der Vorgängerversion dar. In Zusammenarbeit
mit Intel's Streaming-Anwendungen besteht die Möglichkeit, mittels eines progressiven Downloads
eine erhöhte Qualität zu erreichen. Generell ist die Bildqualität jedoch geringer, als die des Sorenson-Codec.
5.6
H.261
H.261 ist ein international standardisierter Codec der für den Einsatz bei Videokonferenzen
entwickelt worden ist. Die mögliche Datenrate beträgt maximal 384 kbps. Er basiert auf der bidirektionalen DCT und Motion Compensation und eignet sich speziell für niedrige Datenraten bei
relativ langsamen Bewegungen. Diese erste Implementierung eines DCT-Videocodecs wurde als
Ausgangspunkt für die Entwicklung der MPEG Standards zugrundegelegt. H.261 ist bereits bei
Datenraten um 50 kbps relativ rechenintensiv und damit nicht für leistungsschwächere Rechner
geeignet. Implementierungen existieren von Intel unter dem Namen ProShare und von Microsoft in
Windows 95. H.261 unterstützt die Architekturen NetShow und Video for Windows.
5.7
H.263
H.263 ist eine Weiterentwicklung des H.261 und des MPEG1-Standards mit dem Ziel, unterhalb 64 kbps eine bessere Qualität zu erreichen. Er basiert auf der blockdiskrete-n KosinusTransformation und stellt in vielen Punkten eine Verbesserung gegenüber der Motion Compensation des H.261 Standards dar. Zusätzlich bietet er Funktionserweiterungen im Hinblick auf paketorientierte Netzwerkübertragung und Fehlerrobustheit. Bei Szenen mit sich wenig verändernden
Inhalten kann ein hoher Kompressionsfaktor erreicht werden. Die bessere Bildqualität geht mit
einer höheren Rechenintensität einher, die speziell bei Datenraten über 50 kbps eine Echtzeitkodierung erschwert. Die Dekodierung funktioniert auch auf langsameren Maschinen gut. Standard
H.263-Datenströme unterstützen die Framegrößen von CIF, QCIF und 16CIF [9].
H.263 wird von mehreren Architekturen wie Quicktime, NetShow, und Video for Windows
unterstützt. Es existieren Implementierungen unter den Namen Vivo H.263, Duck's TrueMotion 2.0
und I H.263 von Intel. Microsoft installiert einen Codec mit NetShow 2.0 und Vivo30 Software vertreibt Streaming-Video-H.263-Komponenten zusammen mit dem Audiocodec G.723 für das Internet unter dem Namen VivoActive. Für das eigens definierte VIV-Dateiformat, das auch in HTMLSeiten integriert werden kann, wird der Vivoplayer benötigt. Zum Enkodieren wird der VivoActiveProducer benötigt.
30
Internet: http://www.vivo.com
- 27 -
5.8
MPEG
MPEG
Das Standardisierungsgremium MPEG wurde 1988 unter dem offiziellen Namen ISO/IECJTC1/SC29/WG1131 gegründet und hat seitdem mehrere Komprimierungsstandards für Audio- und
Videodaten definiert. MPEG ist Teil des Technical Committee on Information Technology32 (JTC1),
einem Zusammenschluß der International Standardisation Organisation33 (ISO) und der
International Electrotechnical Commission34 (IEC). Es existieren bereits eine Reihe von Implementierungen der MPEG Audio und Video, sowohl in Hardware als auch in Software. Sie werden durch
DVD, DAB, DVB, bei Computerspielen und zahlreichen anderen Anwendungen benutzt. Die
MPEG Familie umfaßt die Standards MPEG1, MPEG2 und MPEG4, offiziell bekannt ISO/IEC1117235, ISO/IEC-13818 und ISO/IEC-14496.
MPEG Video Codecs
Das MPEG-Videoverfahren verwendet ähnlich dem Verfahren der Joint Picture Expert Grup für
stehende Abbildungen einen DCT-Algorithmus. MPEG führt zusätzlich jedoch eine zeitliche Komprimierung durch.
5.8.1 MPEG 1
MPEG1 ist der am weitesten verbreitete Standard und wird durch viele Player auf verschiedenen Plattformen unterstützt. Bei Windows95 ist beispielsweise ein Decoder im Media Player
integriert. Diese Version von MPEG ist auf eine Auflösung von 352 x 288 Bildpunkten beschränkt,
die einem Viertel des PAL-Standards entspricht. Bei einer maximalen Bitrate von 4 Mbps wird noch
keine Fernsehqualität erreicht. Netzwerkstreaming ist bei MPEG1-Codecs nicht vorgesehen, und
die erzeugten Videodateien eignen sich mit einer minimalen Datenrate von 1Mbps nicht für Internetübertragungen. Diese Version ist für CD-I, Video-CD- und für die sogenannten LaserdiscAnwendungen vorgesehen. Aktuelle DVD-Abspielgeräte sind zu diesem Standard kompatibel.
5.8.2 MPEG 2
Bei MPEG2 wird zunächst wie bei MPEG1 das DCT-Verfahren auf Einzelbilder angewendet. Danach wird eine Reihe von 12 aufeinanderfolgenden Bildern dem Motion-CompensationVerfahren unterzogen und jeweils die Veränderung zum Vorgängerbild gespeichert. MPEG2 erfaßt
dabei allerdings auch identische Bildteile, die sich nur von einem zum nächsten Bild bewegen.
Dabei wird nur gespeichert, welcher Bildausschnitt sich im nächsten Bild wie weit bewegt hat.
Diese Art der Kompression ist zwar aufwendig, erzeugt allerdings auch bessere Ergebnisse.
MPEG2 ist in der Auflösung beliebig skalierbar und erreicht bei einer durchschnittlichen Datenrate
von 4 Mbps eine Datenreduktion um den Faktor 30-50. Decoder sind in DVD-Abspielgeräten und
digitalen Settopboxen zum DVB-Empfang mit standardisierten Hardwarebaugruppen realisiert. Die
Bitrate des Videodatenstroms einer DVD kann bis zu 9,8 Mbps betragen. Damit ergibt sich eine
Spieldauer von 2 Stunden bis 4 Stunden Video auf einer doppelschichtigen DVD. Bei der Ausstrahlung mehrerer gebündelter MPEG2-Kanäle über Satellit für DVB erfolgt eine dynamische
Bitratenzuweisung für jeden Kanal. Diese Datenraten übersteigen jedoch die Übertragungskapazität heutiger Weitverkehrsnetzwerke. Im Standard ist ein Streamingverfahren nur in begrenztem Maße vorgesehen. Jedoch existieren mittlerweile Packumsetzungsalgorithmen, die in
Software oder Hardware realisiert, eine Übertragung über Internet Protokoll (IP) auf sehr breit31
Internet: http://drogo.cselt.stet.it/mpeg
Internet: http://www.iso.ch/dire/jtc1/directives.html
33
Internet: http://www.iso.ch/welcome.html
34
Internet: http://www.iec.ch
32
- 28 -
MPEG
bandigen Netzen ermöglichen. Bei zu hohen Kompressionsfaktoren kommt es speziell in Bildregionen, die schnellen Bewegungen ausgesetzt sind, zu Blocking-Artefakten. Für die Rechenleistung, die zum Dekodieren benötigt wird, reicht ein Pentium-II-233 mit geeigneter Grafikkarte
aus [18].
5.8.3 MPEG 4
Da der MPEG4-Standard sehr umfangreich ist, sind gegenwärtig viele Funktionalitäten nur
ansatzweise implementiert. Einige Teilbereiche dieses Standards wie die Verbreitung von Multimedainhalten über Netzwerke sind permanent in Entwicklung. Der Standard definiert neben den
Videokomprimierungsverfahren auch noch Sprites, 3D-Welten, Klang- und Sprachsysnthese,
Bildsynthese nach vorgegebenen Modellen und Interaktivität. Als interne Sprache dient JAVAScript. Im Moment gibt es allerdings noch keine Encoder, die reales Filmmaterial in diese
hochkomrimierte, synthetische Form verwandeln. Das Heinrich Hertz-Institut und die Universität
Hannover forschen gegenwärtig an entsprechenden Verfahren. Die hier als MPEG4 vorgestellten
Codecs von Microsoft enthalten ebenfalls keine der genannten objekorientierten Verfahren. Sie
beschränken sich lediglich auf eine weiterentwickelte, dem ISO-H.263-Verfahren sehr ähnliche
Videokodierung mit erweiterter Fehlertoleranz [33].
Es existieren drei Versionen der MPEG4-Implementierung für Video for Windows von Microsoft und zahlreiche illegale Portierungen unter der Bezeichnung DivX (➜5.9). Die letzte offizielle
Version Microsofts stammt vom 25. Oktober 1999 und trägt den Name MPEG4v3. Die Vorgängerversionen von 1997 sind ein Bestandteil von NetShow [J] und waren auf eine QCIF-Auflösung von
176 x 144 Pixeln beschränkt. Ab Version 3 sind jedoch beliebige Formate bis über PAL hinaus
zulässig. Microsofts aktuellester Codec trägt den Namen Windows Media Video 7 und ist Bestandteil der Windows Media Tools. Die MPEG4-Codecs werden dem ASF-Format und Windows
Media Video dem WMV-Format zugeordnet. DivX-Implementierungen erzeugen hingegen AVIDateien. Wie Microsoft bereits erfolgreich bei einem als "NBC Business Video broadcasting over
the Internet" bezeichneten Event gezeigt hat, eignet sich MPEG4 gut für Internetübertragungen, da
es auch bei sehr niedrigen Datenraten arbeitet. Höhere Datenraten überfordern hingegen meist die
Hardware des Dekodierers. Mit MPEG4 wird TV-Qualität bei Datenraten unterhalb der MPEG2üblichen Werte möglich, jedoch zeigen Performancetests, daß die gegenwärtig verbreitete Hardware dafür noch nicht ausreichend Rechenleistung bietet (➜1.1).
MPEG Audio Codecs
Auf die Audiokodierung in MPEG sei hier nur am Rande verwiesen. Alle Standards,
MPEG1, 2 und 4 enthalten Definitionen zur Audiokodierung mit sehr unterschiedlichen Leistungen
und nutzen im wesentlichen ein psychoakustisches Hörmodell zur Komprimierung. In MPEG1 wird
eine Schichtenstruktur eingeführt, die stellvertretend für eine aufsteigende Komplexität steht und
eine Abwärtskompatibilität der Verfahren gewährleistet. Die erste Schicht, der sogenannte Layer1,
wird durch alle gängigen Softwareplayer unterstützt und besitzt den niedrigsten Kompressionsfaktor. Layer2 findet Anwendung beim Digitalen Radio, beim digitalen Fernsehen und bei der DVD.
Auf Grund geringer Kaskadierungsverluste [19] eignet es sich noch gut für die Produktion von
Tonbeiträgen. Die erforderlichen Datenraten sind zwar geringer als bei Layer1, für Weitverkehrsnetzwerkübertragungen aber immer noch zu hoch. Die dritte und letzte Schicht (Layer3)
ermöglicht den höchsten Kompressionsfaktor und stellt die rechenintensivste Anwendung dar. Da
35
Internet: http://www.iso.ch/isob/switch-engine-cate.pl
- 29 -
DivX
mehrfaches Kodieren hier zu starken Artefakten führt ist es nur für die Endarchivierung oder
Sendung geeignet. Als “MP3” hat dieses Verfahren in sehr kurzer Zeit eine weltweite Verbreitung
gefunden und wird mittlerweile durch immer mehr Endgeräte wie Walkman, Caraudio, Videoplayer,
Spielekonsolen und PDAs unterstützt. Erforderliche Datenraten sind für analoge Modem immer
noch zu hoch, ab ISDN wird aber eine sehr gute Qualität erreicht [A]. Die Standards MPEG2 und 4
erweitern die Möglichkeiten der Audiocodierung um Mehrkanalfähigkeit, objektorientierte
Audiokodierung, Nachbearbeitungsmöglichkeiten und vieles mehr. Daneben existieren noch eine
Vielzahl weiterer Audiocodecs, die teilweise spezialisierte Anwendungsgebiete haben. Es sei hier
auf Advanced Audio Coding (AAC), Windows Media Audio (WMA), RealAudio, Qdesign Music,
CELP und andere verwiesen [A].
5.9
DivX
DivX ist eine illegal portierte Version des Microsoft-MPEG4v3-Codecs, an dem einige
Änderungen vorgenommen wurden. Es wurden zum Beispiel speziell optimierte Codecversionen
für langsam oder schnell bewegte Szenen entwickelt. DivX ist sehr weit verbreitet und trägt ironischerweise denselben Namen wie ein mittlerweile zu den Akten gelegtes Sicherheitssystem für das
Freischalten von DVDs. Es existieren Implementierungen für diverse Plattformen wie BeOS, Linux,
Windows, und MacOS. In einschlägigen Personenkreisen wird er zur Verbreitung von DVDs oder
VHS-Videos verwendent [21]. Dazu werden die in Video Objects (VOB) arrangierten AudioVideodateien von einer DVD-Disc extrahiert36, deren MPEG2-Datenstrom dekodiert und erneut
mittels DivX-Codec komprimiert. Auf der Audioseite findet meist eine Transkodierung von MPEG1L2 5+1 Mehrkanalton (AC3) nach MPEG1-L3 in Stereo statt. Dadurch läßt sich die erforderliche
Datenrate so weit senken, daß ein Spielfilm auf einer einzigen CD-Rom Platz findet. Es entstehen
Kaskadierungsartefakte, die in der Praxis jedoch weit unter den Qualitätseinbußen einer VHSKopie auf analogem Magnetband liegen, sie werden daher meist gern in Kauf genommen. In absehbarer Zeit werden von Privatleuten entwickelte Tools zur Verfügung stehen, die es ermöglichen, ohne viel Sachkenntnis mittels DVD-Rom Laufwerk und Pentiumcomputer "über Nacht" eine
originale DVD auf einen handlichen und äußerst kostengünstigen CD-Rohling zu transferieren.
Mittels Videoschnittstellenkarte und TV-Gerät steht dann dem nichtkommerziellen Austausch von
Videofilmen zumindest technisch nichts mehr im Wege.Bezüglich der rechtlichen Situation sei auf
entsprechende Literatur verwiesen [20].
Ein neuer, aus China stammender Standard ist die Super Video Compact Disk (SVCD).
Diese soll die Vorteile aus den DVD- und VideoCD-Systemen vereinen. Es kommen normale CDRoms als Datenträger zum Einsatz, die mittels MPEG2-Komprimierung und einer PAL-konformen
Auflösung von 480 x 576 Bildpunkten mehr als eine halbe Stunde Video fassen. Sie wird mittlerweile von vielen Endgeräten, vorzugsweise günstigen DVD-Spielern aus Fernost unterstützt.
5.10 RealVideo G2
In der bereits beschriebenen Multimedia Architektur Real System G2 ist ein Real Video
Codec mit skalierbarer Video-Technologie (SVT) integriert. Er unterstützt Bitraten von 24–768
kbps. Eine benutzerdefinierte höhere Bitrate über 1000 kbps hat sich in der Praxis für dieses Verfahren jedoch als dermaßen rechenintensiv erwiesen, daß gängige Rechner damit überfordert sind
36
genannt: ripping, grabben; Dechiffrierung der mit dem Content Scrambling-System (CSS)-Verfahren verschlüsselten Daten
- 30 -
Sorenson Video
[B]. Für Bitraten im ISDN- und DSL-Bereich läßt die Rechenintensität jedoch ein Liveencoding auf
aktuellen Highendmaschinen zu.
Als nachteilig erweist sich, daß das System nicht rückwärtts kompatibel ist und daher immer ein aktueller Player zum Dekodieren benötigt wird. Gegenwärtig in der Version 8 hält Real
Video eine SureStream genannte Eigenschaft bereit, die die Abspielqualität der zur Verfügung
stehenden Verbindungsgeschwindigkeit des Benutzers anpaßt. In einem SureStream können
sowohl mehrere Audio- wie auch Videodatenströme mit sehr unterschiedlichen Eigenschaften
untergebracht werden. Da neben der Bitrate auch alle anderen Parameter individuell zugewiesen
werden können, sind auch thematisch angepaßte Profile denkbar. Als Beispiel könnte das
Streaming einer Vorlesung genannt werden, bei dem ein Teil des SureStreams den vortragenden
Sprecher mit geringerer Bildauflösung und höherer Bildwiederholrate enthält. Im zweiten Stream
könnte die Abbildung der gezeigten Folien inklusive einer Übersetzung der Originalsprache gezeigt
werden. Ein solches Verfahren wurde mittels Windows Media durch das IRT erstmals von der
Tonmeister-Tagung 2000 in Hannover getestet [22]. Ein Student kann dann live oder nachträglich
(OnDemand) die Vorlesung über Netzwerk verfolgen.
5.11 Sorenson Video
Sorenson ist der führende Videocodec von Apples Quicktimearchitektur. Er verwendet eine
weiterentwickelte Art der Vektorquantisierung zusammen mit Motion Compensation, mit der hohe
Kompressionsraten erreicht werden können. Sorenson ist für Datenraten von 16-1600 kbps
geeignet, wobei eine Wiedergabe von CD-Rom mit Datenraten über 800 kbps und Bildgrößen ab
320 x 240 bereits höhere Rechenleistungen erfordert. Er arbeitet somit bei niedrigeren Datenraten
als MPEG2 geeignet und kommt auf Pentium oder PowerMac Rechnern über 120 Mhz zum Einsatz. Im Vergleich zu Cinepak bietet Sorenson eine höhere Qualität bei etwa einem Viertel der
Datenrate. Der Decoder ist eine Standardkomponente des Quicktimeplayers. Er ist im Internet und
bei CD-Rom-Distributionen weit verbreitet und wird sehr häufig für Filmtrailer verwendet [Q]. Der
Sorenson Codec bietet derzeit die umfangreichsten Einstellmöglichkeiten für hochkomprimiertes
Video für den Encodingprozess. Es gibt zwei Encoderversionen, die “Basic Edition” und die “Developer Edition”. Erstere ist in Quicktime 3 und 4 integriert und für die Heimanwendung gedacht.
Sie beinhaltet keine der wichtigen Kontrollmechanismen und Optionen, die ein Produzent für die
Kontrolle des Encodingprozesses benötigt. In Zusammenarbeit mit Terran Interactive wurde in die
"Developper Edition" eine erweiterte Datenratenkontrolle integriert. Dazu gehört auch eine
Kodierung mit variabler Bitrate, die für den OnDemand-Betrieb aus einem Zweifachdurchlauf beim
Encoding erzeugt wird37. So ist die notwendige Bitrate besser an die wechselnden Erfordernisse
einer Videosequenz angepaßt. Nach dem Analysedurchlauf wird dem Datenstrom bei besonders
bewegungsintensiven Abschnitten so mehr Bitrate zugewiesen. Für Video for Windows ist derzeit
kein Sorenson Codec verfügbar, da Apple die Verbreitung von Sorenson auf anderen Architekturen verhindert.
37
auch "2-Pass-Encoding"
- 31 -
Apple Video
Eigenschaften der Entwicklerversion
Temporal Scalability ermöglicht das Abspielen eines Filmes mit hoher Framerate auf
schnellen Rechnern mit automatischer Reduzierung bei ungenügender Rechenleistung. Beispielsweise könnte man ein vollwertiges Video mit 30 fps für Pentiumrechner produzieren. Auf langsameren Maschinen wird die Wiederholrate dann auf 15 fps zurückgenommen, ohne daß sich an der
Bildqualität etwas ändert. Automatische Keyframes werden an Stellen im Film eingesetzt, an
denen Schnitte gesetzt wurden. Wie Cinepak versucht auch der Sorenson Codec Frames zu identifizieren, bei denen neue Szenen beginnen und diese automatisch zu Keyframes zu machen, um
Artekakte zu vermindern. Eine zu große Häufigkeit solcher automatischen Frames vermindert
allerdings generell die Qualität.
Als Media Keys wird ein passwortähnliches Feature von QuickTime bezeichnet. Bei der
Enkodierung kann damit der Zuschauerkreis auf diejenigen eingeschränkt werden, die im Besitz
eines bestimmten Schlüssels sind. Eine weitere Möglichkeit, das Data Rate Tracking, erlaubt eine
genaue Kontrolle der Zieldatenrate. Eine Lockerung dieser Überwachung kann im Falle einer
flexiblen Datenrate jedoch zu höheren Qualitäten führen. Das letzte, als Enhanced Watermarking
bezeichnete Feature prägt dem Clip ein benutzerdefiniertes Label ein, wie es von klassischen TVSendern bekannt ist. Dieses Wasserzeichen wird verlustlos abgespeichert und getrennt zum
Datenstrom am Beginn jeder Streamingsitzung übertragen. Ein "Alphakanal" definiert dabei transparente Bereiche. Dadurch ist auf der einen Seite eine perfekte Rekonstruktion des Labels auch
bei sehr niedrigen Datenraten möglich. Andererseits ist so auch die Möglichkeit einer nachträglichen rückstandsfreien Entfernung gegeben. Nach dem Abschluß der Recherchen für diese Arbeit
wurde von Sorenson bereits die dritte, neue Version ihres Codecs angekündigt.
5.12 Apple Video
Der Apple Video Codec wurde für eine schnellere Kompression und Dekompression bei
Erhaltung einer gewissen Bildqualität entwickelt. Da Apple Video keine interne Datenratensteuerung besitzt, muß für eine Begrenzung der Rate ein zusätzliches Tool wie Media Cleaner Pro [T]
eingesetzt werden. Der Codec erfordert generell höhere Datenraten und ist eher für CD-RomDistributionen als für Internetübertragungen geeignet. Er wird lediglich durch die Multimediaarchitektur Quicktime unterstützt. Zu typischen Einsatzgebieten zählt die Videovorschau in Quicktime-gestützten Entwicklungsumgebungen und ein Abspielen auf älteren Rechnern.
5.13 VDOWave
Dieser waveletbasierte Videocodec der Firma VDOnet38 wurde als NetShow-Produkt von
Microsoft lizensiert. In der produkteigenen Dokumentation und aus externen technischen Berichten
geht hervor, daß in diesem Codec neben dem Waveletalgorithmus auch Motion Compensation
oder Frame Differencing angewendet werden. Es existieren zwei Video for WindowsImplementationen. In der Version 2.0 ist die Bitrate fixiert; die nächste Version erlaubt bereits
Skalierbarkeit. Mit Netshow 2.0 wird ein als "decode-only" bezeichneter Codec installiert, bei dem
die Komprimierungsoption fehlt. Diese ist in Netshow Tools enthalten. Während der Codec selbst
unter dem Namen VDOWave angeboten wird, ist als VDOLive ein LiveEncoding-Produkt verfügbar, das einen Server für OnDemand-Streaming, Bearbeitungstools, eine Captureanwendung und
38
Internet: http://www.vdo.net
- 32 -
Escape Videostudio
einen Player enthält. Außerdem bietet das Produkt VDOPhone die Möglichkeit, in Echtzeit Videokonferenzen zu übertragen.
5.14 Escape Videostudio
Escape Videostudio ist ein neuer Codec von Eidos Technologies, der für die Architekturen
QuickTime, Video for Windows, DirectShow, und Eidos's Eigenentwicklung geeignet ist. Er enkodiert sehr schnell und erreicht auch bei Material mit schnellen Bewegungsabläufen eine gute
Bildqualität. Escape ist eine Alternative zu MPEG, die für plattformübergreifende CD-RomProduktionen genutzt wird. Übliche Datenraten sind mit 5000 kbps oft höher als bei MPEG, benötigen dafür aber weniger Rechenleistung. Ein 100MHz Pentium- oder PowerMac-Processor ist für
eine Komprimierung mit 320 x 240 Punkten und 15 fps bereits ausreichend. Eine explizite
Möglichkeit zur Limitierung der Datenrate existiert nicht. Mit dem speziellen Wiedergabeprogramm
Director Xtra ist eine interpolierte oder monitorangepaßte Vollbildansicht möglich, bei der die
Farbwiedergabe jedoch auf 16 Bit begrenzt bleibt. Die Qualität und Datenrate kann indirekt über
Einstellregler zur "spatial" und "temporal quality" beeinflußt werden. Beim Abspielbetrieb mit doppelter Größe wird jede zweite horizontale Linie durch eine schwarze Linie ersetzt. Dieser Effekt
wird subjektiv häufig positiv wahrgenommen, da keine klassischen Blockingartefakte mehr beobachtet werden können, und senkt die erforderliche Rechenleistung erheblich. Es existiert eine
Windows-Implementation, die ausschließlich AVI-Files generiert. Die Version für das Macintoshsystem erzeugt hingegen nur Quicktimedateien.
5.15 ClearVideo
ClearVideo ist eine Entwicklung der Firma Iterated Systems39, die auch durch Progressive
Networks lizensiert wurde und häufig als RealVideo bezeichnet wird. Dieser Codec arbeitet mit
Video for Windows-Applikationen zusammen und basiert auf einer fraktalen Bildkompression. Der
Enkodierungsprozeß ist allerdings sehr langsam und produziert nur eine dem MPEG1-Standard
leicht überlegene Qualität.
5.16 Andere Codecs
Wie eingangs schon erwähnt, erhebt diese Arbeit keineswegs Anspruch auf Vollständigkeit.
Neben den erläuterten Codecs gibt es ein Reihe weiterer Eigenentwicklungen auch von Herstellern
für Grafikkarten und Schnittstellenkarten. Beispielhaft seien hier Codecs für Kioskpräsentation wie
Apple Animation, Power!Video oder Motion-JPEG (MJPEG) für Capturing genannt. Auch der digitale DV-Standard und schwach komprimierte Component Video Aufzeichnungen (YUV) erfordern
einen eigenen Codec. Diese besitzen eine sehr hohe Datenrate mit Kompressionsfaktoren von 2:1
(YUV) über 5:1 (DV) bis hin zu 10:1 (MJPEG) und eignen sich für linearen Videoschnitt und temporäre Ablage. Sie verursachen bei der Bearbeitung weniger Generationsverluste. Bei MJPEG
wird die AD-Wandlung meistens an der Rechnerschnittstelle durchgeführt, wohingegen Wandlung
und Komprimierung bei DV in der Hardware des Endgerätes realisiert sind. Ein Camcorder überträgt zum Beispiel rein räumlich komprimierte Daten über ein spezielles mehrpoliges Kabel zum
Rechner. Für das Einlesen von unkomprimiertem Video über eine SDI-Schnittstelle ist hingegen
kein Codec, wohl aber ein sehr leistungsfähiges Rechnersystem mit hochratigen Systembussen
erforderlich. Hardware und Capturecodecs, die auf spezielle Schnittstellenhardware angepaßt
39
Internet: http://www.iterated.com
- 33 -
Eigenschaften aktueller Netzwerktechnologien
Das OSI-Referenzmodell
sind, seien hier noch am Rande angemerkt. Media 100, VideoVision Studio, Avid Media Composer
oder Truevision sind nur einige von ihnen.
6
EIGENSCHAFTEN AKTUELLER NETZWERKTECHNOLOGIEN
Damit komprimierte Filmsequenzen einer breiten Öffentlichkeit zugänglich gemacht werden
können, sollen derzeit verfügbare digitale Weitverkehrsnetze, wie beispielsweise das Internet
verwendet werden. Um das Zusammenspiel von übertragenen Videoinhalten und Netzwerktechnologien zu verstehen, wird hier kurz auf die Grundlagen der Netzwerktechnik eingegangen.
6.1 Das OSI-Referenzmodell
Jegliche Kommunikation zwischen zwei Partnern ist an bestimmte Voraussetzungen gebunden. Zum einen muß die Hardware der Partner und der Datenübertragungseinrichtungen über
kompatible Schnittstellen verfügen und zum anderen müssen Vereinbarungen über die Art und
Weise des Informationsaustausches getroffen werden. Diese Regelungen sind in sogenannten
Netzwerkprotokollen, die Bestandteil eines internationalen Standards sind, festgehalten.
Dazu hat die ISO eine Zuordnung der einzelnen Kommunikationsfunktionen zu einem logischen Schichtenmodell getroffen, das 7 Teilbereiche umfaßt. In diesem, Open Systems Interconnection (OSI) genannten Modell steht jede einzelne Schicht in Verbindung zu ihrem Vorgänger.
Physikalisch kommunizieren die Ebenen ausschließlich über diese übereinanderliegenden
Schichtenschnittstellen. Logisch gesehen findet jedoch eine horizontale Kommunikation von einer
Stelle zu ihrer Gegenstelle statt. Die wichtigsten Aufgaben der einzelnen Schichten sollen hier kurz
festgehalten werden. Die Schichten 1 - 4 werden der Transportfunktion zugeordnet und die
Schichten 5 - 7 sind für Anwenderfunktionen gedacht. Jede Schicht kann die zu übertragenden
Daten mit einem eigenen Headerblock versehen, der zur Ablaufsteuerung dieser Schicht dient. Der
Datenblock inklusive Header wird als Datagramm oder Protokoll Data Unit (PDU) bezeichnet und
wird von der übergeordneten Schicht als reine Nutzdaten betrachtet. Keine Schicht kann an dem
Header einer übergeordneten Schicht etwas ändern.
6.1.1 Anwendungsschichten
Die Anwendungsschicht (7-Application) stellt eine Verbindung zum Anwenderprogramm
und Dialog mit den Programmen her. Sie ermöglicht den Austausch von Dateien, elektronische
Post. Die eigentlichen Anwenderprogrammen setzen auf dieser Schicht auf. Die DarstellungsSchicht (6-Presentation) interpretiert die Daten der Anwendungsschicht. Hier findet eine Überwachung des Informationsaustausches und eine erste Kodierung der Daten in Standardcodes40 mit
Formaten und Steuerzeichen statt. In der Kommunikationssteuerungschicht (5-Session) wird der
Aufbau, die Durchführung und die Beendigung einer Verbindung durchgeführt. Dabei erfolgt eine
Überwachung der Betriebsparameter mit Synchronisation, sowie eine Datenfluß-Steuerung und
der Wiederaufbau der Verbindung im Fehlerfall. Bei einer Störung oder Unterbrechung kann diese
Schicht eine erneute Aufnahme des Transfers an einem definierten Punkt veranlassen.
6.1.2 Transportschichten
Die Transportschicht (4-Transport) stellt dem Aufbau der Datenverbindung sicher, daß alle
Datenpakete den richtigen Empfänger erreichen. Sie steuert Datentransport, Flußkontrolle und
enthält eine weitere Fehlerbehandlung. Ab dieser Ebene bleiben alle Netzwerkeigenschaften für
40
z.B. ASCII
- 34 -
Verfügbare Übertragungstechniken
die darüberliegenden Schichten verborgen. Hier werden die Daten in passende Blöcke aufgeteilt,
und es findet eine in fünf Klassen aufgeteilte Flußkontrolle statt. Dadurch soll die Vollständigkeit,
Eindeutigkeit und Reihenfolge der ankommenden Datenblöcke sichergestellt werden. In der Vermittlungs- und Paketschicht (4-Network) sind Mechanismen zur Datenpaketübertragung implementiert. Die Routingwege und das Multiplexen mehrerer Verbindungen über einzelne Teilstrecken
inclusive einer weiteren Datenkontrolle können hier durchgeführt werden. Die Sicherungsschicht
(2-Data Link) überwacht eine Verbindung zweier direkt benachbarter Stationen. Für eine weitere
Regelung des Datentransports und der Synchronisierung werden die Blöcke hier in Datenrahmen
bestimmter Länge unterteilt (Frames)41 und mit Prüfinformationen für die Fehlerbehandlung versehen. Typische Protokolle dieser Schicht sind BSC, HDLC und TCP (➜6.3). Dabei findet die
Flußkontrolle in dieser Schicht bereits in der binären Ebene statt. Zur Steuerung des Datenflusses
mittels wechselseitiger Bestätigung der Gegenstationen kann diese Schicht weiter unterteilt werden. Für lokale Netze existiert noch eine weitere Untergliederung in Media Access Control (MAC)
für den Zugriff auf ein Übertragungsmedium und die Logical Link Control (LLC). Die letzte Schicht
ist für die eigentliche Bitübertragung zuständig (1-Physical). Hier werden die elektrischen, mechanischen und funktionalen Eigenschaften für die physikalische Verbindung zwischen zwei Endpunkten festgelegt. Dazu zählen die Art der Modulation, der Kabelzusammensetzung und der
Steckerbelegungen sowie elektrische Pegeldefinitionen. (vgl.[27],[14])
6.2 Verfügbare Übertragungstechniken
Gegenwärtig sind hauptsächlich fünf Übertragungstechnologien verbreitet. In der Übersicht
aus Abbildung 1 (S.5) wurde bereits die Größenordnug typischer Datenraten angedeutet. Dem am
weitesten verbreiteten analogen Modem kann bei einem nominellen Wert von 56 kbps eine effektive Nettobitrate von 32...48 kbps zugeordnet werden. Hier findet eine Phase-Shift-KeyingModulation (PSK) auf einer herkömmlichen Zweidrahtkupferleitung statt. Dazu ist ein serielles
Modemendgerät42 notwendig, das im Sprachband von 3,1 kHz Bandbreite arbeitet.
ISDN
An zweiter Stelle der am meisten verbreiteten Netzwerkstandards dürfte ISDN genannt
werden, das auf einer Zweidrahtleitung mit digitaler Modulation basiert. Für den Übergang vom
Analogmodem nach ISDN ist sowohl auf der Benutzerseite als auch beim Fernmeldeamt43 eine
Umrüstung der Endeinrichtung (Terminal Equipment, TE) beziehungsweise der Netzabschlußeinheit (Network Termination, NT) notwendig. Mit einem ISDN-Basisanschluß erhält der Benutzer
eine garantierte Bruttodatenrate von insgesamt 192 kbps, die sich laut Standard auf zwei B-Kanäle
mit je 64 kbps und einen D-Kanal mit 16 kbps aufteilt. Der D-Kanal enthält Steuerdaten und ist
demzufolge für die Datenübertragung nicht verfügbar. Bei Nutzung eines einzelnen B-Kanals kann
mit einer nutzbaren Nettorate von 48...56 kbps gerechnet werden. Zusätzlich besteht die
Möglichkeit einer Bündelung der zwei B-Kanäle mit nominell 128 kbps, für die 96 kbps als Richtwert für Streaming empfohlen werden [1].
41
nicht zu verwechseln mit dem Einzelbild einer Videosequenz
auch Terminal Equipment (TE)
43
auch Telekomunikation Service Provider (TSP)
42
- 35 -
Ausgewählte Übertragungsprotokolle
DSL
Der Digital Subscriber Line (DSL)-Standard erlaubt Datenraten bis zu 8 Mbps. Eine Variante mit asynchroner Übertragungstechnik, die ADSL-Verbindung, findet gegenwärtig als Angebot
der deutschen Telekom (TDSL) weitere Verbreitung. Im Standardangebot bietet sie nominell eine
Datenrate von 768 kbps hin zum Benutzer (Downstream) und 128 kbps als Rückkanal (Upstream).
Unter Realbedingungen läßt sich mit dieser Technik immerhin eine Nettobitrate von 500...700 kbps
erreichen [28]. Für professionelle Benutzer stehen unter "Infospeed DSL" weitere Angebote mit
1,6...7,1 Mbps zur Verfügung. Dazu wird die herkömmliche Telefonleitung mit einer QuadraturAmplitudenmodulation (QAM) benutzt, die in Frequenzbändern von mehreren hundert Kilohertz
Breite parallel zum Sprachkanal abläuft.
Mobile Übertragung
Mobile Übertragungssysteme wie GSM und UMTS seien hier nur kurz angesprochen. GSM
ist mittlerweile in fast allen Mobilfunktelefonen für den Versand von Short Messaging Service
(SMS)-Nachrichten implementiert und hat eine Übertragungskapazität von 9600 bps. Es wird von
dem UMTS-Verfahren abgelöst, das im Frequency- oder Time Division Multiplex-Betrieb bis zu 384
kbps bzw. maximal 2 Mbps Übertragungskapazität bietet. Die Werte sind stark von der Sendeleistung und dem Ausbau des in Funkzellen aufgeteilten Sendegebiets abhängig.
Lokale Netze
Bei lokalen Netzwerken (LAN) sind Ethernet mit Twisted Pair-Verkabelung in Sterntopologie oder mit Koaxialkabel in Busstruktur sowie Token Ring verbreitet. Es werden Datenraten von
10/100 Mbps angegeben, die unter Realbedingungen mit mindestens 500 kBps bis rund 5 MBps
auch meistens erreicht werden. Die Übertragungskapazität lokaler Netze übersteigt beispielsweise
mit Gigabit Ethernet (1 Gbps) häufig bereits die Leistung der angeschlossenen Hardware.
Glasfaser
An der Spitze stehen Übertragungswege, die auf mono- und multimodalen Glasfasersystemen basieren und Bandbreiten ab 10 Gbps zur Verfügung stellen. Der SONET-Standard im Wave
Division Multiplex-Verfahren (WDM) kann beispielsweise theoretisch n * 10.000.000 kbps auf einer
einzigen Faser übertragen. Mit "n" ist dabei die Anzahl der gleichzeitig benutzten Wellenlängen
gemeint, die an den Einspeisungs- und Endstellen optisch selektiert werden.
6.3 Ausgewählte Übertragungsprotokolle
IP
Das Internet-Protokoll (IP) ist ein verbindungsloser Dienst, bei dem weder die Richtigkeit
der Daten noch die Einhaltung der Reihenfolge und Vollständigkeit überprüft wird. Diese Prüfungen müssen durch die darüberliegende TCP-Ebene durchgeführt werden. Ein IP-PDU-Protokoll
kann durch ein höheres Protokoll beispielsweise als Ethernetframe weitergegeben werden. In das
IP ist eine Strukturierung in Teilnetze implementiert, die eine Fragmentierung von großen Datenpacken zur Folge hat. Der Header eines IP-Paketes enthält neben der Quell- und Zieladresse auch
die Angabe des übergeordneten Upper Layer-Protokolls (ULP) sowie Felder für die Identifikation,
Fragmentierung und das Routing. Die nächste Version des Internet-Protokolls (IPv6) unterstützt
Multicasting (➜6.5.3) und spezielle Protokolle, die besser an Echtzeitanforderungen angepaßt
sind.
- 36 -
Ausgewählte Übertragungsprotokolle
HTTP
Das Hypertext Transfer Protokoll (HTTP) ist ein verbindungsorientiertes Protokoll der Applikationsschicht, das unabhängig von dem Hardware- und Betriebssystem ist. Zur Adressierung
der Ressourcen werden Uniform Ressource Indicators (URI) verwendet, die im Falles eines Uniform Ressource Locator Orte oder Bezeichner mit Uniform Ressource Numbers (URN) sein können. Der verwendete Übertragungsmechanismus entspricht dem eines Standard Mail-Transports.
HTTP funktioniert nach dem Frage-Antwort-Prinzip. Dazu wird durch einen Browser eine Verbindung zum Server geöffnet, der ihm anschließend eine Statusmeldung zurücksendet. Dieser
folgt eine MIME-artige Nachricht, die das gefragte Dokument und Informationen über den Server
enthalten kann. In der Anfrage muß die Fragemethode, die Protokollversion und die URL enthalten
sein. Sofort nach Beantwortung wird die Verbindung wieder abgebaut. HTTP-Verbindungen können statt auf TCP/IP-Protokollen auch auf anderen Netzwerkprotokollen aufsetzen. Ein vorzeitiger
Abbruch der Kommunikation durch den Benutzer einer Seite oder einen Programmfehler wird in
HTTP durch den Abbruch der gesamten Kommunikationsbeziehung quittiert.
UDP
Das User Datagram Protocol (UDP) ist ein einfaches verbindungsloses Protokoll der
Netzwerkschicht. Es stellt eine Transportbeziehung ohne Flußkontrolle und Überprüfung der
Zustellung her. Mit UDP können mehrere unabhängige Kommunikationsbeziehungen44 zwischen
zwei Stationen hergestellt werden. Portnummern dienen der Identifikation der gegenseitigen
Kommuninkationsstellen, die bekannten Anwendungen fest zugeordnet sind. Es wird häufig für
Echtzeit-Audio- und Videoübertragungen verwendet, bei denen verlorene Pakete schlicht ignoriert
werden können.
TCP
Das Transmission Control Protocol (TCP) arbeitet verbindungsorientiert und stellt gesicherte Übertragungen im Internet bereit, bei denen die Vollständigkeit und Reihenfolge der Daten
garantiert ist. Es wird der vierten Schicht des OSI-Modells zugeordnet und beinhaltet Rückmeldungen und Wiederholung fehlerhafter Blöcke. Viele Standardanwendungen verschiedener Betriebssysteme nutzen TCP und das darunterliegende IP als Transportprotokoll unter dem Namen
"TCP/IP". TCP wird in lokalen und weltweiten Netzen eingesetzt. Die Flußkontrolle ist dem HDLCVerfahren ähnlich und erfolgt mittels Fenstergröße und Quittierung. Beim Verbindungsaufbau
werden die Modalitäten der Übertragung wie Fenstergröße, und das Akzeptieren eines bestimmten
Dienstes ausgehandelt. Wie bei UDP findet eine Identifizierung durch Ports statt. Eine TCPÜbertragungseinheit wird als Segment bezeichnet, dessen Header sehr umfangreich ist. In ihm ist
auch eine Durchnumerierung von mehreren Datenpaketen enthalten, die zu einer Übertragung
gehören. Neben jeder notwendigen Empfangsbestätigung für eine solche Nummer wird eine Prüfsumme gesendet. Durch das Warten auf die Empfangsbestätigung können Verzögerungen auftreten, die es für Echtzeitübertragungen von Multimediainhalten mit hoher Fehlertoleranz eher
ungeeignet macht. (vgl. [27])
ATM
Der Asynchronous Transfer Mode (ATM) ist ein verbindungsorientiertes Protokoll für
Hochgeschwindigkeits-Paketvermittlung. Es ist auf die Übertragung von Daten, Text, Sprache und
Bildern optimiert. ATM verwendet dazu ein Fast Paket Switching (FPS)-Verfahren. Es existiert ein
44
auch Multiplex-Verbindungen
- 37 -
Netzwerke und Multimedia
eigenes Standardisierungsgremium, das ATM-Forum. Ein ATM-Header enthält ein Kontrollfeld, in
dem anstatt der expliziten Quell- und Zieladressen virtuelle Pfade und ein virtueller Kanal angegeben werden. Sie existieren nur für die Dauer der Datenübertragung. Anwendungen, die eine hohe
Kapazität beanspruchen werden mehrere virtuelle Kanäle gleichzeitig zugeteilt. Ein virtueller Kanal
kann bei ATM verschiedene virtuelle Pfade durchwechseln. ATM eignet sich sehr gut alle Multimediadistributionsmöglichkeiten von OnDemand- oder Live-Streaming bis hin zu Filedownload. Da
sich bei den Endverbrauchern jedoch hauptsächlich das Internet- Protokoll etabliert hat, kommt
ATM hauptsächlich im Produktionsbereich bei hohen Bitraten zum Einsatz [5].
RTP & RTCP
Das Realtime Transport Protocol (RTP) bietet wichtige Echtzeiterweiterungen zum IPProtokoll, wie etwa Zeitstempel und Synchronisierungsmechanismen, die für Video-Übertragungen
erforderlich sind. Anhand der Sequenznummern lassen sich auch fehlende oder außer der Reihe
angekommene Pakete identifizieren. Für Kontrollaufgaben definiert RTP zusätzlich das Realtime
Transport Control Protocol (RTCP). Typische Anwendungsgebiete von RTP sind Internet-Telefonie
und Audio- beziehungsweise Videokonferenzschaltungen mit oder ohne Multicast-Erweiterungen.
RSVP
RTP unternimmt jedoch keine Anstrengungen, eine bestimmte Dienstqualität sicherzustellen. Dies ist Aufgabe einer anderen IP-Erweiterung namens ReSerVation Protocol (RSVP). Über
RSVP kann ein Host eine bestimmte Verbindungsqualität45 beantragen. Daraufhin versucht eine
als RSVP-Daemon bezeichnete Instanz, auf allen Netzwerkknoten zwischen Sender und Empfänger entsprechende Ressourcen zu reservieren. (vgl. [26], [27], [14])
6.4 Netzwerke und Multimedia
Wie eingangs schon dargestellt, wird die Schnittstelle zwischen Multimediainhalten und installierten Netzwerken durch eine Multimediaarchitektur realisiert. Sie ermöglicht es, Ton- und
Bildinhalte, die entweder zeitgleich von einem Capturingprozess geliefert werden oder einer abgelegten Datei entstammen, an eine Netzwerkschnittstelle zu übergeben.
Bei allen Übertragungstechniken handelt es sich um Paketorientierte Verfahren. Da Multimediainhalte wie Filme oder Ton auf Rechnern grundsätzlich sequentiell verarbeitet werden,
bietet sich eine Netzwerkübertragung an. Die im Capturingprozeß und bei der Kompression durchgeführte Segmentierung der kodierten Audio- und Videoinformationen kann durch ein angepaßtes
Netzwerkprotokoll auch für die Übertragung beibehalten werden [5]. Eine Multimediaarchitektur
versieht nun diese Datensegmente mit weiteren Verwaltungsinformationen wie Netzwerkadressen
oder Fehlerkorrekturdaten. Sie verwendet dazu die im Betriebssystem installierten Hardwarekomponenten und Netzwerkprotokolle. Nach dem OSI-Referenzmodell werden diese Zusatzinformationen als Header an den Kopf jedes Datenpaketes gehängt. Sie entsprechen der Norm des verwendeten Netzwerkprotokolls.
6.5 Webcasting Technologien
Gegenüber dem klassischen Rundfunk und Fernsehen erweist sich die Verbreitung von Ton und
Film im Internet an viele Empfänger als wesentlich komplizierter. Für eine Versorgung großer
Mengen von Zuschauern über das paketvermittelte Netz gibt es verschiedene Ansätze, die hier
45
auch Quality of Service (QoS)
- 38 -
Webcasting Technologien
kurz aufgezeigt werden sollen. Ein Sendeverfahren für Streaminginhalte in paketorientierten
Netzwerken – ein Broadcasting im Netz – wird als Webcasting bezeichnet.
6.5.1 Transfer
Download
Den einfachsten Transfer von Daten zum Benutzer stellt der Download dar. Die Daten in
Form einer Datei werden durch das Protokoll in Netzwerkpakete mit vorangestelltem Header
zerteilt. Erst wenn die Datei vollständig in den Speicher des Empfängers geladen wurde, kann mit
der Dekodierung begonnen werden. Da diese Anwendung nicht zeitkritisch ist, kommt es in erster
Linie auf eine gesicherte Übertragung an. Daher kommen in erster Linie verbindungsorientierte
Protokolle, wie das File Transfer Protocol (FTP), HTTP, TCP oder ein zeitversetzter E-MailVersand zum Einsatz. Auch TCP/IP wird im Multimediabereich häufig zum Filedownload eingesetzt.
Progressiver download
Bei dem progressiven Verfahren kann der Inhalt bereits während des Transfers betrachtet werden.
Der Datenstrom wird in Form einer Datei via HTTP, FTP oder UDP-Protokoll aus dem Netzwerk
auf den lokalen Rechner transferiert. Der Benutzer muß nicht wie beim einfachen Download das
Ende des Transfers abwarten, bevor er den Inhalt beurteilen kann. Es wird keine Anpassung der
Datenrate an die Bandbreite der Benutzerverbindung vorgenommen. Liegt jedoch die Leistung der
Verbindung unter der gewählten Medienqualität, so kommt es durch wiederholte Zwischenpufferungsphasen zu Wartezeiten beim Abspielen. Dieser Umstand wird in Kauf genommen, da der
Focus nicht auf der Betrachtung, sondern auf dem Verbleib des angeforderten Inhalts auf dem
lokalen Speicher des Benutzers liegt. Progressiver Download ist für kurze, qualitativ hochwertige
Filmsequenzen wie zum Beispiel Spielfilmteaser46 geeignet [W].
6.5.2 Streaming
Mit Streaming wird eine paketorientierte Netzwerkübertragung von sequentiell organisierten
Multimediainhalten bezeichnet. Eine Streamingverbindung kann verbindungslos oder verbindungsorientiert ablaufen, wobei spätestens in der Applikationsschicht eine Flußkontrolle stattfinden
muß.
OnDemand-Streaming
"Streaming auf Abruf" oder OnDemand-Streaming erlaubt es dem Betrachter, ausgewählte Beiträge zu einem beliebigen Zeitpunkt anzufordern und innerhalb des Beitrags an bestimmte Stellen
zu navigieren. Beim OnDemand-Streaming wird im Gegensatz zum progressiven Download die
Kodierungsqualität des Audio-Videostroms den Anforderungen der Netzwerkverbindung angepaßt.
Ob der übertragene Inhalt jedoch beim Benutzer für eine weitere Offlinebenutzung verbleibt, liegt
in dem Ermessen des Contentproviders. Er kann bei der Produktion den Nutzungsbereich genau
definieren. Es sei jedoch daraufhingewiesen, daß es auf Softwareebene für Eingeweihte immer
möglich sein wird, diese Restriktionen zu umgehen Fehler! Verweisquelle konnte nicht gefunden werden..
Life Streaming
Beim Life Streaming wird ein Multimediainhalt in Echtzeit mit einer gewissen Verzögerung
vom Sender zum Empfänger übertragen. Ein Benutzer kann sich zu einem beliebigen Zeitpunkt
46
Kurzvorschau auf einen Spielfilm, vgl. Trailer
- 39 -
dem laufenden Datenstrom zuschalten. Zu Beginn der Übertragung werden die Modalitäten der
Verbindung ausgehandelt, die eine Anpassung der zu übertragenden Kodierungsqualität an die
Anforderungen der Netzwerkverbindung ermöglicht. Wie bereits in Abbildung 5, S.18 (Netzwerk
Broadcasting, Ablauf) gezeigt, ist dazu neben dem Encoder ein dedizierter Server für die Verteilung nötig. Falls die Verbindung des Benutzers nicht leistungsfähig genug ist oder es auf dem
Netzwerk zu Überlastungen kommt, kann während der Übertragung auf einen Alternativdatenstrom
niedrigerer Kodierungsqualität ausgewichen werden. Außerdem können durch den Empfänger
ganze Frames ausgelassen47 werden, um eine sich kumulierende Verzögerung bezüglich der
Livequelle zu verhindern. Bei dieser Form des Streaming werden besondere Anforderungen an die
Hardware gestellt. Nach dem Capturing müssen die Video- und Audiodaten unkomprimiert vorliegen, da der Encoder sonst eine Transkodierung durchführen müßte, die weitere Rechenleistung
beansprucht. Dieser zunächst trivial erscheinende Umstand ist jedoch gegenwärtig das Haupthindernis bei der Einrichtung eines Streamingsystems, da die einzige digitale, nicht datenreduzierte
Schnittstelle SDI aus dem Profibereich ist. Selbst analoge Videoschnittstellenkarten kommen meist
nicht in Frage, da sie, was die Hardware betrifft, auf MJPEG komprimieren. Immerhin sind erste
Karten auf dem Markt48, die unkomprimiertes digitales Audio nach dem Sony Phillips Digital Interchange Format und SDI-Schnittstellen enthalten. Einige wenige können sogar ein DCTkomprimiertes DV-Signal, was die Hardware betrifft, in Echtzeit dekodieren und auf dem PCI-Bus
ausgeben. Life Streaming wird für aufgezeichnete Filme mit hoher Spieldauer oder Live-Events
verwendet.
6.5.3 Unicast
Unicast ist ein Verfahren, das Streaming-Video und ähnliche Verfahren in IP-Netzen
benutzt. Dabei werden jedem, der einen Datenstrom anfordert, individuelle Kopien derselben
Datenpakete gesendet. Es besteht also für jeden Empfänger eine Punkt-zu-Punkt-Übertragung
zum Sender. Das bedeutet, dass ein Server für Großveranstaltungen mit mehreren tausend Teilnehmern auch das Tausendfache einer einzelnen Videoübertragung an Bandbreite bereitstellen
muß. Dieses Verfahren ist demnach nur für Live-Ausstrahlungen von wenigen niedrigratigen
Datenströmen oder für OnDemand-Video geeignet, bei dem sich die Last zeitlich aufteilt. Fernsehoder Radiosender kosten im Betrieb hingegen gleich viel, unabhängig davon, ob nur ein oder eine
Million Zuschauer teilnehmen.
6.5.4 Multicast
Daher ist gegenwärtig ein Verfahren in Entwicklung, das die Eigenschaften der analogen
Medienverbreitung auf digitale Netze übertragen soll. Dieses Multicastverfahren ist jedoch im
Vergleich zur analogen unidirektionalen Funkaussendung um ein Vielfaches komplexer.
Da es unwirtschaftlich ist, die gleichen Daten wie bei Unicast mehrfach über dieselbe Leitung zu schicken, soll das Netz selbst die Pakete für jeden Zuhörer vervielfältigen. Diese Aufgabe
wird den Schnittstellen im Netzwerk, den Routern, zugeschrieben. Diese Vervielfältigung soll so
nahe wie möglich beim Empfänger geschehen49. Außerdem wird natürlich kein Datenpaket gesendet, das keinen empfangswilligen Adressaten hat. Das Multicastkonzept kann als Protokoll in
verschiedenen Schichten implementiert werden und funktioniert in groben Zügen folgendermaßen:
47
genannt: frame dropping
z.B. Osprey, Internet: http://www.viewcast.com
49
Ein Router leitet Datenpakete in Netzwerksegmenten anhand von Routingtabellen weiter in Richtung des Empfängers
48
- 40 -
Ein Empfänger abonniert Gruppen von speziellen IP-Adressen beim lokalen Router. Dieser
fragt wiederum beim nächsten Router nach, ob er die Gruppen führt. Ein spezielles Paket (Prune)
dient als Nachricht des Empfängers zur Organisation der Adressgruppen. Es wird ein Rendezvous
Point (RP) eingeführt, bei welchem die Empfänger nachfragen können, welcher Sender eine gewünschte Gruppe führt. Dieser Vorgang ist dem Aufbau einer dynamischen Baumstruktur vergleichbar und dient letztlich der direkten Routenfindung. Bei dichten Multicast-Netzen (Dense
Mode) liegen die Empfänger nahe beieinander, und Router haben eine relativ hohe Zahl von Teilnehmern zu bedienen. Bei spärlich verteilten Empfängern hingegegen (Sparse Mode) muss jeder
Router nur wenige Teilnehmer bedienen, dafür liegen alle Empfänger einer Multicast-Gruppe
räumlich weit verteilt.
Gegenwärtig wird versucht, Multicast in der Protokollhierarchie sehr weit unten auf der IPEbene umzusetzen. Obwohl Multicast hauptsächlich für Multimedia entwickelt wurde, sind auch
ganz andere Möglichkeiten wie Newsticker, Mailinglisten oder Push-Dienste für den Abgleich
replizierter Datenbestände auf verteilten Webservern denkbar. Zudem könnte Multicast den Punktzu-Punkt-Transportmechanismus für VPNs ablösen. An einem Ethernetbus stellt die Verteilung
von Multicast-Daten kein Problem dar, da alle Empfänger alle Datagramme sehen und sich die
interessierenden herausfiltern können. In sich selbstorganisierenden Netzen wie dem Internet
hingegen muß eine lückenlose Kette von Multicastroutern bestehen. Dazu ist eine teure Umrüstung der Netzknoten notwendig.
Für manche Anwendungen wie zum Beispiel das elektronische Börsenparkett ist zudem die
Zuverlässigkeit wichtig. Die Minimierung der Übertragungsfehler wird mit "Reliable Multicast" und
dem Multicast File Transfer Protocol (MFTP) versucht. Dabei kommt einer Router-Assistenz zum
Einsatz, die fehlende Pakete nachbestellt. Router müssen dazu auf dem Übertragungsweg Pakete
zwischenspeichern können, was nur bei Dateiübertragungen, nicht aber für Livesendungen funktioniert. (vgl. [23] [24] [25] [26])
Protokolle, Streaming & Codecs
In der Praxis ergibt sich die Wahl einer Streamingart und des Protokolls aus der Anwendung. Dabei werden die audiovisuellen Qualitätsanforderungen an den Codec gestellt und der
Contentprovider bestimmt Broadcastingform und Protokolle. UDP wird zum Beispiel bei EchtzeitAudio- und Videoübertragungen angewendet, bei denen verlorene Pakete schlicht ignoriert werden
können. Windows Media bietet die Wahl zwischen UDP- und HTTP-Streaming. Es sei allerdings
angemerkt, daß bei UDP-Streaming aus einem LAN ins Internet die Firewalls50 speziell konfiguriert
werden müssen. HTTP hingegen unterstützen praktisch alle Schnittstellen im Netz standardmäßig.
ATM eignet sich für alle Multimediadistributionsmöglichkeiten von OnDemand oder Live-Streaming
bis hin zu Filedownload. Da sich bei den Endverbrauchern jedoch hauptsächlich das InternetProtokoll etabliert hat, kommt ATM hauptsächlich im Produktionsbereich bei hohen Bitraten zum
Einsatz [5]. Bei TCP können durch das Warten auf die Empfangsbestätigung Verzögerungen
auftreten, die es für Echtzeitübertragungen von Multimediainhalten mit hoher Fehlertoleranz eher
ungeeignet macht.
Verschiedene Codecs sind unterschiedlich gut für Streaming geeignet. Die WindowsMedia-Encoder-Anwendung kann theoretisch alle registrierten Codecs zu Streamingzwecken
einbinden. Es hat sich jedoch gezeigt, daß die meisten architekturfremden Codecs für Liveencoding zu Fehlermeldungen führen. Der Grund hierfür ist vermutlich in der Nicht-Übereinstimmung von
50
Sicherheitsschnittstelle für die Verbindung eines firmeninternen Intranet zum weltweiten Internet
- 41 -
Untersuchung der Bildqualität bei unterschiedlichen Netzzugängen
Video Internet Demonstration Aid
Videosegment- und Netzwerkpaketgrößen zu suchen. Sorenson Video benötigt zur Netzwerkanbindung den Sorenson Broadcaster mit dedizierter Hardware und beim Realsystem ist der Algorithmus durch den Real Producer Plus festgelegt. Intel's Indeo Interactive Streamingsoftware ist
nur sehr wenig verbreitet. VivoActive benötigt einen eigenen Player und wird nicht mehr weiterentwickelt. Daher scheint sich der Markt in Zukunft auf die zwei Hauptkonkurrenten Microsoft und
Real Networks zu konzentrieren.
Der klassische Broadcastingfall mit einem Sender mit sehr vielen Empfängern ist zumindest
in der Theorie gelöst. Anstatt Fernsehgeräten mit Netzwerkanschluss werden sich aller Voraussicht nach entsprechend ausgerüstete Set-Top-Boxen als Standaloneanwendung etablieren. In der
Praxis scheitert die kommerzielle Nutzung von Multicast in Deutschland dagegen derzeit an
Internet Service Providern (ISP), die einen MBone-Zugang anbieten.
7 UNTERSUCHUNG DER BILDQUALITÄT BEI
UNTERSCHIEDLICHEN NETZZUGÄNGEN
Im folgenden soll die Bildqualität der Verfahren bei unterschiedlichen Netzzugängen untersucht werden. Dabei wird die Ausgabe eines Videos nach einem EnkodierungsDekodierungszyklus in Echtzeit begutachtet. Man unterscheidet zwischen subjektiver und objektiver Bildqualität. Die objektive Bildqualität umfaßt Bildstörungen wie Artefakte oder Fehler in der
Farbwiedergabe. Zusätzlich werden Meßgrößen wie PSNR oder MSE eingesetzt. Zur subjektiven
Beurteilung wird üblicherweise eine repräsentative Gruppe von Testpersonen herangezogen. Sie
müssen in mehreren Prozeduren nach einer sogenannten Trainingsphase unterschiedliche
Testsignale, sogenannte Stimuli beurteilen. Dabei werden die präsentierten Sequenzen nach einer
genormten Skala verglichen. Sowohl subjektive als auch objektive Standard-Testverfahren gehen
bislang grundsätzlich von der PAL- oder NTSC-Norm als Referenz aus. Die Präsentation erfolgt
über ausgewählte Bildschirmgeräte. Objektive Messungen beziehen sich auf bestimmte Schnittstellen. Hier wird als einziger Parameter die Bitrate des Videosignals variiert. Alle anderen Einstellungen wie die Bilddimensionen oder die Bildwiederholfrequenz sind hingegen festgelegt.
Für Videokodierung mit Bitraten unter 2 Mbps müssen auch diese Parameter variiert werden. Je weniger Bitrate zur Verfügung steht, desto kleinere Bilddimensionen und geringere
Wiederholfrequenzen werden verwendet. Sogar die Anzahl darstellbarer Farben und die Toninformation werden reduziert. Somit ist offensichtlich, daß die einschlägigen Verfahren also für niedrige
Bitraten nicht geeignet sind. Daher wurde für diese Arbeit eine eigene Demonstrationsumgebung
entwickelt. Ziel war es, eine Oberfläche zu schaffen, die es dem Benutzer ermöglicht, interaktiv
bestimmte Videosequenzen auszuwählen und miteinander zu vergleichen. Als bestimmende
Größen sollten die absolute Bitrate, die Komplexität der Filminformationen und verschiedene Kompressionsverfahren mit eingehen.
7.1 Video Internet Demonstration Aid
Das Video Internet Demonstration Aid (VID@) ist eine HTML-basierte Benutzerschnittstelle,
die mit Standard-HTML-Browseranwendungen wie dem Netscape Communicator oder einem
Microsoft Internet Explorer verwendet werden kann. Er stellt eine Weiterentwicklung des am IRT
entwickelten Audio Internet Demonstration Aids (AIDA) dar. Zusatzfunktionen wurden in Javascript
realisiert. Als Multimediasysteme werden die kostenfreien Player von Windows Media, Real System und Apple Quicktime mitgeliefert. Neben der Betrachtung der Videoinhalte stellt VID@ dem
- 42 -
Realisierung
Benutzer umfangreiche Informationen und Quellenangaben hinsichtlich des zugrundegelegten
Filmmaterials und der verwendeten Kompression zur Verfügung. Der Benutzer kann auf dem
eigenen Rechner unter Realbedingungen selbst individuelle Tests an verschiedenen Videosystemen durchführen. Es wird ihm so ein Hilfsmittel für die persönliche Urteilsfindung über die Benutzerfreundlichkeit und die Leistung gegenwärtig verfügbarer Systeme an die Hand gegeben. Mittels
Zusatzinformationen und Quellenverweisen ist eine detailliertere Recherche oder der direkte Bezug eines favorisierten Systems möglich.
7.2 Realisierung
Eine repräsentative Vorauswahl an Videosequenzen erfolgte durch die EBU [C]. Diese
Videosequenzen zeichnen sich durch unterschiedliche Merkmale in Hinblick auf Objektvielvalt,
Bewegungsrichtung, Farbvielfalt und Geschwindigkeit aus. Sie wurden bereits für offizielle objektive und subjektive Tests des MPEG2-Verfahrens [11], [12] verwendet und sind bei der Video
Quality Experts Group (VQEG) [D] zum Download freigegeben.
7.2.1 Quellenmaterial
Als Ausgangsformat dient sowohl PAL-, als auch NTSC-konformes Filmmaterial mit einer
Farbunterabtastung von 4:2:2 im YUV-Format. Bei einer Farbquantisierung mit 8 Bit trägt eine
Bildzeile damit insgesamt 720 Helligkeitswerte Y, 360 Blau-Gelb-Balancewerte Cb und 360 RotGrün-Balancewerte CR. Dadurch ergeben sich 1440 Bytes an Bildinformation für eine Bildschirmzeile. Die Bildauflösungen betragen für PAL 720 x 576 Pixel und für NTSC 720 x 486 Pixel. Das
mit 525@60Hz bezeichnete NTSC-Material hat dabei eine Bildwiederholrate von 30 Frames pro
Sekunde und das 625@50Hz PAL Material weist 25 Frames pro Sekunde auf. Eine Sequenz hat
eine Dauer von 8 Sekunden und beansprucht dabei 182 MB an Speicherplatz. Um eine Synchronisierung der Codecs sicherzustellen, sind jeder Sequenz 10 unbenutzte Frames voran- und nachgestellt. Damit ergibt sich eine Dauer von 260 Frames für NTSC- und 220 Frames für PAL-Material.
NTSC
PAL
525@60Hz Framegröße =
625@50Hz Framegröße =
1440 x 486 ➜ 699.840 Bytes pro Frame
1440 x 576 ➜ 829.440 Bytes pro Frame
NTSC
PAL
525@60Hz 8 Sekunden Video =
625@50Hz 8 Sekunden Video =
699840 x 260 Frames ➜ 181.958.400 Bytes
829440 x 220 Frames ➜ 182.476.800 Bytes
Diese Sequenzen wurden zunächst für die Videokodierung vorbereitet. Zunächst wurde
eine Konvertierung in Standard Audiovideointerleave Dateien (AVI) durchgeführt. Dazu sind aus
den einzelnen Sequenzen alle Einzelbilder extrahiert [E], diese anschließend in einem Stapelverarbeitungsprozzess einer Deinterlacingfilterung unterzogen [F] und wieder zu einer Bildsequenz
zusammengesetzt worden [G]. Bei der Einzelbildextraktion erfolgte zwangsweise eine Formatumwandlung vom YUV-Farbmodell mit 4:2:2 Unterabtastung der 8 Bit-Komponenten in Echtfarben
RGB mit 16 Bit Quantisierungstiefe je Pixel. Dadurch entstand eine unkomprimierte AVI-Datei, und
das Datenvolumen hat sich verdoppelt. Abschließend wurde dem Videomaterial noch eine StereoTonspur mit 44.1 kHz Abtastrate und 16 Bit Quantisierung aufgeprägt [H]. Sie ist notwendig, da
viele Codecs zwar reine Audiofiles, nicht aber Videodateien ohne Audiospur generieren können.
Die Audioinformation dient also lediglich der Vollständigkeit, soll aber nicht als Testkriterium mit
eingehen. Bei 8 Sekunden Spieldauer kann jedoch nur ein grober Eindruck über die Synchronität
von Ton- und Bildinformationen gegeben werden. Für die sogenannte Lippensynchronität zwis- 43 -
Realisierung
chen Ton und Bild sei hier auf weitere Tests mit Sequenzenlängen ab 30 Minuten Spieldauer
verwiesen.
7.2.2 Parameterprofile
Um den Anforderungen verschiedener Netzzugänge gerecht zu werden, wurden fünf
Parameterprofile definiert, die sowohl Übertragungseigenschaften wie auch Bild- und Toneinstellungen festlegen.51 Es wurden fünf häufig anzutreffende Netzwerktechnologien wie das analoge
Modem, der digitale ISDN-Zugang, die gegenwärtig auszubauende DSL-Technik und das in Firmen verbreitete lokale LAN-Netzwerk ausgewählt. Auch die Möglichkeit, zwei Datenkanäle einer
ISDN-Leitung logisch zu einem Zugang zusammenzuschalten, wurde berücksichtigt. Stellvertretend für diese Technologien wurde jeweils eine effektive Datenrate festgelegt, die bei einer
durchschnittlichen Leitungsqualität zwischen Endstelle und Internet Service Provider während des
Verbindungsaufbaus ausgehandelt wird. Die Profile ANALOG, ISDN, DUAL, DSL und LAN stehen
stellvertretend für eine effektive Datenrate von 40, 56, 112, 300 und 1000 Kilobit pro Sekunde.
Bild- und Toneinstellungen müssen an diese Übertragungskapazitäten angepaßt sein. Neben der Zuteilung der verfügbaren Datenrate für Video- und Audiodatenströme sind für jedes Profil
eigene Bildauflösungen, Bildwiederholraten und Kompressionseinstellungen definiert. Eine detaillierte Aufstellung dieser Parameter ist dem Anhang zu entnehmen. Die Bezeichnungen der Profile
werden im folgenden stellvertretend für die Benutzung jener Einstellungen verwendet. Bilddimensionen richten sich nach dem genormten Standard Image Format (SIF)52. Entsprechend der zugrundeliegenden Fernsehnorm des Quellmaterials wurden auch bei kleineren Bildformaten die
Seitenverhältnisse von rund 1,25 für NTSC und 1,5 für PAL verwendet.
Aus Kompatibilitätsgründen sind nur bestimmte Kombinationen zwischen Audio- und Videocodecs möglich. Da die vorgegebenen Parameter für die Audiokodierung nicht immer eingehalten werden konnten, soll die Tonqualität hier nur bezüglich der Synchronität zur Videoinformation
eine Rolle spielen.
51
52
siehe Anhang
auch Common Image Format (CIF)
- 44 -
Realisierung
7.2.3 Design
Die Designspezifikation in Abbildung 7 gibt einen Einblick in das Funktionsprinzip des
Demonstrators. Nach dem Start wird die Indexseite in den Browser geladen und ermöglicht die
Auswahl eines bestimmten Netzwerkprofils. Hat der Benutzer eine Auswahl getroffen, so aktualisiert sich automatisch die Sequenztabelle. Sie stellt die Zugangsmöglichkeit zu einer Datenbank
dar, in der viele kodierte Videosequenzen strukturiert abgelegt sind.
Abbildung 7: VIDA, Designspezifikation
Als Sortierkriterien dienen die kodierte Bitrate, die Nummer der Originalsequenz zum einen
und der verwendete Codec zum anderen. Für ihre Identifizierung wurden die von Microsoft eingeführten Four Character Codes verwendet53. Für die volle Funktionalität wird eine Installation aller
notwendigen Decoder und Player beim Benutzer vorausgesetzt. Da die Videosequenzen bereits
bei der Entwicklung des Demonstrators in komprimierter Form entsprechend der Parameterprofile
in die Datenbank abgelegt wurden, ist eine Encoderinstallation nicht notwendig. Wird in der Sequenztabelle ein Icon durch den Benutzer angeklickt, so übergibt der Browser eine Dateizugriffsanforderung an das Betriebssystem. Dieses versucht nun eine mit dem Dateityp dieser Anforderung verknüpfte Anwendung zu starten. Nach erfolgreichem Start der Playeranwendung wird
dieser die angeforderte Videodatei aus der Sequenzdatenbank übergeben. Neben den eigentlichen Sequenzen enthält die Datenbank auch Diagramme, die einen Einblick in die Kodierungseigenschaften eines Codecs zulassen (➜6.1). Diese werden in einem eigenen Fenster im Falle
eines Klicks mit der rechten Maustaste auf ein Sequenzicon angezeigt. Zusätzlich stehen diverse
zusätzliche Seiten zur Verfügung, die über Codecs und Quellen informieren. Eine Vorschau zeigt
Standbilder der einzelnen Sequenzen.
53 siehe Anhang
- 45 -
Realisierung
7.2.4 Komponenten
Für eine übersichtliche Oberflächengestaltung reicht der Funktionsumfang der Hyper Text
Markup Language (HTML) nicht aus. Daher wurden den HTML-Seiten zusätzliche Funktionalitäten
in JAVA-Skript angefügt. Der Übersichtlichkeit halber wurden sie in eigene Dateien ausgelagert.
Die Realisierung der drei Hauptkomponenten soll hier erläutert werden. Die Javascriptdatei
MAIN.JS wird zusammen mit jeder Sequenztabelle geladen und enthält folgende fünf Unterfunktionen:
MAIN.JS
function
function
function
function
function
changeRightclick();
dispInfo(cat,file);
URLfilename();
statusMsg(msgNo);
chartInfo(msgNo,file); //v2.0
Mit der Funktion changeRightclick() werden Klicks mit der rechten Maustaste abgefangen und an die Funktion dispInfo(cat,file) übergeben. Dadurch erhält der Benutzer
anstatt des durch den HTML-Browser angebotenen Kontextmenüs eine kontextsenitive Statusinformation. Je nachdem, ob auf ein entsprechendes Icon oder in einen freien Bereich geklickt wird,
wird ein Bitratendiagramm in die Seite chartTMP.HTM geladen oder ein Benutzerhinweis
angezeigt.
Die Unterscheidung zwischen diesen zwei Möglichkeiten wird durch die Funktion
dispInfo(cat,file)vorgenommen. Diese kann ein neues, leeres Fenster erzeugen, das festgelegte Eigenschaften besitzt. Der Aufrufparameter cat bestimmt die Kategorie des neuen Fensters. Je nachdem, ob in dem neuen Fenster Informationen zu Codecs und Sequenzen, ein Diagramm oder Bilder angezeigt werden sollen, wird eine bestimmte Fensterhöhe und -breite
eingestellt. Der Übersichtlichkeit halber werden sämtliche Steuerelemente des Fensters verborgen.
Zusätzlich wird ein globaler Zugriffspfad festgelegt. Über ein Window-Handle, das dem Browser
übergeben wird, überprüft die Funktion, ob bereits ein Fenster geöffnet ist, und schließt dieses bei
Bedarf.
Mittels der Funktion URLfilename() wird der Dateiname zur aktiven HTML-Seite ermittelt
und bei Anforderung eines Bitratendiagramms an die JAVA-Scriptroutine der chartTMP.HTM
Datei übergeben. In der Funktion statusMsg(msgNo) werden verschiedenen Mausereignissen
bestimmte vordefinierte Benutzerhinweise zugeordnet. Die Funktion chartInfo(msgNo,file)
dient lediglich der Kompatibilität zu HTML-Browsern älterer Bauart.
In der JAVA-Scriptdatei SELECT.JS sind zwei Funktionen enthalten, die den Symbolwechsel in der Netzwerkprofilauswahlleiste regeln.
SELECT.JS
function initIcons();
function changeIcon(imgName,newImg,swap);
Nach einer Initialisierung von zwei Arraystrukturen durch die Funktion initIcons(), werden diese mit Pfad und Dateinamen der zugehörigen Icondateien belegt. In der Funktion
changeIcon(imgName,newImg,swap) wird das Verhalten der Knopfsymbole in der Selektionsleiste festgelegt. Mit dem Eingabeparameter imgName wird eine Icongruppe anhand ihres zugehörigen Profilnamens referiert, wobei newImg das Array-Element des neuen Icons angibt. Der
Parameter swap gibt an, ob im Falle eines Klicks "0" ein Wechsel des aktuellen und ein Rücksetzen des zuvor gewählten Knopfes vorgenommen werden soll. Einem onMouseOver-Ereignis "1"
- 46 -
Realisierung
folgt ein temporärer Symbolwechsel und onMouseClick "2" erzeugt eine bleibende Veränderung
eines Knopfes. Je nach Benutzerauswahl eines in select.htm bestimmten Knopfes wird die
entsprechende Sequenztabellenseite in das Hauptfenster geladen.
Sequenztabelle
Die Tabelle ist intern der Reihenfolge nach Sequenzen und innerhalb einer Sequenz nach Codecs
aufgebaut. Die Grundstruktur hat folgenden Eintragungen:
Sequenzauswahl
ana.htm | isdn.htm | dual.htm | lan.htm | high.htm
<a href="Media/WinMedia/40k/WNM7_19.wmv"
onMouseover="chartInfo(4,1);return document.msgFLG"
onMouseout="chartInfo(0,0)">
<img src="icons/seq_525.GIF" alt="MS Media Video7" boder="0"></a>
Codecinformationen
<a href="javaScript:dispInfo('codec','cod_WNM7.htm')"
onMouseover="statusMsg(2);return document.msgFLG"
MS<br>Media<br>Video7</a>
Sequenzvorschau
<a href="javaScript:dispInfo('pic525','clip_19.htm')"
onMouseover="statusMsg(3);return document.msgFLG"
<img src="pics/clip_19_mini.JPG" border="0"></a>
Als Hauptfunktionselement ist der Aufruf einer Sequenz in einfachem HTML gehalten, um
Benutzer mit älteren Browserversionen nicht auszuschließen. Lediglich zusätzliche Statusinformationen sind in JAVA-Script realisiert. Die Codecinformationen und Sequenzvorschau finden über
die dispInfo(cat,file)-Funktion statt, die alle Fensterparameter dem Inhalt entsprechend
anpaßt. Eine Besonderheit stellt der Aufruf des Bitratendiagramms mit der rechten Maustaste dar.
Dessen Kontext, also der Diagrammname zur entsprechenden Sequenz, wird nämlich bei jedem
onMouseOver-Event eines Sequenzicons mit der chartInfo-Funktion als globale Variable erzeugt.
ChartTMP.htm
title = "BITRATEOVERVIEW - Sequence#" + seqNumber + " coded by "+ codName;
document.write('<title>' + title + '</title>');
document.write('<IMG SRC="' + path + '">');
Zur Anzeige eines Framediagramms zum entsprechenden Clip wird die HTML-Seite
chartTMP.htm benützt. Sie stellt ein Template dar, dessen Inhalt mit JAVA-Script aktiv generiert
wird. Mit der dokument.write-Methode wird so die Titelzeile und der Bildinhalt dieser Seite zur
Laufzeit kontextsensitiv bezüglich des gewählten Icons erzeugt. Für die Darstellung des Diagramms wird zusätzlich analog zum aufgerufenen Parameterprofil der Sequenztabelle ein Zugriffspfad festgelegt. Die aktiv erzeugte Titelzeile enthält neben der Sequenznummer des angeklickten Icons auch den zugrundeliegenden Codec und stellt so den Bezug zum Diagrammbild her:
7.2.5 Sequenzkodierung
Die Kodierung der Quellsequenzen erfolgte in der jeweils codeceigenen Applikation. Für
MPEG4v3 kamen die Microsoft Netshow Tools 4.1, für Windows Media der Windows Media Encoder 7, für das Real G2 System der Real Producer Pro 6.0 und für Real v8 der Real Producer
Plus 8.0 zum Einsatz. Die MPEG1- und MPEG2-Codierungen wurden mit dem Darim Vision Software Encoder 5.0 verwendet. Bei Sorenson Video kam der Sorenson Codec, Developper Edition
v3 unter Apple Quicktime Pro zum Einsatz und als H.263-Repräsentant wurde der in Quicktime
- 47 -
Benutzung
Pro integrierte Codec von Apple verwendet. Die restlichen Sequenzen für Intel Indeo, DivX und
VDO Wave wurden unter Terran Media Cleaner als AVI-Dateien kodiert, wobei die jeweils
neuesten Versionen der Videocodecs direkt von den Anbietern Intel und VDOnet bezogen wurden.
Eine Ausnahme bildet die illegale Portierung DivX, die hier zu Versuchszwecken von einem nichtkommerziellen Anbieter bezogen wurde.
7.3 Benutzung
7.3.1 Installation
Die notwendigen Dateien stehen zur Onlinebenutzung via HTTP auf einem Server des IRT
zur Verfügung und werden auf Wunsch in beschränkten Stückzahlen als kostenlose Demo-CDRom ausgegeben. Außerdem ist ein Download der kodierten Sequenzen per FTP möglich. Nachdem der Demonstrator das erste Mal gestartet wird, müssen eventuell nicht vorhandene Player
und einige Codecs im Betriebssystem installiert werden. Möchte man die gegenwärtige Multimediafähigkeit des eigenen Systems testen, ist es aber auch möglich, das Startprogramm
auszuführen und zunächst entsprechende Installationshinweise zu übergehen. Da viele Betriebssysteme wie MacOS, Linux und Windows bereits Codecs und Player enthalten, ist mindestens
eine Teilfunktionalität gegeben. Es wird auch darauf verwiesen, nach der Installation entsprechende Voreinstellungen zu treffen, um eine optimierte und vergleichbare Wiedergabequalität der
verschiedenen Player zu gewährleisten.
7.3.2 Netzwerkeigenschaften
Nachdem der Benutzer die Indexseite des Demonstrators geöffnet hat, stehen ihm verschiedene Auswahlmöglichkeiten zur Verfügung. Analog zu den vorher definierten Parameterprofilen hat er die Möglichkeit, einen von
fünf Netzzugängen auszuwählen. Es sei angemerkt, daß die
Übertragung und damit auch deren Eigenschaften je nach
Verwendung des Demonstrators nur simuliert ist. Wird er von
einem CD-Rom Laufwerk auf einem lokalen Rechner
gestartet, kommt keine reale Netzwerkverbindung zustande.
In diesem Fall wird die Übertragungsbandbreite
ausschließlich durch die bei der Enkodierung festgelegte
Datenrate bestimmt. Auch wenn der Benutzer Videosequenzen über eine TCP/IP-Internetverbindung vom Server des
IRT anfordert, werden diese zunächst lokal im temporären
Speicher des Rechners (Cache) abgelegt, bevor sie an den
Player weitergegeben und durch diesen visualisiert werden.
Abbildung 8: Selektion, Netzwerkprofil
Es findet also in keinem Fall Live-Streaming statt. Dieser Umstand ist bewußt gewählt, um
für alle Benutzer möglichst gleiche Bedingungen zu schaffen, da die Verbindungsqualitäten abhängig vom gewählten ISP und der aktuellen Netzauslastung sehr unterschiedlich sein können.
Außerdem ist die Demonstration so vom tatsächlich installierten Netzwerk unabhängig. Dementsprechend kann auch ein ISDN-Nutzer nach einem etwas längeren Datentransfer die Videoqualität
eines DSL-Zugangs testen. Durch einen Mausklick wird das entsprechende Profil aktiviert und die
Inhaltstabelle wird entsprechend aktualisiert.
- 48 -
Benutzung
7.3.3 Sequenztabelle
Dem Benutzer präsentieren sich diese Sequencen in einer großen Sequenztabelle. Sie
stellt eine Übersicht des verfügbaren Materials dar und bietet Zugang zu zusätzlichen Informationen. Die Spalten zeigen Symbole stellvertretend für die kodierten Videosequenzen, wobei der
Spaltenkopf über den benutzten Videocodec Auskunft gibt. In den Zeilen wird zwischen den Quellsequenzen unterscheiden, wobei die Symbole Auskunft über das Bildseitenverhältnis geben. Icons
mit der Bezeichnung 625 verweisen auf die in Europa gebräuchliche PAL-Fernsehnorm mit 576
sichtbaren Bildschirmzeilen und 525 deutet auf das in Amerika verbreitete NTSC-System mit 486
sichtbaren Zeilen hin.
Abbildung 9: Demonstrator, Sequenztabelle
Beim Klick auf ein Sequenzicon wird ein im Betriebssystem registrierter Player gestartet
und die Sequenz abgespielt. Neben einer Voransicht der Sequenzen durch Klick auf das Miniaturbild in der rechten Spalte kann der Benutzer detaillierte Informationen zum Quellmaterial und den
verwendeten Codecs abrufen, indem er den entsprechenden Zeilen- oder Spaltenkopf anwählt.
Die bereitgestellten Codecinformationen beinhalten die zugehörige Multimediaarchitektur, den
verwendeten Komprimierungsalgorithmus, die Versionbezeichnung, einen passenden Audiocodec,
die Indentifizierung im Betriebssystem und Quellverweise zum Hersteller. Sequenzinformationen
geben Auskunft über Name, Dauer, Videoformat, Farbsystem, Fileformat, Audioabtastung und den
Ursprung der Sequenz. Hilfestellung bietet ein Fragezeichen in der rechten oberen Ecke. Benutzt
der Tester die rechte Maustaste beim Klick auf ein Sequenzsymbol, erhält er detailiertere Informationen bezüglich der Bitratenzuteilung zur entsprechenden Sequenz (➜6.1).
7.3.4 Informationen
Die vorher erläuterten Parameterprofile sind am unteren Ende jeder Sequenztabelle angegeben. Sie geben Auskunft über die Bitrate und deren Aufteilung. Im Beispiel der Abbildung 10
entfallen von einem Megabit Gesamtdatenrate 800 Kilobit auf den Video- und 160 Kilobit auf den
Audiodatenstrom. Die Bildwiederholrate beträgt hier volle 25 bzw. 30 Frames pro Sekunde, wobei
jedes zehnte Frame als Intraframe kodiert wurde. Im Falle eines NTSC-Ausgangsmaterials wurde
- 49 -
Benutzung
eine Auflösung von 480 x 324 Bildpunkten verwendet. Neben den Audioeigenschaften wie Samplingfrequenz, Abtatsttiefe und Kanalanzahl wird der Kompressionsfaktor mit 112:1 angegeben. Er
errechnet sich aus dem Verhältnis zwischen der komprimierten Datenrate von 1 Mbps und der
Datenrate des äquivalenten Ausgangsmaterials. Da in diesem Beispiel mit einer geringeren Auflösung kodiert wurde, als im Original, muß die Quelldatenrate um einen entsprechenden Wert
korrigiert werden. Dementsprechend steht im Beispiel der reduzierten Datenrate eine Quellrate von
112 Mbps oder 14 MBps bezogen auf ein Ursprungsmaterial von 480 x 324 Bildpunkten (NTSC).
Abbildung 10: Sequenztabelle, Kodierungsparameter
Abschließend sind noch die Anforderungen an Speicherkapazität zu dem aktiven Profil
angegeben. Umgerechnet würde eine Standard-CD-Rom mit 650 MB Kapazität beispielsweise
rund 90 Minuten Video dieser Kompressionsstufe aufnehmen. Das entspricht einer Rate von 120
kBps, die beispielsweise für aktuelle CD-Rom-Laufwerke mit Raten ab 4•150kBps kein Problem
darstellt. Im Vergleich dazu würde eine CD-Rom unkomprimiert lediglich 45 Sekunden aufnehmen
und ein Abspielen bei einer geforderten Rate um 14 MBps ist selbst für die schnellsten Laufwerke
dieses Medientyps unmöglich. Ein Sequenzicon mit rotem Kreuz bedeutet, daß eine Codierung mit
diesem Parametersatz beim entsprechenden Codec aus technischen Gründen nicht durchführbar
war. Beispielsweise ließ sich der H.263-Codec nicht auf eine Datenrate von 1000 kbps einstellen,
da er zu Videokonferenzzwecken via ISDN-Leitung entwickelt wurde, welche weit unterhalb dieser
Datenrate betrieben wird.
- 50 -
Benutzung
7.3.5 Bitratendiagramm
Wie vorher erläutert, erhält der Benutzer, wenn er mit der rechten Maustaste auf ein Sequenzsymbol klickt, ein Diagramm [H], das den zeitlichen Verlauf der Bitrate wiedergibt. Das ist
insbesondere dann von Interesse, wenn eine Sequenz während des Abspielens Fehler aufweist.
Teilweise ist es möglich, Ausreißer im Diagrammverlauf so den Abspieleigenschaften zuzuordnen
und Probleme spezieller Codecs auszumachen.
Das in Abbildung 11
dargestellte Diagramm zeigt
den Verlauf eines acht
Sekunden dauernden Bilddatenstroms einer Videosequenz. Im hier vorliegenden
Fall einer für ISDN kodierten
Sequenz mit 10 Frames pro
Sekunde ergeben sich insgesamt 80 Frames.
Abbildung 11: Bitratendiagramm, Erläuterung
Dieser Wert kann je nach Codec und Sequenz um ca. 10% vom rechnerischen abweichen.
Die roten Balken geben dabei die Samplegröße eines Intraframes, die blauen diejenigen eines
Deltaframes wieder. Der vorliegende Codec kommt also bei über 80 Frames mit nur zwei I-Frames
aus. Da mit einem I-Frame immer ein komplettes, DCT-komprimiertes Bild übertragen wird,
benötigt dieses, wie aus der Balkenhöhe ersichtlich, grundsätzlich mehr Bitrate als ein Deltaframe.
An der rechten Skala ist abzulesen, daß das erste Keyframe mit ca. 2 KB ein absolutes Maximum
des Graphen darstellt. Dieses Extremum ist auch bei anderen Sequenzen bestimmter Codecs zu
beobachten. In der sogenannten "Preload"-Phase füllt der Decoder vor dem Abspielen einer Sequenz seinen Pufferspeicher. Da der Zuschauer während dieser Zeit warten muß, wird dann häufig
das erste I-Frame als Standbild gezeigt. Dieser Prozedur wird durch bestimmte Codecs bereits bei
der Enkodierung Rechnung getragen, indem dem ersten Frame ein Überhang zugeteilt wird. Treten während der laufenden Übertragung Verzögerungen auf, so können diese mit der Reserve aus
dem Speicher ausgeglichen werden. Diese Pufferung setzt eine zur Kodierungsrate leicht erhöhte
Übertragungsrate voraus und bedingt eine Verzögerung zwischen gesendetem und abgespieltem
Signal. In der rechten Diagrammhälfte sind Lücken zu beobachten, in denen die erwarteten Deltaframes fehlen. Da eine reale Szene zwar geringe, aber permanente regionale Bildveränderungen
aufweist, kann bei solchen Verläufen normalerweise von Kodierungsfehlern ausgegangen werden.
Im vorliegenden Fall kann der Player auf Grund der fehlenden Information die Framerate nicht
aufrechterhalten. Dadurch wird der flüssige Bewegungsablauf unterbrochen, und das Bild bleibt
zeitweise stehen. Eine weiße Linie zeigt die mittlere Datenrate, welche sich an der linken Skala
ablesen läßt, wobei der Gesamtmittelwert durch eine waagrechte rote Linie gekennzeichnet wird.
Bei der vorliegenden, für ISDN kodierten Sequenz wurde eine Bitrate von 56 kbps bzw. 7 kBps
gefordert. Dieser Wert wurde im Gesamtmittel unterboten, bei zwei lokalen Maximas allerdings
überschritten. Mit einer standardmäßigen Pufferung von 5 Sekunden bei der hier verwendeten
Bitrate ergibt sich eine Kapazität von ca. 35 KB beim Player. Ein solcher Puffer würde die Überschreitungen der geforderten Bitrate durch den Encoder im vorliegenden Fall bei einer konstanten
Netzwerkbitrate von 7 kBps ausgleichen.
- 51 -
Untersuchung der Rechenintensität ausgewählter Verfahren
8
Serverseitige Enkodierung
UNTERSUCHUNG DER RECHENINTENSITÄT AUSGEWÄHLTER
VERFAHREN
Nachdem bislang die Funktionalität der verschiedenen Verfahren untersucht wurde, soll
das Augenmerk nun auf die Rechenintensität fallen. Dazu wurde ein Benchmarking54 durchgeführt,
bei dem die benötigte Rechenzeit für die Komprimierung einer bestimmten Filmsequenz eines
ausgewählten Codecs untersucht wurde. Als Referenzcomputer diente hierbei ein Intel Pentium III
System, getaktet mit 500 Mhz intern und 100 Mhz Speichertakt55.
8.1
Zunächst wird die Rechenzeit gemessen, die ein Encoder braucht, welcher auf der Produktionsseite beim Server installiert ist. Die Codecparameter wurden hier für Liveencodinganforderungen optimiert. Spezielle Filter wurden deaktiviert und grundsätzlich das Singlepass-Verfahren
angewendet. Das heißt, der Encoder benötigt nur einen Durchlauf für eine Videosequenz und
versucht eine konstante Datenrate zu gewährleisten (CBR). Die Tests wurden bei drei festen
Bitraten durchgeführt, wobei die Parameter den weiter oben definierten Profilen entsprechen. Um
die Komplexität der Codecs gegenüberzustellen, wurden die vier in Tabelle 7 dargestellten
Videosequenzen ausgewählt.
#15, Mobile & Calendar
#16, Animation
#19, Football
#20, Susie On The Phone
Tabelle 7: Testsequenzen, Auswahl
Die Sequenz No.15 "Mobile & Calendar" enthält Bewegung in zwei Hauptrichtungen, stark
saturierte Farben und eine extrem hohe Detaildichte. Sequenz No.16 ist eine synthetisch generierte Animation mit langsamer Bewegung in zwei Hauptebenen, Kamerazoom und sehr weichen
Farbübergängen mit scharfen Konturen. In Sequenz No.19 "Football" finden schnelle Bewegungen
in mehreren Richtungen mit Kameraschwenk statt, wogegen No.20 "Susie On The Phone" eine
typische Talking-Head-Situation darstellt, wie sie häufig bei Nachrichten oder Diskussionsrunden
auftritt. Hier passieren nur sehr langsame, auf bestimmte Bereiche begrenzte Bewegungen bei
feststehender Kamera. Zudem tritt nur eine begrenzte Anzahl an Farben auf.
54
55
dt. Leistungsmessung
genannt: Ram Bustakt
- 52 -
8.1.1 ISDN
Hier wurde eine Gesamtbitrate von nur 56 kbps gewählt, wobei 8 kbps auf die
Audioinformation und 48 kbps auf die Videoinformation enfallen. Bei einer Auflösung von 240x162
Punkten wurde eine Bildwiederholfrequenz von 10 fps gefordert.
48
50
45
40
35
30
encoding
25
time [sec]
20
#15 Mobile & Calendar
#16 Animation
#19 Football
#21 On The Phone
17
15
10
5
0
MS MPEG4v3
MS Media
Video7
Real Video
v8
Sorenson
Apple H.263
Videocodec
Abbildung 12: Dauer der Enkodierung von 8 Sekunden NTSC Video
für ISDN auf einem PIII-500 Windows98 System
Die Kodierung der 8 Sekunden langen Sequenzen dauerte maximal 48 Sekunden beim
H.263-Codec und minimal 17 Sekunden bei Microsofts MPEG4v3-Codec. Es ist auch ersichtlich,
daß eine Liveencodierung für ISDN nicht in Frage kommt, da kein Codec auf diesem System
einere geringere Zeit als 8 Sekunden benötigte. Trotz der unterschiedlichen Eigenschaften des
Videomaterials weißt lediglich der H.263-Codec leichte Differenzen zwischen den Sequenzen auf.
Erwartungsgemäß benötigte die Szene mit den meisten Details No.15, am meisten Zeit, und No.21
mit wenig zeitlichen Veränderungen am wenigsten Zeit.
8.1.2 DSL
Hier wurde eine Bitrate von 300 kbps gewählt, wobei 64 kbps auf die Audio- und 240 kbps
auf den Videodatenstrom entfallen. Bei einer Auflösung von 352 x 240 Punkten (SIF) war eine
Bildwiederholfrequenz von 20 fps gefordert.
160
145
140
120
100
encoding
time [sec]
#16 Animation
#19 Football
#21 On The Phone
80
60
40
22
20
0
MS MPEG4v3
MS Media
Video7
Real Video
v8
Sorenson
Apple H.263
Videocodec
für DSL auf einem PIII-500 Windows98 System
- 53 -
Die Rangfolge der Codecs hat sich im Vergleich zur niedrigeren Datenrate bei ISDN nicht
geändert, wohl aber die absolute Kodierungsdauer. Wieder benötigt der H.263-Codec von Apple
mit 145 Sekunden am längsten, gefolgt von Sorenson, Real und Microsoft. Während sich die
Kodierungsdauer der Microsoftcodecs durch die Steigerung von 56 kbps auf 300 kbps nur
geringfügig erhöhte, kann man bei Sorenson von einer Verdopplung und beim H.263-Codec von
nahezu einer Verdreifachung der benötigten Zeit sprechen. Außerdem bereiten dem Apple-Codec
höhere Bitraten bei Szenen mit schnellen Bewegungen offensichtlich mehr Probleme als viele
Bilddetails, während die Animation und die Talking-Head-Situation mit Sorenson gleichauf liegen.
Für dieses Profil ist eine Liveencodierung auf einem 500 Mhz-Pentium also noch weniger geeignet.
8.1.3 LAN
Dem Profil für lokale Netze wurde eine Bitrate von rund 1 Mbps zugrundegelegt, wobei 800
kbps auf den Audio- und 160 kbps auf den Videodatenstrom enfallen. Die Auflösung beträgt 480 x
324 Punkte und die Bildwiederholfrequenz hat für das NTSC Material bereits volle 30 fps. Der
H.263-Codec ist bei dieser Messung nicht mehr enthalten, da dessen maximal zulässige Bitrate
analog dem H.261 Standard bei 384 kbps liegt (➜5.6).
172
180
160
140
120
encoding 100
time [sec] 80
#16 Animation
#19 Football
#21 On The Phone
60
40
31
20
0
MS MPEG-4v3
MS Media
Video7
Real Video v8
Sorenson
Videocodec
für LAN auf einem PIII-500 Windows98 System
Der Trend der vorherigen Messungen setzt sich auch bei einer Bitrate von einem Megabit
fort. Die Codecrangfolge bleibt gleich und während die Steigerungen von Microsoft und Real
bezüglich der geringeren Bitraten im linearen Bereich bleiben, verdoppelt Sorenson wiederum die
erforderliche Rechenleistung. Ein bestimmter Mechanismus des Sorensoncodec scheint also eine
zur Bitrate exponentiell ansteigende Rechenzeit zu verursachen.
8.1.4 Livebetrieb
Nachdem in den bisherigen Messungen auf Dateibasis offline enkodiert wurde, sollen nun
Streamingbedingungen untersucht werden. Dazu wurde der Windows Media Encoder 7 mit altem
und neuem Codec auf einem Doppel-Pentium System mit 866 Mhz mit einer Osprey-500 Capturingkarte betrieben. Als Videoquelle diente ein S-VHS-Recorder, der ein für Livestreaming typisches aufgezeichnetes Signal56 auf S-Video mit getrenntem analogen Luminanz- / Chrominanzsignal ausgibt. Es kamen die sechs bekannten Bitratenprofile Analog, ISDN, DUAL, DSL und LAN
mit Bitraten von 40 kbps bis 1 Mbps zum Einsatz. Außerdem wurden zwei Multibitratenströme
56
hier: Livemitschnitt eines Konzertsaales mit DV-Kamera
- 54 -
(intelligent Streams) betrachtet, deren Bitraten 40..56 kbps und 112..300 kbps mit 8 kbps und 32
kbps für Audio betrugen. Als Bildauflösung wurde QCIF und CIF gewählt.
Intelligent Streams:
MULTI1:40,56 | 8kbps Audio | (QCIF)
MULTI2:112,300 | 32kbps Audio | (CIF)
Abbildung 15: CPU-Auslastung einer Liveenkodierung von PAL Video
auf einem dual PIII-866 Windows2000 System
Analog zu den Offlinemessungen kann man erkennen, daß der MPEG4v3-Codec wiederum
geringfügig weniger Rechenleistung verbraucht als Windows Media. Bei den CPU-Daten handelt
es sich um Durchschnittswerte. Mit einem Dual-Pentium-Prozessor können Zielgruppen57 mit
Modem und ISDN und auch Benutzer einer DSL-Verbindung also problemlos bedient werden.
DSL-Benutzer empfangen dabei immerhin bereits 352 x 288 Punkte Auflösung und Stereoton mit
44.1 kHz. Bei der Enkodierung von hochratigem Video stellt eine Bildgröße von 480 x 324 Punkten
mit 25 fps die Obergrenze des Machbaren dar. Vollwertige PAL-Qualität wird mit Rechenleistungen
unter 1 Ghz also noch nicht in Echtzeit erreicht.
57
auch Target Audience
- 55 -
8.2
Clientseitige Dekodierung
Clientseitige Dekodierung
In der Anwendung des Demonstrators (VIDA) mit unterschiedlichen Rechnerkonfigurationen hat sich gezeigt, daß auch an den Playoutrechner bestimmte Hardwareanforderungen
gestellt werden müssen. Dabei spielen alle Hardwarekomponenten, die Prozessorgeschwindigkeit,
die Grafikkarte, die Grafikbeschleunigungschipsätze, die Multimediaerweiterung des Prozessors,
der PCI-Bus und die RAM-Busparameter sowie der Zugriff auf die Speichermedien eine Rolle.
Anhand einer Beobachtung der benötigten Rechenkapazität eines Pentiumsystems mit 800 Mhz
läßt sich folgender Trend erkennen:
Abbildung 16: CPU-Auslastung beim Abspielen von NTSC Video
auf einem PIII-800 Windows2000 System
Das Decoding von niedrigratigem Video, wie es für ISDN oder DSL bis 300 kbps benötigt
wird, stellt auf der benutzten Rechnerarchitektur bei keinem Kodierungsverfahren ein Problem dar.
Weniger komplexe Verfahren wie MPEG1 und MPEG2 erzielen bei sehr hohen Datenraten ab 2
Mbps mit höheren Bildqualitäten gute Ergebnisse. Dagegen erfordern komplexere neuere Verfahren wie Windows Media, MPEG4 und DivX bei mittleren Datenraten um 1,5 Mbps und gleich
hohen Bildparametern eine extrem hohe Rechenleistung. Ist diese nicht vorhanden, kommt es zu
Inkonsistenzen im Bildablauf (Ruckler), die bei den einfacheren MPEG-Verfahren nicht auftreten.
Dort werden dafür Artefakte deutlicher sichtbar. Andere Verfahren wie Real Video sind schlicht
nicht für Datenraten über 1 Mbps ausgelegt und verursachen ebenfalls einen Einbruch der Bildwiederholrate.
Weitere Stichprobentests lassen den Schluß zu, daß mit aktuellen Verfahren wie Windows
Media mittlerweile auch bei Datenraten um 1 Mbps PAL-Fernsehqualität erreicht werden kann,
sofern genug Rechenleistung zur Verfügung steht. Diese liegt allerdings mit mindestens rund 800
Mhz noch über der Leistungsfähigkeit eines älteren Desktoprechners. Wie bei allen Datenkompressionsformen gilt also auch hier das Prinzip: Ein Datenvolumen läßt sich grundsätzlich in weiten
Grenzen reduzieren, wodurch sich aber der Aufwand beim Wiederherstellungsprozesses erhöht.
Wird bei Video- und Audioanwendungen Echtzeitfähigkeit gefordert, so müssen die Anforderungen
der Algorithmen an den technischen Fortschritt angepaßt werden.
- 56 -
Auswirkungen einer gestörten Übertragung
9
9.1
Mögliche Ursachen von Übertragungsfehlern
AUSWIRKUNGEN EINER GESTÖRTEN ÜBERTRAGUNG
Mögliche Ursachen von Übertragungsfehlern
Als Übertragung wird hier der Transport des kompletten Multimediainhalts von einer Quelle,
dem Produktionsort, bis zur Senke, dem Endbenutzer, angesehen. Grundvoraussetzung ist, daß
alle beteiligten Komponenten die durch den OSI-Standard geforderten Betriebsbedingungen einhalten und daß eingesetzten Protokolle und Formate kompatibel sind. Die Ursache für gestörte
Übertragung ist an drei Stellen zu suchen: Bei der Produktion seitens des Service Providers, auf
dem Übertragungsweg der Netzwerk Provider und bei der Ausstattung des Kunden selbst. Beim
Netzwerk kann es speziell im Unicastbetrieb zu einer Überlastung des Servers kommen.
Wenn zu viele Benutzer versuchen, auf einen Datenstrom gleichzeitig zuzugreifen, sinkt die
individuelle Datenrate. Im Extremfall kommt es dazu, daß Verbindungsanforderungen nach einem
Timeout gelöscht oder sogar bestehende Beziehungen beendet werden. Die Echtzeitanforderung
an Livevideo wird dann schnell unterschritten. Störungen einer logischen Netzwerkverbindung
können durch eine Überlastung der Netzknoten hervorgerufen werden. Wenn alle Ports eines
Routers im Netzwerksegment belegt sind und der Routingalgorithmus keinen Alternativweg mehr
findet, wird bereits der Aufbau zur gewünschten Adresse mit einer Fehlermeldung quittiert. Bei
einer etablierten Verbindung kann es durch Störungen auf dem Kabelweg zu Paketverlusten oder
Vertauschungen von deren Reihenfolgen kommen. Bei einem ungesicherten UDP-Streaming
werden die falschen Pakete nicht erneut angefordert. Die betreffenden Informationen fehlen dann
auch in einer lokal abgelegten Kopie des Datenstroms. HTTP-Streaming beendet die Kommunikation komplett, wenn eine fehlerhafte Übertragung oder ein Timeout auftritt. Das führt dazu, daß die
Verbindung inklusive Preloadphase jedesmal wieder neu aufgebaut werden muß. Auf der Seite
des Konsumenten kann es bei älteren Rechnern zur Überlastung des Systems kommen. Wie
jedoch aus Abbildung 1, S.56 (Netzwerke & Videostandards, typische Datenraten) hervorgeht, ist
dieser Fall aufgrund der niedrigen Bandbreiten eher seltener anzutreffen. Eine letzte mögliche
Fehlerquelle im Sinne der hier definierten Übertragung ist die Inkompatibilität der Decoding- oder
Netzwerkkomponenten zum gelieferten Datenstrom. Häufig wird der Benutzer zu einer erneuten
Playerinstallation oder einem Codec- bzw. Plugindownload aufgefordert.
9.2
Auswirkung auf die Bild- und Tonübertragung
Die Auswirkungen von Übertragungsfehlern sind neben dem Netzwerkprotokoll auch stark
vom verwendeten Codec und der Architektur oder dem Player abhängig. Während sich die Tonwiedergabe bei allen Architekturen als fehlerrobust herausgestellt hat, ist die Bildwiedergabe
bereits anfällig für einen kurzzeitigen Einbruch der Datenrate. Bis auf Real, wo mittels Prioritätenregelung auch dem Bild Vorrang gewährt werden kann, läuft der Ton meist ungestört synchron zur
Übertragung, während es beim Video zu Aussetzern oder einem gänzlich stehenden Bild kommt.
Fehlende Pakete verursachen beim Ton fast immer "Gluckser", die maximal im Zehntelsekundenbereich liegen. Fängt das Video zu "ruckeln" an, kommt es hingegen trotz hoch gewählten Wiederholraten schnell zu Aussetzern von mehreren Sekunden. Manche Architekturen wie Real verfügen
über Eingriffsmöglichkeiten zum Ergreifen von Gegenmaßnamen, die dann zwar die Framerate
aufrechterhalten, aber in bewegten Bereichen extreme Unschärfen erzeugen. Der SorensonCodec hingegen erzeugt einen pulsierenden Detailverlust mit starken Blockingartefakten, wenn die
Datenrate einen bestimmten Wert unterschreitet. Bei Sequenzen mit Spielfilmlänge beginnt spe- 57 -
Auswirkungen einer gestörten Übertragung
Kompensationsmöglichkeiten
ziell bei höheren Bitraten mit Windows Media, die Bild-Tonabstimmung (Lippensynchronität)
auseinanderzudriften. Der DivX-Codec trägt diesem Umstand immerhin mit einer Nachregelung ab
einem Maximalwert an Divergenz Rechnung. Er korrigiert dann beim Abspielen den Zeitabstand,
indem er den quasi hinterherhinkenden Film für kurze Zeit mit doppelter Geschwindigkeit ablaufen
läßt.
9.3
Um Übertragungsfehler zu vermeiden, können folgende Maßnahmen ergriffen werden:
Prinzipiell ist es möglich, für Streaming den Encoder und Serverprozeß auf einem Rechner laufen
zu lassen. Gerade bei Livestreaming ist aber in höchstem Grade davon abzuraten. Besser ist ein
Encoderrechner mit möglichst hoher Rechenleistung und ein Netzwerkserver mit noch höherer
Bandbreite. Außerdem ist ein ISP mit möglichst guter Backbone auszuwählen. Bei der Enkodierung sollten die sehr unterschiedlichen Einstellungsmöglichkeiten des Codec und der Architektur ausgenützt werden. Sorenson bietet zum Beispiel eine Spike-Suppression-Funktion, die
bereits bei der Enkodierung einer gleichmäßigen Datenrate Rechnung trägt. Bei den Kodierungen
zu VIDA hat sich herausgestellt, daß die wenigen Codecs, die Variable Bitrate Encoding (VBR)
anbieten, meist schwer dazu zu bringen sind, das eingestellte Maximum dann auch einzuhalten.
Die normale Qualitätseinstellung gibt es fast bei jedem Codec. Sie kann von "clearer Image" bis
"smother Action" variiert werden und arbeitet sehr effektiv. Sie ist der entsprechenden Anwendung
anzupassen. Für ein Präsentationsstreaming sind beispielsweise andere Parameter als bei einem
Konzertmitschnitt zu wählen. Bei Real sollte die Prioritätenregelung von Bild und Ton genutzt
werden. Seitens der Dekodierung sollte die Playersoftware sinnvoll konfiguriert werden.
Tabelle 8: Playerkonfiguration, Pufferung
Wie Tabelle 8 zeigt, sollte die Zwischenpufferung gerade bei längeren Streamingsitzungen
nicht zu niedrig gewählt werden. Wenn es bereits beim lokalen Abspielen von der Festplatte zu
"Rucklern" kommt, reicht die Rechenleistung nicht aus. In diesem Fall ist die Hardwarebeschleunigung der Grafikkarte auf das Maximum zu stellen. Bei Datenraten über 5 Mbps sollte der
Direct Memory Access (DMA)-Zugriff zu allen Speichermedien aktiviert58 werden. Zudem existieren
Player, die eine weitere Einstellung der Decodingsqualität ermöglichen.
58
siehe Microsoft Windows: Einstellungen|Systemsteuerung|System|Laufwerke|Eigenschaften
- 58 -
Zusammenfassung
10 ZUSAMMENFASSUNG
Aufgabe dieser Arbeit war es, die Qualität, Komplexität und Eignung moderner Videokompressionsverfahren für Video@Internet zu untersuchen. Es sollte ein Überblick über derzeit für das
Internet verfügbare Videokompressionsverfahren gegeben werden. Dazu wurden zunächst deren
verwendete Algorithmen dargestellt. Es wurde die Komplexität verbreiteter Multimediaarchitekturen
beurteilt und eine detailierte Übersicht der verfügbaren Implementierungen gegeben. Zusätzlich
sind verschiedene Ansätze des Broadcasting im digitalen Netzwerk aufgezeigt worden. Zur Beurteilung der Bildqualität der Verfahren bei unterschiedlichen Netzzugängen wurde eine interaktive
HTML-basierte Testumgebung entwickelt, mit der der Benutzer einen individuellen Vergleich der
Videosysteme durchführen kann. Den Abschluß bildete eine Meßreihe über die Rechenintensität
der einzelnen Verfahren und die Erörterung des Verhaltens bei gestörter Übertragung.
Die Untersuchungen haben gezeigt, daß gegenwärtig verfügbare Verfahren bereits
geeignet sind, bewegte Bilder über das weltweite digitale Netz zu übertragen. Mit dem Ausbau der
Bandbreiten und einer Modernisierung der Netzwerktechnologien werden in Zukunft qualitativ
hochwertigere Video-Liveübertragungen und interaktive Unterhaltung mit aktiver Programmgestaltung möglich. Ausgebaute Netzwerke sind für Business-TV im LAN-Bereich und
Educational-Anwendungen im Internet bereits jetzt geeignet. Mit der Verbreitung von DSL und der
Einführung von Multicast in IP-Netzen wird auch für OnDemand-Video eine weltweite Teilname an
LiveEvents attraktiv.
Es erzielen niedrigere Bitraten um ISDN das Real System, bei mittleren Raten um DSL
Windows Media und für hochwertiges PAL-Video DivX und Video for Windows gute Ergebnisse.
Apples Quicktimearchitektur konnte jedoch trotz umfangreicher Zusatzfunktionalitäten und
Plattformunabhängigkeit weder in der Bedienung noch in der Videoqualität überzeugen. Die
Vorteile des hoch gelobten Sorensoncodecs konnten selbst mit dessen umfangreichen Einstellmöglichkeiten nicht nachvollzogen werden. Desweiteren erscheinen die Streamingfähigkeiten der
Real- und Windowsmedia-Architekturen ausgereifter. In der Vielzahl weiterer verfügbarer Codecs
finden sich durchaus überlegene Kompressionsprinzipien. Auf Grund der spärlichen Verbreitung,
der nicht vorhandenen Netzwerkunterstützung und dem Umstand, daß die meisten dieser Codecs
nicht mehr weiterentwickelt werden, kommen sie nicht für Video@Internet in Betracht.
Zuletzt muß noch ein weitverbreiteter Irrtum ausgeräumt werden. Auf Produktionsseite
besteht häufig die Meinung, daß für niedrige Bitraten beim Internetvideo keine besonderen Anforderungen an die Qualität des Ausgangsmaterials gemacht werden müssen. Genau das Gegenteil
ist der Fall ! Bei diesem engen, aber angepaßten Übertragungskanal sollte die Qualität der Quelle
am besten SDI oder DigiBeta, minimal aber DV-Video sein. Wer ein LiveStreaming mit VHS-Video
und schlechter Ausleuchtung einrichtet und glaubt auf Kameraführung verzichten zu können,
braucht sich über niedrige Besucherzahlen also nicht zu wundern.
- 59 -
Ausblick
11 AUSBLICK
In weiteren Untersuchungen könnte der Frage nachgegangen werden, wie die realisierten
Bildqualitäten der Netzzugänge subjekiv auf Testpersonen wirken. Dazu muß ein neues Testverfahren entwickelt werden. Als Benutzerschnittstelle könnte eine Weiterentwicklung des Multi
Stimulus with Hidden Reference and Ankre (MuSHRA) [30]-Verfahrens dienen. Die verfügbare
objektiven Testverfahren sind auf ein Lowbitrate-Video-System nicht anwendbar. Daher müssen
auch hier neue Ansätze geprüft werden. Als objektives Verfahren, dessen Messwert nicht von der
Testumgebung beeinflußt wird erscheint eine reine Softwarelösung ohne Videoschnittstellen als
sinnvoll. Dazu könnte ein Programm entwickelt werden, das im offline-Betrieb jedes dekodierte
Einzelframe von einer internen Softwareschnittstelle des Grafikaufbaus abgreift.
Zu solchen Analysezwecken könnten die in dieser Arbeit erzeugten Testsequenzen dienen.
Die Datenbank von über 500 Sequenzen unterschiedlichster Codecs und Architekturen könnte um
objektive Messwerte und subjektive Testresultate erweitert werden. Außerdem besteht bereits jetzt
durch die zunehmende Verbreitung des Demonstrators über Internet und ausgegebene CD-Roms
zunehmende E-Mail-Resonanz, die in die weitere Bewertung mit eingehen kann.
Erfahrungen des Autors
Nach meiner persönlichen Auffassung befindet sich die Entwicklung bei Video@Internet
gegenwärtig an dem Punkt, an dem sich vormals MPEG-Audio beim Übergang des Layer 2 zu
"MP3" befand. In einschlägigen Kreisen ist der digitale Austausch und die Archivierung qualitativ
hochwertigen Videomaterials zu privaten Zwecken bereits Realität. Zudem möchte eine wachsende Zahl des Publikums den Zeitpunkt und den Inhalt ihrer Freizeitunterhaltung selbst bestimmen. Für diese Freiheit sind immer mehr Konsumenten durchaus bereit, Abstriche in der Qualität
hinzunehmen. Das Gleiche, was mit Napster59 in der Musikbranche zum De-Facto-Standard
wurde, ist im Begriff, sich auf Videoinhalte auszuweiten. Es besteht die Gefahr einer geteilten
Gesellschaft. Ein Teil wird dann mit maximaler Individualität (komplett) am Markt vorbei konsumieren, ein anderer sich von übersteigerten Preise abschrecken lassen. Wenn die Unterhaltungsbranche dies verhindern will, gilt es jetzt zu handeln. Es sollten nicht nur Risiken der kriminalisierten Verbraucher gesehen werden. Die Chancen neuer Technologien sind auf ein mündiges
Publikum anzuwenden. Wir sollten nicht abwarten, bis in einer mehr oder weniger fernen Zukunft
die Technik reif ist und die Konsumenten bereits ihren eigenen Weg gegangen sind.
59
Synonym für private Internet Tauschbörsen, die unter anderem eine illegale Verbreitung kommerzieller Inhalte ermöglicht
- 60 -
Literaturverzeichnis
LITERATURVERZEICHNIS
[1]
Fremerey, Frank:
Der digitale Sender, Hörfunk und Fernsehen aus dem Computer
c't - magazin für computer technik, Heft 4, 1999, S.98ff
[2]
Werner, Dieter:
Taschenbuch der Informatik
Fachbuchverlag Leipzig, 1995
[3]
McGowan, John F.: AVI Glossary, CCIR 601
2000
Internet: http://www.jmcgowan.com/avigloss.html
[4]
AECweb:
ARCHmatic Glossar und Lexikon
Mai 2000
Internet: http://www.glossar.de
[5]
Wilkens, Henning: (Institut für Rundfunktechnik)
IRT auf der Systems
Multiservice Netzwerk-Plattform für Rundfunkapplikationen
Messemitteilung, Nov 2000
[6]
Steinmetz, Arnd; Hemmje, Matthias:
(Gesellschaft für Mathematik und Datenverarbeitung,
Institut für integrierte Publikations- und Informationssysteme)
Konzeption eines digitalen Videoeditiersystems auf Basis
des internationalen Standards ISO/IEC 11172 (MEPG-1)
Studie, Nov 1998
Internet: http://www.darmstadt.gmd.de
[7]
McGowan, John F.: Overview of Video for Windows DirectShow and AVI
1996-2000
Internet: http://www.jmcgowan.com
[8]
Simon, Ute; Berndtgen, Manfred:
Handlich bunt, Kompressionstechniken für Bild- und Videodateien im Vergleich
c't - magazin für computer technik, Heft 11,1996
[9]
Cótè, Guy; Erol, Berna; Gallant, Michael; Kossentini, Faouzi:
(Institute of Electric and Electronic Engineers)
H.263+: Video Coding at Low Bit Rates
IEEE Transactions On Circuits And Systems For Video Technology: Vol.8 No.7
Nov 1998
[10]
European Broadcasting Union:
subj. Skala Recommendation ITU-R BS.1116-1:
Methods for the subjective assessment of small impairments in audio systems
including multichannel sound systems
ITU-R recommendations: BS series, 1998, S.434-459
[11]
International Telecommunication Union, Telecommunication Standardization Sector:
(Video Quality Experts Group, KPN Research)
Evaluation of new methods for objective testing of video quality:
objective test plan
1997-2000
[12]
Corriveau, Philip; Walch, Nikolaus; Schertz, Alexander:
(Communications Research Centre, Institut für Rundfunktechnik)
Video Quality Experts Group, Subjective Test Plan, Version 3
Jul 1999
- 61 -
[13]
Schmidt, Ulrich:
Digitale Videotechnik
Franzis' Verlag, München, 1998
[14]
Németh, Karlo:
Vorlesung Datenkommunikation
Skript. Fachhochschule München, 1999
[15]
Loviscach, Jörn; Wagner, Reinhard E.:
Spots aus dem Rechner, Computertechnik im TV-Studio
[16]
Beier, Andreas:
Macintosh-Notizen
c't - magazin für computer technik, Heft 9, 2000, S.64
Internet: www.microsoft.com/windows/mediaplayer/en/download/Macintosh.asp
[17]
Terran Interactive: Codeccentral, Index of Codecs
1999-2000
http://www.terran-int.com/CodecCentral/Codecs/index.html
[18]
Himmelein, Gerald:Kinoprogramme, Software-DVD-Spieler unter Windows
[19]
Ritscher; Felderhoff; Nielsen:
Kaskadierung von Bitratenreduktionsverfahren für Tonsignale
18. Tonmeistertagung, Karlsruhe, 1994
[20]
Jaeger, Stefan:
Legal oder illegal, Der rechtliche Status des DVD-Hackertoolsaktuell
c't - magazin für computer technik, Heft 14, 2000, S.28f
[21]
Loviscach, Jörn:
Filmkonserven, Analogvideo DV und DVD archivieren
[22]
Mackensen, Philip: Live Streaming von der Tonmeistertagung
(Institut für Rundfunktechnik)
Dez 2000
Internet: http://www.tonmeister.de/tmt/2000/streaming/intro.htm
[23]
Leitner, Felix von: Bilder für alle, Multicast: Sendeverfahren für Audio und Video im Netz
[24]
Hofmann, Herbert: Networks and Network Management, Audio/Video Streaming over IP
Mai 2000
[25]
Schröder, Karsten, Gebhard, Harald:
Audio-/Video-Streaming über IP Multimedia-Netze
Fernseh- und Kinotechnik, Heft 54, Jahrgang Nr.1-2, 2000
[26]
Gebhard, Harald:
Diplomarbeit. IP-basierte Video-Kommunikation
(Lehrstuhl für Nachrichtentechnik, Universität Dortmund)
Internet: http://www.nt.e-technik.uni-dortmund/m_gh, 1999
[27]
Plate, Jürgen:
[28]
Zivadinovic, Dusan: Highspeed-Surfer, Breitbandtechnik in Deutschland nicht flächendeckend
[29]
Stokes, Michael; Anderson, Matthew; Chandrasekar, Srinivasan; Motta, Ricardo:
(Hawlett Packard, Microsoft)
Farbmodelle, A Standard Default Color Space for the Internet, sRGB Version
Nov 1996
Multimedia in Netzen
Vorlesung, August 1997
Internet: http://www.w3.org/graphics/color/sRGB
- 62 -
[30]
Stoll, Gerhard:
Audio Goes Internet
Seminar Präsentation, Aug 2000, S.17
[31]
Kuri, Jürgen:
Telefonieren über TCP/IP: Spielerei oder Zukunftstechnik?
[32]
Oberdörster, Alexander; Carstens, Matthias:
Frontalangriff, Internet- Audio und Video: Microsoft contra Apple und MP3
[33]
Loviscach, Jörn:
[34]
Zivadinovic, Dusan: Privatfunk, Bluetooth als Netzwerk- und Schnittstellenmodul
[35]
Rink, Jürgen:
[36]
Windeck, Christof: Universeller Bus gegen Feuerdraht, Wer ist schneller?
c't - magazin für computer technik, 22/99, Seite 57
[37]
Gersho, A.; Gray, R.; Boston:
Vector Quantization and Signal Compression
1992
[38]
Zota, Volker:
Kopierschutz ausgehebelt, Microsofts Streaming-Media-Formate speicherbar
c't - magazin für computer technik, Heft 16, 1900, S.33f
[39]
ISO/IEC 13818-1:
Information technology, Generic coding of moving pictures and associated
audio information, Part 1: Systems
[40]
ETR:
Digital Video Broadcasting (DVB); Implementation Guidelines for the Use of
MPEG-2 Systems
Draft 154, Rev.3, Juni 1999
[41]
Reimers, U.:
Digitale Fernsehtechnik
Berlin, Springer Verlag 1995
Formen mit Normen, Internet-Standards für Multimedia - nicht nur online
c't - magazin für computer technik, Heft 18, 2000
IrDA-Verbindungen mit PC, Notebook, PDA und Mobiltelefon
- 63 -
Anhang
QUELLENVERZEICHNIS
[A]
Stoll, Gerhard; IRT, Audio Internet Demonstration Aid, Version 2.1
Internet: http://radio.irt.de/aida/start_e.htm
[B]
Schmalohr, Martin; IRT, Video Internet Demonstration Aid, Version 2.6
Internet: http://radio.irt.de/vida/begin.htm
[C]
European Broadcasting Union
Internet: http://www.rnw.nl/ebu
[D]
Video Quality Experts Group
Internet: http://ftp.crc.ca/test/pub/crc/vqeg
[E]
Cristy, John; ImageMagic, Version 5.21
Internet: http://www.imagemagick.org
[F]
Adobe, Photoshop, Version 4.0
http://www.adobe.com/products/main.html
[G]
Roberts, Jeff; Rad Video Tools,
Internet: http://www.radgametools.com
[H]
Adobe, Premiere, Version 5.1
http://www.adobe.com/products/main.html
[I]
W3C, Empfehlung zur Synchronized Multimedia Integrated Language,
Internet: http://www.w3.org/tr/rec-smil
[J]
Microsoft, Netshow Tools, Version 4.1
http://www.microsoft.com/netshow/download/en/release.htm
[K]
Microsoft, Windows Media Encoder, Version 7
Internet: http://www.microsoft.com/windows/windowsmedia
[L]
Microsoft, Windows Media System Developer Kit, Version 7
Internet: http://www.microsoft.com/windows/windowsmedia
[M]
Real Networks, Real Producer Pro, Version 6.0
Internet: http://www.real.com
[N]
Real Networks, Real Producer Plus, Version 8.0
Internet: http://www.real.com
[O]
Darim Vision, MPEG Encoder, Version 5.0
Internet: http://www.s-vision.com
[P]
Sorenson, Video Codec, Developper Edition 3
http://www.sorenson.com/SorensonVideo/overview.html
[Q]
Apple, Quicktime Pro, Version 4.0
http://www.apple.com/quicktime
[R]
Intel, Indeo Video Codec, Version 3-5
Internet: http://developer.intel.com/ial/indeo/video/web.htm
[S]
Radium, DivX Video Codec, Version 3.11
Internet: http://divx.ctw.cc
[T]
Terran, Media Cleaner, Version 4.0
Internet: http://www.terran-int.com/products/cleaner/index.html
[U]
Quicktimetools Electrifier, LiveStage, Macromedia Director, MPEG
Internet: http://www.terran-int.com/products/LivestageOverview.html
[V]
Macromedia, Dreamweaver, Version 3.0
Internet: http://www.macromedia.com/software/dreamweaver
[W]
Quicktime, Filmtrailer
Internet: http://www.apple.com/trailers
[X]
Münz, Stefan; Selfhtml, Version 7.0
Internet:
[Y]
http://www.teamone.de/selfaktuell
Wilson, Dave; Four Character Code Liste
Internet: http://www.webartz.com/fourcc
[Z]
Microsoft, Four Character Code Liste
http://www.microsoft.com/hwdev/devdes/fourcc.htm
- 64 -
Anhang
ABKÜRZUNGSVERZEICHNIS
MC ............................................................Motion Compensation
MFTP .........................................Multicast File Transfer Protocol
MJPEG................................................................... Motion-JPEG
MPEG ......................................... Moving Picture Experts Group
MSE .............................................................Mean Squared Error
MuSHRA ...... Multi Stimulus with Hidden Reference and Ankre
A
AAC ......................................................Advanced Audio Coding
ACM ............................................. Audio Compression Manager
AIDA.................................... Audio Internet Demonstration Aids
ATM....... Asynchronous Transfer Asynchronous Transfer Mode
AVI ......................................................... Audio Video Interleave
N
C
NT ..............................................................Network Termination
NTSC ......................... National Television Standards Committee
CBR ................................................................... Constant Bitrate
CD-I ......................................................................CD Interactive
CoDec ................................. Compressor-Decompressor-Pärchen
CYMK................ Farbmodell nach Cyan Yellow Magenta BlacK
O
OSI...............................................Open Systems Interconnection
D
P
D1..D9....................................................... digitales Videosystem
DCT ............................. engl. für diskrete Kosinustransformation
DIB...................................................Device Independent Bitmap
DLL.........................................................Dynamic Link Liberary
DMA ........................................................Direct Memory Access
DSL.................. Digital Subscriber Line Digital Subscriber Line
DV.............................................................. Digital Video System
DVB ................................................. Digital Video Broadcasting
DVC-Pro ................................................... digitales Videosystem
DVD.........................................................Digitale Versatile Disc
DWT ....................................... Diskrete Wavelet Transformation
PAL..........................................................Phase Alternation Line
Payload.......................................................................... Datenteil
PDU ..............................................................Protokoll Data Unit
PNG..................................................... Portable Network Grafiks
PSK ............................................Phase-Shift-Keying Modulation
PSNR .................................................Peak Signal to Noise Ratio
E
RGB ..........................................Farbmodell nach Rot-Grün-Blau
RLE ........................................................... Run Length Encoding
RPRendezvous Point
RSVP ........................................................ ReSerVation Protocol
RTCP ................................................ Transport Control Protocol
RTP ................................................. Realtime Transport Protocol
Q
QAM ...................................... Quadratur-Amplitudenmodulation
R
EBU ............................................. European Broadcasting Union
F
FBAS.............................. Farb-Bild-Austast- und Synchronsignal
FCC............................................................. Four Character Code
FD .................................................................Frame Differencing
FPS..............................................................Fast Paket Switching
FTP............................................................ File Transfer Protocol
S
SDI........................................................... Serial Digital Interface
SFM ........................................................ Surface Fitting Method
SIF...........................................................Standard Image Format
Sprite........................................................................... Bildobjekt
SVCD..............................................Super Video Comopact Disk
SVT..............................................skalierbare Video Technologie
G
GIF ................................................. Graphics Interchange Format
GOP.................................................................. Group of Pictures
GSM...Short Messaging Service Groupe Spécial Mobile System
T
H
TCP ..............................................Transmission Control Protocol
TDSL..................................................................... Telekom-DSL
TE ............................................................... Terminal Equipment
Header ......................................................................Kopfstruktur
HF .......................................................................High Frequency
HSB........................ Farbmodell nach Hue,Saturation,Brightness
HTML .......................................... Hyper Text Markup Language
HTTP.............................................. Hypertext Transfer Protokoll
U
UDP .......................................................User Datagram Protocol
ULP .......................................................... Upper Layer Protokoll
UMTS ................. Universal Mobile Telecommunication Service
URI................................................Uniform Ressource Indicators
URL....................................................Uniform Resource Locator
URS................................................. Uniform Ressource Number
I
IEC ............................International Electrotechnical Commission
IP .................................................................... Internet Protokoll
IPv6..............Internet-Protokoll Version 6 (auch next Generation
ISDN .................................. Integrated Services Digital Network
ISO ............................ International Standardisation Organisation
ISP...................................................... Internet Service Providern
IVI...........................................................Indeo Video Interactive
V
JPEG ................................................ Joint Picture Experts Group
JTC1...... Joint Technical Committee on Information Technology
VBR ....................................................................Variable Bitrate
VCM ..............................................Video Compression Manager
VHS ............................................................ Video Home System
VID@.....................................Video Internet Demonstration Aid
VOB ...................................................................... Video Objects
VQEG ............................................Video Quality Experts Group
L
W
LAB.. Farbmodell nach Helligkeit und Farbkreiskoordinaten-AB
LAN .............................................................Local Area Network
LLC .............................................................Logical Link Control
WDM ...................................................Wave Division Multiplex
WMA ...................................................... Windows Media Audio
J
Y
M
YUV...............Farbmodell mit RGB-Balance Component Video
MAC .........................................................Media Access Control
- 65 -
Anhang
ANHANG
- 66 -
Anhang
Parameterprofile
1 PARAMETERPROFILE
1.1
Quellbitrate
ORG
20 MBps
Originale unkomprimierte Sequenz ...............................................................260Mbyte gesamt, Faktor 1:1
@ 257Mbps|1500:8|I1|4:2:2
Video:
NTSC
525@60Hz
720x486 260 pics/24 bit
PAL
625@50Hz
720x576 220 pics/24 bit
Audio:
PCM
16bit stereo@44.1kHz
REF
6 Mbps
1
Referenz, Video only (DVD, MP@ML) ......................................................15,2Mbyte gesamt, Faktor 41:1
@ 6Mbps|6000:0
Video:
525@60Hz: (720x486)
30fps|IBBP
625@50Hz: (720x576)
25fps|IBBP
Audio:
no Audio
1.2
Niedrige Bitraten
ANA
40 kbps
56K Analog-Modem ........................................................................................42kByte gesamt, Faktor 83:1
@ 40kbps|34:6|7fps|I60
Video:
NTSC
525@60Hz
176x112 (QSIF)
PAL
625@50Hz
176x144 (QSIF)
Audio:
8bit mono@8kHz
ISDN
56 kbps
einfacher ISDN B-Kanal................................................................................58kByte gesamt, Faktor 167:1
@ 56kbps|48:8|10fps|I60
Video:
NTSC
525@60Hz
240x162
PAL
625@50Hz
240x192
Audio:
16bit mono@11.050kHz
DUAL
112 kbps
Doppeltes ISDN, 2 parallelgeschaltete B-Kanäle .......................................116kByte gesamt, Faktor 222:1
@ 112kbps|80:22|15fps|I40
Video:
NTSC
525@60Hz
320x216
PAL
625@50Hz
320x256
Audio:
DSL
300 kbps
Schnelles Internet, T1 Kabel Modem, xDSL Breitband ..............................311kByte gesamt, Faktor 135:1
@ 300kbps|240:64|20fps|I20
Video:
NTSC
525@60Hz
352x240 (SIF)
PAL
625@50Hz
352x288 (SIF)
Audio:
LAN
1 Mbps
Standard LAN, Intranet ..................................................................................1Mbyte gesamt, Faktor 112:1
@ 1Mbps|800:160|I10
Video:
NTSC
525@60Hz
480x324 30fps
PAL
625@50Hz
480x384 25fps
Audio:
1
Main Profile at Main Layer
-A1-
Anhang
1.3
Parameterprofile
Mittlere Bitraten
Video:
Audio:
NTSC
PAL
PCM
525@60Hz
352x240
30fps (SIF)
625@50Hz
352x288
25fps (SIF)
Video CD
1125k
Video CD, CD Interactive, Laserdisc ........................................................... 1,5MByte gesamt, Faktor 54:1
@ 1125kbps|1125:224|IBBP
(29.97fps)
MPEG-1
1 Mbps
Program Stream mit minimaler Rate ........................................................... 1.3MByte gesamt, Faktor 61:1
@ 1Mbps|1000:128|IBBP
MPEG-1
1.5 Mbps
Standard Program Stream für Videoclips .................................................... 2.0MByte gesamt, Faktor 41:1
@ 1,5Mbps|1500:224|IBBP
MPEG-1
3 Mbps
Hochwertiger Program Stream .................................................................... 3.7MByte gesamt, Faktor 20:1
@ 3Mbps|3000:224|IBBP
1.4
Hohe Bitraten
Video:
Audio:
NTSC
PAL
PCM
525@60Hz
720x486
30fps
625@50Hz
720x576
25fps
MS Media7
1.5 Mbps
Windows Media mit TV Qualität................................................................. 1.7MByte gesamt, Faktor 166:1
@ 1,5Mbps|1500:192|I90/I75
MS Media7
2 Mbps
Windows Media mit DV Qualität ................................................................ 2.3MByte gesamt, Faktor 125:1
@ 2Mbps|2000:192|I90/I75
MPEG-2
1.5 Mbps
Program Stream mit minimaler Rate ......................................................... 2.0MByte gesamt, Faktor 166:1
@ 1,5Mbps|1500:224|IBBP
MPEG-2
3 Mbps
Program Stream mit mittlrer Rate ................................................................ 3.7MByte gesamt, Faktor 83:1
@ 3Mbps|3000:224|IBBP
MPEG-2
4 Mbps
Standard Program Stream (DVD,DVB) ....................................................... 4.9MByte gesamt, Faktor 62:1
@ 4Mbps|4000:224|IBBP
MPEG-2
6 Mbps
Video Only Stream, hochwertige Qualität.................................................... 6.5MByte gesamt, Faktor 41:1
@ 6Mbps|6000:224|IBBP|no sound
1.5
Codec Kombinationen
CODE
APPL
I263
IIND
MPG2
MPG4
RLG2
SRS2
VDOW
WNM7
Videocodec
Apple Video
Intel H263
Intel Indeo
Darim MPEG2 V5
MS MPEG4v3
Real G2
Sorenson2
VDOWave
MS Media7
Audiocodec
Architektur
Qdesign Music Codec
QT
MPEG-1 Audio L3
QT
MPEG-1 Audio L3
WM
MPEG-1 Audio L2 / no
WM
MS Audio V2
WM
Real Audio
RL
Qdesign Music Codec
QT
MPEG-1 Audio L3
WM
MS Audio V7
WM
-A2-
Anhang
Programmcode
2 PROGRAMMCODE
2.1
MAIN.JS
<!-var dispFLG = 1;
var infoDir = "info/";
var picDir = "pics/";
var file3 = "";
var info = "";
var path = "";
var fpsFile = "";
var filename = "";
var scrolling = "no";
var resize = "no";
var Message0 = "Click left to view the Videosequence and right to display a Bitratechart";
var Message1 = "Sorry, no additional Information avaliable";
var Message2 = "Click here for more Information";
var status0 = Message0;
var status1 = "Click here for Details on the Videosource";
var status2 = "Click here for special Encodingparameters";
var status3 = "Click to enlarge view";
var status4 = "Click for slideshow";
var status5 = "Click to view the Videosequence";
var extraWin = "";
function changeRightclick()
{
if (document.layers)
{
window.captureEvents(Event.MOUSEDOWN | Event.MOUSEUP)
window.onmousedown=rightclick;
window.onmouseup=rightclick;
function rightclick(e)
{
if (e.which == 3)
{
dispInfo('chart', fpsFile);
return false;
}
else return true;
}
}
if (document.all)
{
function click()
{
if (event.button==2) dispInfo('chart', fpsFile);
if (event.button==3) dispInfo('chart', fpsFile);
}
document.onmousedown=click
}
}
function dispInfo(cat,file)
{
var Iwidth=100;
var Iheight=550;
var Property
dispFLG=1;
scrolling = "no";
resize = "no";
switch(cat)
{
case "codec":
case "info":
case "chart":
case "seq525":
case "seq625":
case "pic525":
case "pic625":
default:
Iwidth=450;Iheight=420;
path = infoDir + file;.
break;
path = infoDir + file;
break;
if (fpsFile==0) {alert(Message0);dispFLG=0;}
if (fpsFile==1) {alert(Message1);dispFLG=0;}
break;
break;
break;
break;
break;
break;
}
if (dispFLG)
{
filename = URLfilename();
if (extraWin.closed == false) extraWin.close();
if (cat=="chart") {path = infoDir + "chartTMP.htm?" + escape(file) + '&' + escape(filena
Property = "width=" + Iwidth + ",height=" + Iheight + ",directories=no,scrollbars=" + sc
extraWin = windowHandle=window.open(path,'infoWin',Property);
}
}
function URLfilename()
{
actPageURL = window.location.href;
x = actPageURL.length;
while((actPageURL.substring(x,x-1)) != "."){ x--; } clipend = x;
while((actPageURL.substring(x,x-1)) != "/"){ x--; } clipstart = x;
return actPageURL.substring(clipend-1,clipstart);
}
function statusMsg(msgNo)
{
switch(msgNo)
{
case 0:
status = "";break;
case 1:
status = status1;break;
case 2:
case 3:
case 4:
case 5:
case 6:
default: status = "";break;
}
document.msgFLG = true;
}
function chartInfo(msgNo,file) //v2.0
{
jsStr = "fpsFile = \'" + file + "\'";.
statusMsg(msgNo);
return eval(jsStr);
}
//-->
-A3-
Anhang
2.2
Programmcode
selectICON = imgName;
if (selectICON != 'ana') document['ana'].src =
if (selectICON != 'isdn') document['isdn'].src
if (selectICON != 'dual') document['dual'].src
if (selectICON != 'dsl') document['dsl'].src =
if (selectICON != 'lan') document['lan'].src =
if (selectICON != 'high') document['high'].src
SELECT.JS
<!-var selectINFO = "";
var selectICON = "";
var icons = 6;
var infos = 6;
var modes = 3;
var iconDir = "icons/";
var statusINFO = "choose your Web Connection Speed (kilobit per second)";
var statusFLG = 0;
var i;
var info = new Array(infos);
var icon = new Array(icons);
for (i=0; i < icon.length; ++i) {icon[i] = new Array(modes);}
function initIcons()
{
if (document.images)
{
icon[0][0] = new Image(); icon[0][0].src = iconDir + "0_analog.gif";
// OnLoad Off
// OnMouseOver OnC
// OnMouseOver OnC
icon[1][0] = new Image(); icon[1][0].src = iconDir + "0_isdn.gif";
icon[2][0] = new Image(); icon[2][0].src = iconDir + "0_dual.gif";
icon[3][0] = new Image(); icon[3][0].src = iconDir + "0_dsl.gif";
icon[4][0] = new Image(); icon[4][0].src = iconDir + "0_lan.gif";
icon[5][0] = new Image(); icon[5][0].src = iconDir + "0_high.gif";
info[0] = new Image(); info[0].src = iconDir + "i_info.gif";
// OnLoad Off
info[1] = new Image(); info[1].src = iconDir + "i_analog.gif";
// OnMouseOver OnClick O
info[2] = new Image(); info[2].src = iconDir + "i_isdn.gif";
// OnMouseOver OnClick On
info[3] = new Image(); info[3].src = iconDir + "i_dual.gif";
info[4] = new Image(); info[4].src = iconDir + "i_dsl.gif";
info[5] = new Image(); info[5].src = iconDir + "i_lan.gif";
info[6] = new Image(); info[6].src = iconDir + "i_high.gif";
}
}
function changeIcon(imgName,newImg,swap)
{
if (document.images)
{
if (selectICON != imgName) document[imgName].src = eval(newImg + ".src");
if (swap == 2) selectINFO = selectICON;
else selectINFO = imgName;
switch (selectINFO)
{
case "ana" :
document['sel_INFO'].src = eval('info[1]' + ".src"); break;
case "isdn" :
case "dual" :
case "dsl" :
case "lan" :
case "high" :
document['sel_INFO'].src = eval('info[6]' + ".src"); break;.
default
:
}
if (swap == 0)
{
eval('icon[0][0]' +
= eval('icon[1][0]'
= eval('icon[2][0]'
eval('icon[3][0]' +
eval('icon[4][0]' +
= eval('icon[5][0]'
".src");
+ ".src");
+ ".src");
".src");
".src");
+ ".src");
}
}
}
function defMsg() {
status=statusINFO;
document.statusFLG = true;
}
function clrMsg() {
status = "";
document.statusFLG = true;
}
//-->
2.3
SELECT.HTM
<html>
<head>
<title>Select bar</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script language="JavaScript" src="select.js" type="text/javascript">
</script>
</head>
<body bgcolor=" DDDDDD" onLoad="initIcons()">
<img src="icons/bar_0.GIF" hspace=0 vspace=0 border=0 width="140" height="100"><br>
<img src="icons/bar_1.GIF" hspace=0 vspace=0 border=0 width="140" height="160"><br>
<a href="analog.htm" target="main"
onClick="changeIcon('ana', 'icon[0][2]',0);"
onMouseOver="changeIcon('ana', 'icon[0][1]',1); defMsg(); return true; return document.sta
onMouseOut="changeIcon('ana', 'icon[0][0]',2); clrMsg()">
<img name="ana" SRC="icons/0_analog.gif" border=0 alt="Analog Modem"></a><br>
<a href="isdn.htm" target="main"
onClick="changeIcon('isdn', 'icon[1][2]',0);"
onMouseOver="changeIcon('isdn', 'icon[1][1]',1); defMsg();return document.statusFLG"
onMouseOut="changeIcon('isdn', 'icon[1][0]',2); clrMsg()">
<img name="isdn" SRC="icons/0_isdn.gif" border=0 alt="Integrated Services Digital Network
<a href="dual.htm" target="main"
onClick="changeIcon('dual', 'icon[2][2]',0);"
onMouseOver="changeIcon('dual', 'icon[2][1]',1); defMsg();return document.statusFLG"
onMouseOut="changeIcon('dual', 'icon[2][0]',2); clrMsg()">
<img name="dual" SRC="icons/0_dual.gif" border=0 alt="Two Parallel ISDN Lines"></a><br>
<a href="dsl.htm" target="main"
onClick="changeIcon('dsl', 'icon[3][2]',0);"
onMouseOver="changeIcon('dsl', 'icon[3][1]',1); defMsg();return document.statusFLG"
onMouseOut="changeIcon('dsl', 'icon[3][0]',2); clrMsg()">
<img name="dsl" SRC="icons/0_dsl.gif" border=0 alt="Digital Subscriber Line"></a><br>
<a href="lan.htm" target="main"
onClick="changeIcon('lan', 'icon[4][2]',0);"
onMouseOver="changeIcon('lan', 'icon[4][1]',1); defMsg();return document.statusFLG"
onMouseOut="changeIcon('lan', 'icon[4][0]',2); clrMsg()">
<img name="lan" SRC="icons/0_lan.gif" border=0 alt="Local Area Network"></a><br>
<a href="high.htm" target="main"
onClick="changeIcon('high', 'icon[5][2]',0);"
onMouseOver="changeIcon('high', 'icon[5][1]',1); defMsg();return document.statusFLG"
onMouseOut="changeIcon('high', 'icon[5][0]',2); clrMsg()">
<img name="high" SRC="icons/0_high.gif" border=0 alt="Local Storage & Distribution"></a><
<img src="icons/i_info.GIF" width="140" height="229" name="sel_INFO"><br>
<img src="icons/bar_2.GIF" width="140" height="400">
</body>
</html>
-A4-
Anhang
2.4
Programmcode
INDEX.HTM
<html>
<head>
<title>Video Internet Demonstration Aid</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<frameset cols="16%,*%" frameborder="NO" border="0">
<frame src="select.htm" frameborder="NO" scrolling="NO" name="select" marginwidth="0" mar
<frameset rows="20%,80%" frameborder="NO" border="0">
<frame src="head.htm" scrolling="NO" frameborder="NO" name="Head">
<frame src="analog.htm" frameborder="NO" name="main">
</frameset>
</frameset>
<noframes><body bgcolor=" FFFFFF">
<a href="/index.htm">index</a> <a href="/index.htm">index</a>
</body></noframes>
</html>
2.5
chartTMP.HTM
<HTML>

<BODY leftmargin=0 topmargin=0 marginwidth=0 marginheight=0 bgcolor= C0C0C0 onLoad="self.focu
<SCRIPT LANGUAGE="JavaScript">
var title = "";
var codec = "";
var path = "";
var codName = "";
var seqNumber = 0;
var passed
= location.search ? unescape(location.search.substring(1)) + '&' : '';
var file
= passed ? passed.substring(0,passed.indexOf('&')) : 'default.gif';
passed
= passed.substring(passed.indexOf('&')+1);
var bitrate
= passed ? passed.substring(0,passed.indexOf('&')) : 'Default bitrate';
switch(bitrate)
{
case "analog": path = "../pics/chart/40k/" + file;
break;
case "isdn":
path = "../pics/chart/56k/" + file;
break;
case "dual":
break;
case "dsl":
break;
case "lan":
break;
default:
break;
}
seqNumber = file.substr(5,2);
codec = file.substr(0,4);
switch(codec)
{
case "A263":
codName = "Apple H.263";
break;
case "DIVX":
codName = "DivX MPEG-4v3";
break;
case "IIND":
codName = "Intel Indeo Video";
break;
case "MPG2":
codName = "Reference MPEG-2 (DVD)";
break;
case "MPG4":
codName = "MS MPEG-4v3";
break;
case "RLG2":
codName = "Real Video G2";
break;
case "RLV8":
codName = "Real Video v8";
break;
case "SRS2":
codName = "Sorenson Video";
break;
case "VDOW":
codName = "VDOnet VDO Wave";
break;
case "WNM7":
codName = "MS Media Video7";
break;
default:
codName = "unknown Codec";
break;
}
var title = "BITRATEOVERVIEW - Sequence " + seqNumber + " coded by "+ codName;
document.write('<title>' + title + '</title>');
document.write('<IMG SRC="' + path + '">');
</SCRIPT>.</BODY>
</HTML>
-A5-
Anhang
Architekturen
3 ARCHITEKTUREN
3.1
Quicktime
3.1.1 Video Codecs
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Animation
Apple BMP
Apple Video
Cinepak
Component Video
DV - NTSC
DV - PAL
Graphics
H.261
H.263
Intel Indeo Video 3.2
Intel Indeo Video 4.4
Microsoft Video
Microsoft RLE
Motion JPEG A
Motion JPEG B
MPEG 1 (Mac OS)
None
Photo JPEG
Planar RGB
Streaming
•
•
•
•
H.261
H.263
Motion JPEG
Sorenson Video 2
3.1.2 Audio Codecs
•
•
•
•
•
•
•
•
•
•
•
•
•
24-bit Integer
32-bit Integer
32-bit Floating Point
64-bit Floating Point
ALaw 2:1
DVI 4:1
IMA 4:1
MACE 3:1
MACE 6:1
MS ADPCM
QDesign Music 2
QUALCOMM PureVoice
uLaw 2:1
Streaming
•
•
•
•
3.1.3 Spur Typen
•
•
•
•
•
•
•
•
•
Video
Sound
Music
Text
3D
Sprite
VR – virtual reality
Timecode
Tween, Base, Hint Tracks
-A6-
DVI 4:1
QDesign Music 2
QUALCOMM PureVoice
uLaw 2:1
Anhang
3.2
Architekturen
Windows Media Technologies
3.2.1 Video Codecs
•
•
•
•
•
Microsoft MPEG-4 Video 1
Windows Media Screen 7
ISO-MPEG-4 (version) 1
3.2.2 Audio Codecs
•
•
•
•
•
Windows Media Audio 1
Frauenhofer IIS MPEG Layer3 Codec
Voxware
3.2.3 Spur Typen
• Script (Visual Basic)
• Audio
• Video
3.3
Real System G2
3.3.1 Video Codecs
• Real Video G2
• Real Video V8
3.3.2 Audio Codecs
• Real Audio V2
• Real Audio V8
3.3.3 Spur Typen
•
•
•
•
•
•
Real Text
Real Text 3D
Real Pix
Script (SMIL)
RealAudio
RealVideo
-A7-
Anhang
Codeceigenschaften
4 CODECEIGENSCHAFTEN
4.1
Apple Video
Multimedia Architektur
Geeignetes Material
Farbumfang
Räumliche Kompression
Zeitliche Kompression?
Eigenschaften
Encoder Voraussetzungen
Decoder Voraussetzungen
Encoder Quelle
Decoder Quelle
Hersteller
4.2
Cinepak
Geeignetes Material
Farbumfang
Eigenschaften
Encoder Quelle
Decoder Quelle
Algorithmus
Farbraum
Hersteller
4.3
Video für Windows
PAL-Video
8,24 Bit Farbe oder Graustufen
slow
Ja
MacOS, Windows
MacOS, Windows
QuickTime
QuickTime
Vector Quantisierung
RGB
Apple, CTI
Clear Video
Farbumfang
Treiber (32 Bit)
Hersteller
4.4
Quicktime
Video
16 Bit Farbe
Asymmetrisch (ca. 7:1)
Ja
advanced data rate limiting mit Media Cleaner Pro 2.0
MacOS, Windows
MacOS, Windows
Quicktime
Quicktime
Apple
Video für Windows
8 Bit Farbe
vidc.ucod=clrvidcd.dll
Q-Team
escape videostudio
Geeignetes Material
Farbumfang
Eigenschaften
Encoder Quelle
Decoder Quelle
Hersteller
Video für Windows
Video
16 Bit Farbe
Schneller als Cinepak
Ja
Blacklined-Doubling Verfahren
Pentium, PowerMac
Pentium, PowerMac
Eidos Technologies
Frei verfügbar
Eidos Technologies
-A8-
Anhang
4.5
Codeceigenschaften
H.261
Geeignetes Material
Farbumfang
Eigenschaften
Encoder Vorraussetzungen
Decoder Vorraussetzungen
Encoder Quelle
Decoder Quelle
Algorithmus
Farbraum
Hersteller
Treiber (32 Bit)
4.6
H.263
Geeignetes Material
Farbumfang
Eigenschaften
Encoder Quelle
Decoder Quelle
Algorithmus
Treiber (32 Bit)
Hersteller
4.7
Video für Windows, Quicktime
Low-motion video
16 Bit Farbe
Symmetrisch, Echtzeit
Ja
MacOS, Windows
PowerMac, Pentium
QT Conferencing kit, Intel's ProShare videoconferencing, Microsoft
QT Conferencing kit, Intel's ProShare videoconferencing, Microsoft
Diskrete Kosinus Transformation (DCT),
Bewgungskompensation(H.261 war der erste video codec mit DCT)
4:2:0
Verschiedene, auch Apple und Microsoft
VIDC.M261=MSH261.DRV
Video für Windows, Quicktime
Low-motion video
16 Bit Farbe
Symmetrisch, Echtzeit
Ja
MacOS, Windows
PowerMac, Pentium
QuickTime 3, Microsoft NetShow (Vivo H.263),
Intel I263 mit NetCard, Shannon Communication
Systems (SCS) H.263+, Telenor R&D of Norway
QuickTime 3, Microsoft NetShow (Vivo H.263),
Intel I263 mit NetCard, Shannon Communication
Systems (SCS) H.263+, Telenor R&D of Norway
Bewgungskompensation basierend auf H.261
VIDC.VIVO=IVVIDEO.DLL
VIDC.I263=C:\WINDOWS\I263_32.DLL
VIDC.I420=C:\WINDOWS\I263_32.DLL
VIDC.M263=msh263.drv
Verschiedene, auch Apple, Microsoft, Intel
Microsoft Video 1
Farbumfang
Treiber (Win 3.x)
Treiber (32 Bit)
Hersteller
Video für Windows
8, 16 Bit Farbe
Vidc.msvc=msvidc.dll
Vidc.msvc=msvidc32.dll
Microsoft
-A9-
Anhang
4.8
Codeceigenschaften
MPEG
Geeignetes Material
Eigenschaften
Encoder Quelle
Decoder Quelle
Algorithmus
Hersteller
Treiber (Windows 95)
4.9
Video für Windows, Quicktime, Windows Media, Real
PAL/NTSC video
Moderat
Ja
Ab MPEG4 objektorientierte Kodierung möglich
MPEG4 Encoder in NetShow 3.0, u.a.
MPEG4 Decoder in NetShow 3.0, u.a.
Bewgungskompensation basierend auf H.263
Offener Standard
vidc.mpg4=msscrc32.dll
RealVideo G2
Geeignetes Material
Farbumfang
Eigenschaften
Encoder Quelle
Decoder Quelle
Treiber (Windows 95)
Treiber (32 Bit)
Hersteller
Real
Low-motion video, ab 24 kbps
32 Bit Farbe
Asymmetrisch
Ja
PowerMac, Pentium
PowerMac, Pentium
RealVideo Encoder kit oder Media Cleaner Pro
RealProducer Packet von RealNetworks
RealPlayer Installer
RealNetworks
4.10 RLE
Geeignetes Material
Farbumfang
Eigenschaften
Encoder Quelle
Decoder Quelle
Algorithmus
Treiber (Win 3.x)
Treiber (32 Bit)
Hersteller
Video für Windows
Animationen
8 Bit Farbe
Ja
Nein
Verlustlos
Windows 95
Windows 95
Run Length Encoding (Lauflängenkodierung nach LZW)
vidc.mrle=msrle.dll
vidc.mrle=msrle32.dll
Microsoft
- A 10 -
Anhang
Codeceigenschaften
4.11 Sorenson Video
Geeignetes Material
Farbumfang
Eigenschaften
Quicktime
Video, Animationen
24 Bit Farbe
Sehr Langsam
Ja
Developer Edition:
Temporal scalability,
Media Keys, watermarking,
variable bitrate encoding
Encoder Voraussetzungen PowerPC, Windows
Decoder Voraussetzungen WWW: PowerMac, Pentium
CD-ROM: PowerMac, Pentium
(120mhz for playback of 320x240 @ 15fps)
Basic Edition: QuickTime 3 and 4
Encoder Quelle
Developer Edition: Terran, Sorenson
Hardware-beschleunigte Version: Terran
Decoder Quelle
QuickTime 3 and 4
Algorithmus
Fortgeschrittene Vectorquantisierung mit Bewegungskompensation
Farbraum
YUV-9
Hersteller
Sorenson Vision, Inc.
4.12 VDO Wave
Eigenschaften
Encoder Quelle
Decoder Quelle
Algorithmus
Treiber (Win 3.x)
Treiber (32 Bit)
Hersteller
Video für Windows
Stark
Ja
Skalierbar
Microsoft Netshow 2.0
Microsoft Netshow 2.0
Wavelet
vidc.vdom=vdowave.drv
vidc.vdow=vdowave.drv
VDONet
- A 11 -
Anhang
Microsoft Four Character Codes
5 MICROSOFT FOUR CHARACTER CODES
5.1
Standard Codecs
Compressor
Code
MSVC or CRAM or WHAM
MRLE
IV31
IV32
CVID
ULTI
MJPG
IJPG
CYUV
YVU9
XMPG
MPGI
VIXL
MVI1
SPIG
PGVV
TMOT
DMB1
BW10
IV41
IV50
UCOD
VDOW
SFMC
QPEG
H261
M261
VIVO
M263
I263
MPG4
MP42
MP43
DIV3
DIV4
MWV1
Description
Microsoft Video 1
Microsoft Run Length Encoding
Indeo 3.1/3.2
Indeo 3.1/3.2
Cinepak (Radius)
Ultimotion (IBM)
Motion JPEG (Microsoft, Paradigm Matrix, video capture companies)
Intergraph JPEG
Creative YUV
Intel Indeo Raw YUV9
Editable (I frames only) MPEG (Xing)
Editable MPEG (Sigma Designs)
miro Video XL
Motion Pixels
Radius Spigot
Radius Video Vision
Duck TrueMotion S
Custom Format Used by Matrox Rainbow Runner. This appears to be a type of Motion
JPEG
Broadway I-Frame MPEG. Broadway is a Video Capture and Editing System,
including a video capture and MPEG compression board for the PC.
Indeo Interactive (Indeo 4.1 from Intel)
Indeo 5.x, including 5.0, 5.06, and 5.10
ClearVideo (Iterated Systems)
VDOWave (VDONet)
Surface Fitting Method (CrystalNet)
Q-Team Dr.Knabe 's QPEG video compressor
H.261
Microsoft H.261
Vivo H.263
Microsoft H.263
Intel "I.263" H.263
Microsoft MPEG-4
Microsoft MPEG-4 Version 2
Microsoft MPEG-4 Version 3
DivX MPEG-4 Video
DivX MPEG-4 Video
Aware Motion Wavelets Video Codec (not registered with Microsoft as of March 10, 2000)
- A 12 -
Anhang
5.2
Durch Microsoft registrierte Codecs
Compressor
Code
ANIM
AUR2
AURA
BT20
BTCV
CC12
CDVC
CHAM
CPLA
CVID
CWLT
DUCK
DVE2
DXT1
DXT2
DXT3
DXT4
DXT5
DXTC
FLJP
GWLT
H260
H261
H262
H263
H264
H265
H266
H267
H268
H269
I263
I420
IAN
ICLB
ILVC
ILVR
IRAW
IV30
IV31
IV32
IV33
IV34
IV35
IV36
IV37
IV38
IV39
IV40
IV41
IV42
IV43
IV44
IV45
IV46
Description
Intel - RDX
AuraVision - Aura 2 Codec - YUV 422
AuraVision - Aura 1 Codec - YUV 411
Brooktree – MediaStream codec
Brooktree – Composite Video codec
Intel - YUV12 codec
Canopus - DV codec
Winnov, Inc. - MM_WINNOV_CAVIARA_CHAMPAGNE
Weitek - 4:2:0 YUV Planar
Supermac - Cinepak
reserved
Duck Corp. - TrueMotion 1.0
InSoft - DVE-2 Videoconferencing codec
reserved
reserved
reserved
reserved
reserved
DirectX Texture Compression
D-Vision - Field Encoded Motion JPEG With LSI Bitstream Format
reserved
Intel - Conferencing codec
Intel - I263
Intel - Indeo 4 codec
Intel - RDX
InSoft - CellB Videoconferencing codec
Intel - Layered Video
ITU-T - H.263+ compression standard
Intel - YUV uncompressed
Intel - Indeo Video 3 codec
Intel - Indeo Video 3.1 codec
- A 13 -
Anhang
5.3
IV47
IV48
IV49
IV50
MP42
MPEG
MRCA
MRLE
MSVC
NTN1
qpeq
RGBT
RT21
RVX I
SDCC
SFMC
SMSC
SMSD
SPLC
SQZ2
SV10
TLMS
TLST
TM20
TMIC
TMOT
TR20
V422
V655
VCR1
VIVO
VIXL
VLV1
WBVC
XLV0
YC12
YUV8
YUV9
YUYV
ZPEG
Intel - Indeo 5.0
Microsoft - MPEG-4 Video Codec V2
Chromatic - MPEG 1 Video I Frame
FAST Multimedia - Mrcodec
Microsoft - Run Length Encoding
Microsoft - Video 1
Nogatech - Video Compression 1
Q-Team - QPEG 1.1 Format video codec
Computer Concepts - 32 bit support
Intel - Indeo 2.1 codec
ntel - RDX
Sun Communications - Digital Camera Codec
Crystal Net - SFM Codec
Radius - proprietary
Radius - proprietary
Splash Studios - ACM audio codec
Microsoft - VXtreme Video Codec V2
Sorenson - Video R1
TeraLogic - Motion Intraframe Codec
Duck Corp. - TrueMotion 2.0
Horizons Technology - TrueMotion Video Compression Algorithmus
Duck Corp. - TrueMotion RT 2.0
Vitec Multimedia - 24 bit YUV 4:2:2 format (CCIR 601).
Vitec Multimedia - 16 bit YUV 4:2:2 format.
ATI - VCR 1.0
Vivo - H.263 Video Codec
Miro Computer Products AG - for use with the Miro line of capture cards.
Videologic - VLCAP.DRV
Winbond Electronics - W9960
NetXL, Inc. - XL Video Decoder
Intel - YUV12 codec
Winnov, Inc. - MM_WINNOV_CAVIAR_YUV8
Intel - YUV9
Canopus - YUYV compressor
Metheus - Video Zipper
Codecs für DIB Kompression
Compressor
Code
CYUV
FVF1
IF09
JPEG
MJPG
PHMO
ULTI
VDCT
VIDS
YU92
Description
Creative Labs, Inc - Creative Labs YUV
Iterated Systems, Inc. - Fractal Video Frame
Intel - Intel Intermediate YUV9
Microsoft - Still Image JPEG DIB
Microsoft - Motion JPEG DIB Format
IBM - Photomotion
IBM - Ultimotion
Vitec Multimedia - Video Maker Pro DIB
Vitec Multimedia - YUV 4:2:2 CCIR 601 for V422
Intel - YUV
- A 14 -
Credits
Danksagung
An dieser Stelle möchte ich allen danken, die zum Entstehen dieser Arbeit
beigetragen haben. Ich danke Herrn Prof. Dr. Konrad Walliser für seine Betreuung
dieser Arbeit von Seiten der Fachhochschule München.
Vielen Dank an Herrn Dipl.-Ing. Gerhard Stoll und Herrn Dipl.-Phys. Philip
Mackensen, meine Betreuer im Institut. Ich möchte auch allen anderen Mitarbeitern
der Abteilung AS des Instituts für Rundfunktechnik danken, die mir immer mit Rat
und einigem Humor zur Seite gestanden haben, allen voran auch Herrn Olliver
Dreier, welcher mich als Praktikant unterstützte und Herrn Michael Wechsel, meinem
freundlichen Zimmerkollegen.
Ein ganz besonders herzlicher Dank geht an Stephanie, "Martin 2" und meine lieben
Eltern, die mir geholfen und beigestanden haben.
-C1-
Credits
Lebenslauf des Autors
Name:
Geburtstag:
Geburtsort:
Eltern:
Martin Schmalohr
25. Mai 1974
München
Vater: Gerhard Schmalohr
Mutter: Edith Schmalohr
Familienstand:
ledig
Staatsangehörigkeit: deutsch
Anschrift:
Defreggerstr. 29, 85540 Haar
Schulbesuch:
1980 – 1984 .... Grundschule Haar am Jagdfeldring
1984 – 1993 .... Ernst-Mach-Gymnasium Haar
Leistungskurse: Wirtschaft/Recht, Physik
Facharbeit: Physik, Rechnergestützte
Geschwindigkeitsmessung
Abschluß:
Abitur
Studium:
Studium der Elektrotechnik und Informationstechnik
1993 – 1997 .... Technische Universität München
Vordiplom: WS1996/97
1997 – 2000 .... Fachhochschule München
Schwerpunkt Datentechnik
2000 ................ Diplomarbeit am Institut für Rundfunktechnik
Praktikum:
1993 ................ Henschel & Co. KG, Mechanische Grundpraxis
1997 ................ Deutsches Museum München, Elektroniklabor
1999 ................ Siemens AG-ZT, F&E Radarsysteme
Berufserfahrung:
1990 – 1993 .... Mc Donald’s, Rotation in Service und Produktion
1997 – 1998 .... Tele München, Fernseh GmbH & Co
Dokumentation interner Datenbankstrukturen
München, den 27. Dezember 2000
-C2-

Diplomarbeit

Transcription

Similar documents

Einige Stellungnahmen der Hapimag Partner zu dieser Anregung

SIP-basierte Dienstentwicklung für das IMS CN (UMTS Release 5

Agilent ChemStation - Agilent Technologies

Förderinfo Mai 2015 - Technische Universität Braunschweig

Laser Disc

Agilent ChemStation - Agilent Technologies

Leseprobe - it-journalist.de

BLAST Tutorial: