Warenkorb
0 Artikel | US$ 0,00
ID 5555
Rutsch, Bastian: Spezifische Anforderungen der Streamingtechnologie und Entwicklung einer
mobilen Übertragungseinheit: Am Beispiel der Mobile Streaming Unit (MSU) unter
technologischer Berücksichtigung der Funktionalitäten von Real Media, Windows Media und
Quicktime - Hamburg: Diplomica GmbH, 2002
Zugl.: Brandenburg, Fachhochschule, Diplomarbeit, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
2
INHALT
Seite
ABBILDUNGSVERZEICHNIS
4
TABELLENVERZEICHNIS 5
1. EINLEITUNG
6
1.1 Ziele der Diplomarbeit und Motivation
6
2.
TECHNOLOGISCHE
BETRACHTUNGEN
8
2.1
Entwicklung
einer
Technologie 8
2.2 Zielstellungen von Streaming Media
9
2.3
Ein
Definitionsversuch
10
2.4
Als
alles
begann 11
3.
STREAMINGTECHNOLOGIE
13
3.1 Grundlegende Funktionsweise eines Streamingszenarios
13
3.2 Audiovisuelle Grundlagen für die Erstellung von Streaming Content 15
3.3
Warum
Kompression
17
4. PROTOKOLLARCHITEKTUREN UND KOMMUNIKATIONSMODELLE 19
4.1
ISO/OSI
Referenzmodell
19
4.2
Protokollarchitektur
von
TCP/IP
21
4.3 Protokolle für Streaminganforderungen
23
4.4 Intelligente Netzstrukturen und Servermodelle
27
5. ANWENDUNGSMODELLE DER STREAMING MEDIA TECHNOLOGIE
30
5.1
Streaming
Markt 30
5.2 Real Networks Eine Erfolgsgeschichte
31
5.2.1 Grundlegende Komponenten und Funktionsphilosophie
34
5.2.2 Contentgenerierung - Real
Producer
35
5.2.3 Contentdistribution - Real Server
43
5.2.4
Contentdarstellung
-
Real
Player
53
5.2.5
Metasprache
SMIL
57
5.2.6
Schlussbemerkung
und
Ausblick
58
5.3 Windows Media Technologie Der große Verfolger Microsoft
59
5.3.1 Grundlegende Komponenten und Funktionsphilosophie
61
5.3.2 Contentgenerierung - Windows Media Encoder
62
5.3.3
Contentdistribution
- Windows Media Server
74
5.3.4
Contentdarstellung
-
Windows Media Player
81
5.3.5
Schlussbemerkung
und
Ausblick
84
3
5.4 Quicktime von Apple Der schlafende
Streamingriese
85
5.4.1 Grundlegende Komponenten und Funktionsphilosophie
86
5.4.2 Contentgenerierung - Sorenson
Broadcaster
87
5.4.3
Contentdistribution
-
Quicktime
Server
91
5.4.4
Contentdarstellung
-
Quicktime
Player
93
5.4.5
Schlussbemerkung
und
Ausblick
95
6.
ENTWICKLUNG
DER
MSU
96
6.1 Motivation für die Entwicklung einer solchen Einheit
96
6.2 Anforderungen an eine mobile Übertragungseinheit
97
6.3 Definition einer Zielgruppe und von Einsatzgebieten
98
6.4
Finanzielle
Aspekte
99
6.5
Komponenten
der
MSU 101
6.6 Funktionsweise und Zusammenspiel der Komponenten
102
6.6.1
Externes
Kameramodul
102
6.6.2
Externes
Audiomodul 105
6.6.3
Signalaufnehmendes
Videomodul
1 106
6.6.4
Weiterverarbeitendes
Videomodul
2
108
6.6.5
Internes
Audiomodul
1
109
6.6.6
Internes
Audiomodul
2
111
6.6.7
Encoder
Netzwerkmodul
112
7.
EINSATZSZENARIEN
DER
MSU
116
7.1 Allgemeine Anwendungen in der Medienwelt
116
7.2
Berlinale
2001
117
7.3
Fritz
Waldländer 129
8. ZUSAMMENFASSUNG
134
9.
LITERATURVERZEICHNISS
136
GLOSSAR
139
ANHANG
145
4
ABBILDUNGSVERZEICHNIS
Abbildung 1:
Funktionelle Übersicht eines Streamingszenarios
Abbildung 2:
Das ISO/OSI Modell
Abbildung 3:
Schichtenverhältnisse von TCP/IP und ISO/OSI
Abbildung 4:
Einordnung der Streamingprotokolle in das ISO/OSI Modell
Abbildung 5:
Unicast, Multicast und Protokolle
Abbildung 6:
Intellivision Data Center
Abbildung 7:
Neuralcast Funktionalität
Abbildung 8:
Frontend des Real Producer 8
Abbildung 9:
Recording Wizzard des Real Producers
Abbildung 10: Real Media Editor
Abbildung 11: Administration des Real Servers
Abbildung 12: Mount
Points
Abbildung 13: Encoder Mount Point
Abbildung 14: Real Media Recording Wizzard
Abbildung 15: Real System Administrator Realm
Abbildung 16: Real Player Frontend
Abbildung 17: Einstellungen Real Player
Abbildung 18: SMIL Darstellung im Real Player
Abbildung 19: Windows Media Encoder Frontend
Abbildung 20: Windows Media Encoder Startup Screen
Abbildung 21: Windows Media Assistent für neue Sitzungen - Geräteoptionen
Abbildung 22: Windows Media Assistent für neue Sitzungen - Übertragungsverbindung
Abbildung 23: Windows Media Profilverwaltung
Abbildung 24: Windows Media Profilerstellung 1
Abbildung 25: Windows Media Profilerstellung 2
Abbildung 26: Windows Media Profilerstellung 3
Abbildung 27: Windows Media Sitzungseigenschaften
Abbildung 28: Windows Media System Kommunikationswege
Abbildung 29: Windows Media Administrator
Abbildung 30: On Demand Unicast Veröffentlichungspunkte
Abbildung 31: Broadcastunicast Veröffentlichungspunkte
Abbildung 32: Windows Media Player 7 Frontend
Abbildung 33: Windows Media Player Optionen - Netzwerk
Abbildung 34: Windows Media Player Optionen - Leistung
Abbildung 35: Sorenson Broadcaster Quality
Abbildung 36: Sorenson Broadcaster Sources
Abbildung 37: Sorenson Broadcaster Publishing
Abbildung 38: Sorenson Broadcaster Network
Abbildung 39: Sorenson Broadcaster Recording
Abbildung 40: Quicktime Player 5 Frontend
Abbildung 41: Quicktime Player Settings Connection Speed
Abbildung 42: Das externe Kameramodul mit den dazugehörigen Schnittstellen
Abbildung 43: Das externe Audiomodul mit den dazugehörigen Schnittstellen
Abbildung 44: Das signalaufnehmende Videomodul mit den dazugehörigen Schnittstellen
Abbildung 45: Das weiterverarbeitende Videomodul mit den dazugehörigen Schnittstellen
Abbildung 46: Das interne Audiomodul 1 mit den dazugehörigen Schnittstellen
Abbildung 47: Das interne Audiomodul 2 mit den dazugehörigen Schnittstellen
Abbildung 48: Das Encoder-Netzwerkmodul mit den dazugehörigen Schnittstellen
Abbildung 49: Globales Projektszenario des Berlinale Projektes
Abbildung 50: Signalweg der aufnehmenden Komponenten zur MSU
Abbildung 51: Konfiguration der verschiedenen Signalwege in das Netz (Quelle)
Abbildung 52: Rundfunk IP Angebot der Telekom
Abbildung 53: Webszenario für das Projekt
Abbildung 54: Konfiguration der verschiedenen Signalwege aus dem Netz (Senke)
Abbildung 55: Zugriffszahlen Real Server Live
Abbildung 56: Zugriffszahlen Real Server On Demand
Abbildung 57: Projektrealisierung Fritz Waldländer
5
TABELLENVERZEICHNIS
Tabelle 1:
Entwicklung der Streamingformate von Real Networks, Microsoft und Apple
Tabelle 2:
Arten von Datentransfer bei Streaminganwendungen
6
1. EINLEITUNG
1.1 MOTIVATION UND ZIELE DER DIPLOMARBEIT
Die vorliegende Diplomarbeit entstand im Jahre 2001 und ist in einer für mich sehr
erkenntnisreichen Zeit gewachsen, die von persönlichen Errungenschaften und einem
sehr medienorientierten Arbeitsumfeld geprägt worden ist. In Ihr spiegeln sich außer
den technologischen Fakten die persönliche Erkenntnis wider, etwas besonderes in
meinem Leben erreicht zu haben.
Das vergangene Jahr war für mich eine intensive Zeit der Recherche und
Materialsammlung. Dabei versuchte ich, eine junge Technologie vorzustellen und das
mir darüber bekannte Wissen mit neuen Erkenntnissen in Beziehung zu bringen.
Die Schwerpunkte der dargelegten Diplomarbeit beziehen sich auf Erkenntnisse der
Streamingtechnologie, stellen konkrete Anwendungsmöglichkeiten vor und wenden
gewonnene Erkenntnisse auf die Entwicklung einer mobilen Streaming Einheit an.
Dabei werden alle an einem Streamingszenario beteiligten Komponenten, die sie
umgebenden Medien, sowie deren Eigenschaften betrachtet. Dabei wird aus den
Positionen des Entwicklers und des Anwenders Stellung bezogen. Aspekte der
Informatik, Erkenntnisse aus Kompressionstechnologie, Wirtschaft und Marktpolitik
spielen dabei eine Rolle. Um das gewonnene Wissen und die daraus entstandene
technische Komponente nicht nur auf der theoretischen Ebene zu betrachten, wird auf
den praktischen Einsatz bei zwei hochinteressanten Projekten eingegangen und deren
Realisierung geschildert. Um die genannten Punkte zu konkretisieren, möchte ich im
folgenden die einzelnen Kapitel der Diplomarbeit nennen und vorstellen.
Im Kapitel 2 beschäftige ich mich mit grundlegenden erkenntnistheoretischen
Überlegungen, welche die Entwicklung einer Technologie betrachten, Zielstellungen der
Streamingtechnologie hinterfragen, versuchen konsolidierend zu definieren und einen
konkreten Überblick über die Anfänge der Streamingtechnologie geben.
Das Kapitel 3 dringt dann tiefer in die Materie Streaming ein, versucht die
grundlegenden Funktionalitäten zu beschreiben, gibt einen Exkurs in die audiovisuellen
Grundlagen der Videotechnik und beschäftigt sich detailliert mit der Frage, warum
Signale komprimiert werden müssen.
Im darauf folgenden Kapitel 4 wird das Funktionieren von Streaming auf der Basis von
IP analysiert, dabei das ISO/OSI Referenzmodell betrachtet und diese Erkenntnisse auf
TCP/IP abstrahiert. Zusätzlich gehe ich auf konkrete Protokollszenarien ein und stelle
innovative Netzstrukturen vor.
Die Anwenderschnittstellen der Streaming Media Technologie werden im Kapitel 5
vorgestellt; es gibt einen Überblick über den bestehenden Streaming Markt und die
Technologien von Microsoft, Real Networks und Apple. Dabei werden alle am
Streamingprozess beteiligten Softwarekomponenten erläutert und in ihrer Anwendung
beschrieben.
7
Einleitung
Das Kapitel 6 präsentiert die Entwicklung einer mobilen Streaming Einheit, welche in
der Firma streamcast media GmbH konzipiert worden ist. Es gibt einen umfassenden
Einblick in die konkreten Anforderungen an die Einheit und es werden Zielgruppen
sowie finanzielle Aspekte der Streamingtechnologie betrachtet. Zusätzlich versuche ich,
auf eine sehr konkrete Art und Weise die technischen Komponenten und ihre
zusammenhängende Funktionalität zu beschreiben.
Am Ende der Diplomarbeit werden zwei praktische Anwendungen präsentiert. In ihnen
kommt die vorgestellte Mobile Streaming Unit zum Einsatz. Hier wird durch eine sehr
detaillierte Kommentierung einzelner Arbeitsphasen, das Moment einer Produktion
beschrieben.
Das Ziel, dass mit dieser Diplomarbeit verbunden ist, wird von vielen verschiedenen
Ansprüchen beeinflusst. Zum einen soll die Arbeit den Versuch wagen, eine in ihren
Tiefen sehr komplexe Technologie zusammenzufassen und übersichtlich zu
präsentieren. Des weiteren sollen die verbreitetsten Benutzerschnittstellen vorgestellt
und eine umfassende Einführung in den Umgang mit ihnen gegeben werden. Die im
weiteren Verlauf dargestellte technische Entwicklung einer mobilen Streamingeinheit
soll theoretische Erkenntnisse mit Problemen einer praktischen Umsetzung in
Verbindung bringen.
8
2. TECHNOLOGISCHE BETRACHTUNGEN
2.1 ENTWICKLUNG EINER TECHNOLOGIE
Warum hat sich eine Technologie entwickelt, aus welchen Motivationen ist sie
entstanden und was für gesellschaftliche Einflüsse lassen aus einer Idee eine
Technologie werden?
Blicken wir zurück auf die Technologieentwicklung des Internets.
Nach dem Siegeszug des Internets, spezieller dem des World Wide Web, ist ein Netz in
unser Leben eingezogen, welches ursprünglich vom Militär entwickelt worden ist. Der
eigentliche Hintergrund der Entwicklung bestand darin, eine Kommunikationsgrundlage
zu entwickeln, die punktuelle Ausfälle problemlos kompensieren kann. Aus dieser Idee
ist das heutige Netz der Netze, das Internet, entstanden. Dieses Internet besteht derzeit
aus Tausenden von Subnetzen und bildet schon nach wenigen Jahren allurbaner
Nutzung eine Kommunikationsgrundlage, die nicht mehr wegzudenken ist. Aus dem
Medium Internet ist innerhalb kürzester Zeit ein Unterhaltungsmedium entstanden.
Diese neu erschlossene Nutzungsebene des Internets soll nun in der Lage sein,
verschiedenste Kommunikationsstrukturen zu vereinen und gesellschaftsfähig zu
machen.
1
Eine Aufeinanderfolge von sich bedingenden Zuständen lassen mich zu einer
Erkenntnis kommen: Eine Anforderung, so banal sie auch sein mag, bildet die
Grundlage für eine Idee, und die Idee wiederum ist der eigentliche Ursprung einer
Technologie.
Die Idee Audio und Video effizienter durch das Netz zu bewegen und es dem Benutzer
anzubieten, wuchs aus der Anforderung, dass es bis dato nur durch langwierigen
Download möglich war, A/V Inhalte aus dem Internet abzuspielen. Diese erste Idee
entwickelte sich rekursiv zu einer Technologie, die mit neuen Protokollen daher kam,
völlig neue Produkte auf den Markt brachte und immer neuere Anwendungsmöglichkei-
ten gebar. Diese Technologie heißt Streaming Media.
1
vgl. Internet Society, Die definitive Geschichte des Internets
9
2.2 ZIELSTELLUNGEN VON STREAMING MEDIA
Historisch betrachtet ist es die Zielstellung von Streaming Media, den kompletten und
damit aufwendigen Download von Dateien mit audiovisuellen Inhalten zu ersetzen. Der
Hauptgrund für diese erste Zielstellung war die Befriedigung gewachsener User-
Bedürfnisse, welche sich in Wartezeit, Verbindungskosten und Handling im WWW
widerspiegelten. Heute sind diese Anforderungen mit Ihren Zielen gewachsen und
verweben sich immer mehr mit den sie umgebenden Medien. Es ist also von enormer
Bedeutung, eine Technologie wie die Streamingtechnologie so zu pflegen und zu
entwickeln, dass die spezifischen Ziele einer Technologie auch andere Anforderungen
bedienen. Die Streamingtechnologie dient unter anderem den Zwecken der
Netzverbundentlastung, der Trafficdezentralisierung und der Broadcastentwicklung,
wenn man mit audiovisuellen Daten umgehen möchte. Allerdings ist die besondere
Bedeutung der Streamingtechnologie eher an den praktischen Neuerungen
festzumachen. Zum Beispiel die Möglichkeit der Streamingtechnologie in Echtzeit
arbeiten zu können, bringt für den Anwender wichtige Ziele mit sich. Es ist und bleibt
eben so, eine Technologie die keiner will, weil der Sinn für die ,,Bevölkerung" nicht
transparent ist, obwohl sie noch so tolle technische Details in sich birgt, beginnt zu
sterben bevor sie anfängt zu leben.
Heute ist mit der Streamingtechnologie vor allen Dingen das Ziel ins Auge gefasst
worden, völlig neue Publikationsmöglichkeiten zu schaffen. Es gibt vermehrt die
Meinung, in einzelnen Teilbereichen, von der kostenaufwendigen Fernsehproduktion
auf das Medium Internet auszuweichen. Übertragungen von Messen, die Vorstellung
neuer Produkte, Konzert- und Sportveranstaltungen sind alles Ereignisse, welche mit
Hilfe der Streamingtechnologie im Internet präsentiert werden können. Allerdings, und
das ist meine feste Überzeugung, wird es nicht dazu kommen, dass die
Streamingtechnologie Medien wie das Fernsehen verdrängt. Sie wird diese höchstens
ergänzen und auch das Endmedium Fernsehen wird neue Übertragungswege
beschreiten. Dies wird durch die Entwicklung des Digitalen Rundfunks mehr als
deutlich.
Es wird die Kunst sein, mit den neuen Möglichkeiten, welche das Internet für die
Übertragung von audiovisuellen Daten bietet, Anwendungen zu bedienen, die mit
anderen Medien nicht präsentiert werden können. So ist es beispielsweise denkbar, in
Zukunft die Medizin unterstützen zu können, indem Operationsbilder, z.B. einer
Endoskopie, zu Spezialisten an jeden Ort der Welt übertragen werden. Dieser kann
dann ,,Live" dem behandelnden Arzt behilflich sein. Dies ist mit herkömmlichen Medien
wie z.B. dem Telefon nicht möglich und wird für das Fernsehen nicht wirtschaftlich sein.
Auch das Arbeiten mit Archiven und Bibliotheken wird in Zukunft anschaulicher und
effizienter gelöst werden können.
Es ist an dieser Vorausschau auf eine Entwicklung deutlich zu sehen, welche
Eigendynamik die Zielstellungen einer Technologie bekommen können, wenn immer
mehr Strukturen sich einer Technologie bedienen. Wichtig dabei ist, dass durch das
Nutzen neuer Technologien ökonomische Effizienz entsteht.
10
2.3 EIN DEFINITIONSVERSUCH
Wir kommen nun dem zentralen Thema meiner Arbeit immer näher. Um mir selbst und
meinen Lesern etwas in die Hand zu geben, möchte ich versuchen, diesen so
ungenauen Begriff ,,Streaming" zu beschreiben.
Die Streamingtechnologie ist aus der Motivation entwickelt worden, multimediale
Objekte im Netz so zu referenzieren, dass der Rezipient ohne lange Wartezeit in die
Lage versetzt wird, multimediale Daten visualisiert zu bekommen.
Das bedeutet für den Anwender: keine nervenaufreibende Downloadzeit, um sich
multimedialer Inhalte zu bedienen. Das Streaming ist zudem in seiner Funktionalität an
die Technologie des Radios und der des Fernsehens angelehnt. Der jeweilige Client
wird in die Lage versetzt, sobald genügend Daten gepuffert sind, sofort den decodierten
Datenstrom als Audio oder Video abzuspielen. Die Daten werden also im eigentlichen
Sinne nicht übertragen, dann lokal gespeichert und verarbeitet, sondern kleine
Datenpakete werden gesendet, dargestellt und wieder vergessen. Dabei ist keine
Speicherung auf einer Festplatte notwendig. Streaming beschreibt eine Technologie,
welche einen Datenstrom mit beliebigen, zeitlich skalierbaren Daten während einer
Paketübertragung optisch oder akustisch darstellt. Die ankommenden Datenpakete
werden durch eine spezielle Softwareimplementierung aufgenommen und sofort in
Echtzeit wiedergegeben.
11
2.4 ZUR ENTSTEHUNGSGESCHICHTE DER STREAMINGTECHNOLOGIE
Als im Jahr 1991 die Entwicklung des Internets in der Vorstellung des WWW mündet,
hat die Zahl der Hosts, im kurz zuvor abgeschafften Apranet, die Zahl 100.000 bereits
überschritten. Der Erfinder und Entwickler Tim Berners-Lee leitete mit einer Gruppe von
Physikern am Kernforschungszentrum CERN in Genf ein Softwareprojekt in die Wege,
dass als globales, interaktives Informationssystem für die Hochenergiephysik dienen
sollte. Mit seiner Hilfe ließen sich Informationen im Computernetz über eine einheitliche
Oberfläche benutzerfreundlich integrieren. Das Ergebnis der darauffolgenden
Entwicklungsarbeiten ist heute unter dem Namen World Wide Web, WWW oder W3
bekannt. Es ist mehr eine Initiative als ein Produkt, deren Ziel es ist, mit Hilfe von
Hypermedia-Informationssystemen Zugang zu global verteilten Dokumenten im Internet
zu gewähren. Ein Hypertext- oder Hypermediadokument besteht im Grunde lediglich
aus zwei unterschiedlichen Komponenten: den in sich inhaltlich abgeschlossenen
Informationseinheiten (nodes) und ihren Verbindungsstrukturen (links). Im Konzept des
World Wide Web werden die nodes in der "HyperText Markup Language (HTML)",
einem Subset der Standard Generalized Markup Language, beschrieben, und die links
für die Verwendung in einem global verteilten Informationsnetz als "Universal Resource
Locator (URL)" definiert. Nodes und links zusammen bilden also eine netzartige
Struktur, bei der die Knoten die Informationseinheiten und die Verbindungsstücke die
Netzfäden darstellen (daraus leitet sich auch der Name "World Wide Web" ab). Diese
Struktur erlaubt es, mit geeigneten Hypertext-Browsern sehr komfortabel in global
verteilten Informationsbeständen zu navigieren.
2
Damit war die Grundlage geschaffen, das Internet für die breite Masse der Bevölkerung
transparent zu machen und die Arbeit im Internet wesentlich zu erleichtern. Ein Jahr
später besteht das Internet aus 1.000.000 Hosts und im Jahre 1992 findet die erste
Audio und auch die erste Video Sendung statt. In den nächsten 3 Jahren explodiert die
Anzahl der Hosts, die Zugriffe im NSFNET übersteigen ein Transfervolumen von 10
Trillionen Bytes im Monat und die Wirtschaft beginnt, sich ernsthaft für das Internet zu
interessieren. Im Jahr 1995 schlägt die Geburtsstunde des Streamings: Real Networks
(damals noch Progressive Networks) macht mit Real Audio 1.0 die erste
Echtzeitübertragung für Audio möglich. Dass Real Networks damit als Streaming
Pionier bezeichnet werden kann und auch für die ersten Entwicklungsstufen
verantwortlich ist, zeigt die Tabelle 1 auf der nächsten Seite. Jahre später nimmt der
Branchenriese Microsoft die Verfolgung auf und ist erst im Jahre 2001 dabei, mit Real
Networks gleichzuziehen. Der dritte Große im Bunde ist das Quicktimeformat der Firma
Apple und wird in der Zukunft eine entscheidende Rolle spielen.
2
vgl. http://www.tuwien.ac.at/histu/histu/www_history.html
12
Zur Entstehungsgeschichte der Streamingtechnologie
Real Networks
Microsoft
Apple (Quicktime)
04/1995 Vorstellung des ersten
Real Players und Real
Audio 1.0
1991
Vorstellung von Quicktime
in der Version 1.0
10/1995 Vorstellung von Real
Audio 2.0
1992
Erweiterung auf Version
1.5, mit einer doppelt so
schnellen Verarbeitung der
Inhalte
03/1996 Streaming
Media
Agree-
ment zwischen Microsoft
und Progressive Networks
1994
Vorstellung von Quicktime
2.0, Bildschirmfüllende
Videos mit neuen
Sprachumschaltungsmög-
lichkeiten, MPEG1 Ströme
ohne spezielle
Hardwareerweiterungen
Abspielbar
09/1996
Vorstellung von Real
Audio 3.0
1991-
1992
Windows 3.0, mit den
Multimediaerweiterungen
1.0
(Softwarebasierte
Wiedergabe von
AVI Dateien und
Geräteunterstützung)
1995
Erweiterung auf Version
2.5, Integration von MIDI
und durchsuchbaren
Texttracks
10/1996
RTSP als offener Standart
für Streaming Media
Übertragung
02/1997 Vorstellung Real Video
1.0
07/1997 Vertiefung
der Beziehung
zwischen Progressive
Networks und Microsoft
09/1997 Aus
Progressive
Networks wird Real
Networks
10/1997 Vorstellung von Real
System 5.0
1992-
1996
Windows 95 und Netshow
1.0
(erste interne Tests mit
Kompressionstechnologien)
1997
Präsentation von Quick-
time 4.0, Verwendung des
Sorenson Codecs,
Qdesign und Qualcoom
02/1998 Real Networks kauft
Hauptkonkurrenten VIVO
Software
04/1998 Ankündigung von SMIL
Support und Vorstellung
von Real System G2
10/1998 Partnerschaft zwischen
Real Networks und
Netscape
11/1998 Vorstellung
Real
Producer
G2
1997-
1999
Windows 98 und Windows
Media Technologie 4.0
(komplette Überarbeitung
der Netshowtechnologie zur
Windows Media
Technologie)
1999
Quicktime 4.0 wird
vorgestellt, Streaming in
Echtzeit unter Nutzung von
RTP und RTSP möglich
02/1999 Real System G2 zur
führenden Streaming
Media Plattform gewählt
03/1999 Integration von AOL
Instant Messenger
Service in Real player G2
04/1999
Real Networks übernimmt
Xing Technologies als
führenden MP3 Entwickler
05/1999 Vorstellung der Real
Jukebox
11/1999
Real Player 7.0
05/2000 Vorstellung Real System
8.0
2000-
2001
Windows 2000 und
Windows Media
Technologie 7.0
(Überarbeitung des
Userinterfaces,
Optimierung der
Wiedergabequalität)
2001
Vorstellung von Quicktime
5.0, Unterstützung von
SMIL, viele neue
Funktionen und Skins,
Darwin Projekt
Tabelle 1 - Entwicklung der Streamingformate von Real Networks, Microsoft und Apple
3,4
3
vgl. Tobias Künkel, Streaming Media S.58-59 S.107, Addison-Wesley Verlag
4
vgl. http://mediasrv.cs.uni-dortmund.de/lehre/Dtvideo_SS2001/pdf/QTVideo_kap4.pdf
13
3. STREAMINGTECHNOLOGIE
3.1 GRUNDLEGENDE FUNKTIONSWEISE EINES STREAMINGSZEANRIOS
In diesem Kapitel soll nun die konkrete und grundsätzliche Funktionsweise eines
klassischen Streamingszenarios erläutert werden.
Die Streamingtechnologie verlangt im wesentlichen 3 Komponenten:
· Encoder
· Server
· Decoder
Der Encoder ist eine Software, die in Verbindung mit den Hardwarekomponenten eines
Rechners anliegende AV-Signale in IP-Packete verpackt. Dabei findet eine hohe
Komprimierung des Ausgangsmaterials statt. Diese Komprimierung muss sehr effizient
sein, da die Streamingtechnologie, zumindest beim Live-Streaming, Echtzeit verlangt.
Die Daten werden noch während des Encodingvorgangs zu einem Server geschickt,
bzw. der Server handelt mit dem Encoder über einen definierten Port eine Verbindung
aus.
Von Wichtigkeit ist an dieser Stelle das vereinbarte Protokoll, welches den Umgang mit
den Daten bestimmt. Dieses Protokoll ist durch das ISO-OSI Modell spezifiziert, setzt
auf IP auf und kann durch Encodereinstellungen genauer bestimmt werden.
Der einfachste Fall ist das sogenannte HTTP-Streaming. Das Protokoll HTTP wird aber
nur von einfachen Webservern genutzt, und ist für das Live-Streaming ungeeignet.
HTTP ist TCP basiert, was verbindungsorientierte Datenübertragung bedeutet.
Verbindungsorientierte Datenübertragung wiederum stützt sich auf das Prinzip einer
,,sicheren" Datenübertragung. Der Clientrechner muss also jedes ankommende Paket
quittieren. Fehlt ein Paket, wird es erneut angefordert und der Stream dadurch
unterbrochen. Durch diesen zusätzlich benötigten Kontrollkanal wird außerdem das
Netz stark belastet.
Für das "handeln" von gestreamten Datenpaketen werden also speziell auf
Streaminganwendungen abgestimmte Protokolle benutzt, welche auch spezielle Server
notwendig machen, die mit den Streamingprotokollen zusammenarbeiten können.
Diese Server sind ebenfalls Softwarelösungen mit sehr mächtigen Funktionen. Sie
regeln die Verteilung und Handhabung der Datenströme. Die Art der
Streamingprotokolle wird durch das jeweilige Encodersystem bestimmt. Zumeist
basieren diese Protokolle für den Datentransfer auf den Grundlagen von UDP. Diese
Protokollart arbeitet im Gegensatz zu TCP verbindungslos. Auf eine
Empfangsbestätigung wird verzichtet und verlorengegangene Pakete müssen nicht neu
angefordert werden. Das ist für den Streamingprozess von besonderer Bedeutung. Es
ist nämlich nie voraussehbar, ob das Internet eine bandbreitenkonstante Verbindung
aufrecht erhalten kann. Das Ergebnis dieser Protokolleigenschaft wird dem Anwender in
Situationen gegenwärtig, in denen auf einmal das Bildsignal schlechter wird oder
ausfällt, ohne dass der Stream unterbrochen wird.
14
Grundlegende Funktionsweise eines Streamingszenarios
Ein weiteres wichtiges Merkmal sind die dem Protokoll zugrunde liegenden Zeitstempel,
die jedes Paket während des Verarbeitungsprozesses erhält und somit eine
zeitsynchrone Darstellung ermöglichen.
Der Client, welcher den eigentlichen Rezipienten und damit das Ziel aller Anwendungen
darstellt, kann dann im einfachsten Fall über eine Webseite und unter Verwendung
eines URL den Datenstrom bekommen. Hier ist die Anwendung sehr trivial. Ist man im
Besitz eines Decoders (Players) mit allen nötigen Plug-Ins und der relevanten Adresse,
kann der Stream empfangen und abgespielt werden.
Abbildung 1 - Funktionelle Übersicht eines Streamingszenarios
Die Abbildung 1 zeichnet ein sehr triviales Bild, welches den grundlegenden Workflow
eines Streamingszenarios im Internet darstellt. Es soll einzig dazu dienen, das globale
Funktionieren des Streamings graphisch darzustellen und den grundsätzlichen
Signalfluss vom Produzierenden zum Rezipienten deutlich zu machen.
15
3.2 AUDIOVISUELLE GRUNDLAGEN FÜR DIE ERSTELLUNG VON STREAMING
CONTENT
Wenn ich heute gefragt werde, was denn alles notwendig ist um eine Internetübertra-
gung für Streaminganwendungen videotechnisch vorzubereiten, dann ist die Antwort
sehr detailliert. Denn unabhängig vom Endmedium werden für jede am Produktionspro-
zess beteiligte Komponente, hohe Anforderungen gestellt. Diese sind einerseits techni-
scher Natur, andererseits müssen sie gestalterischen Spielraum ermöglichen, um den
Intentionen der Auftraggeber gerecht zu werden. Für eine Videoproduktion ist die Wahl
der Komponenten abhängig von der inhaltlichen Anforderung. Es gilt hier wie in vielen
anderen Produktionsprozessen auch: eine optimale Ausgangsqualität liefert das beste
Endergebnis. Der Produktionsprozess ist durch ökonomische Parameter bestimmt. Das
vorhandene Budget wird immer zu einer Konfiguration führen, die aus Kompromissen
besteht.
Die Spezifikationen der Streamingtechnologie erfordern in jedem Fall eine optimale
Ausgangsqualität, um später ein gutes Encodingergebnis zu bekommen. Hier ist aus
technischer Sicht die Qualität von DV bzw. DVCam ausreichend.
Das Ausgangsmaterial
muss vor dem Zerlegen in IP-Packete noch einmal formatiert bzw. umgerechnet wer-
den. Um die Funktionsweise der dafür benutzten Videocodecs verstehen zu können,
sollte man wissen, das Videoinformationen in drei Elemente gegliedert werden können:
5
· Das redundante Element
Dazu gehören alle Informationsteile, die trotz bereits erfolgter Übermittlung ein zweites
oder gar mehrfaches Mal wiederholt werden. Ein typisches Videosignal enthält ein ho-
hes Maß an natürlicher Redundanz. Räumlich benachbarte Bildpunkte innerhalb eines
Bildes sind zueinander häufig von sehr ähnlichem Informationsgehalt oder gar identisch.
Dasselbe gilt für große Bildbereiche zeitlich aufeinander folgender Fernsehbilder.
· Das irrelevante Element
Unser Auge kann bestimmte objektiv vorhandene Bildinformationen nicht erkennen.
Dies kann auch auf bestimmte ,,Fehler" im Bild zutreffen. Diese Anteile an der Bildinfor-
mation bezeichnet man als Irrelevanz.
· Das Kern-Element
Dies ist der verbleibende, wesentliche Teil der Videoinformation, der weder redundant
noch irrelevant ist.
5
vgl.
Panasonic 1999, Das Videokompressionsbuch, Matsushita Electric Industrial Co., Ltd. Video Systems Division
16
Audiovisuelle Grundlagen zur Erstellung von Streaming Content
Wie die Kompressionsverfahren auf die verschiedenen Bildanteile reagieren, wird im
nächsten Kapitel besprochen. Hier ist nur folgendes wichtig: je höher die Anteile von
Kerninformationen, also z.B. weniger Bildrauschen, desto besser wird die letztendliche
Bildqualität nach dem Encoding sein.
Aber nicht nur die technische Qualität einer Kamera ist entscheidend für das Endpro-
dukt, sondern auch das bewusste Drehverhalten.
6
Hier spielen die Aspekte Kamera-
einsstellung, im Sinne von Einstellungsgröße und die Kamerabewegungen eine ent-
scheidende Rolle. Der Kameramann muss berücksichtigen, das die spätere Darstellung
im Internet um ein vielfaches kleiner als eine Vollbildauflösung ist. Hier erfolgt zumeist
eine Reduzierung, um von einer PAL Auflösung auszugehen, von 768x576 auf z.B.
192x144 Pixel. Es ist also sinnvoll, bei der Aufnahme mit wenig Totalen und vielen
Naheinstellungen zu arbeiten. Das bringt zugleich Vorteile für das Encoding und das
spätere subjektive Bildempfinden des Betrachters.
Die Kompressionsalgorithmen arbeiten auf der Basis von Differenzbilderkennung und
speichern nicht die kompletten Inhalte eines Frames. Zwar sind moderne Algorithmen
schon in der Lage, zusätzliche Bildbewegungen zu erkennen, aber grundsätzlich gilt
auch hier die Regel: um so weniger bzw. ruhiger eine Kamera arbeitet, desto besser
kann ein Kompressionsalgorithmus mit den Bildinformationen umgehen. Auch die gute
Ausleuchtung einer aufzunehmenden Bildsequenz erhöht die Qualität des Ergebnisses
und das subjektive Wahrnehmungsgefühl des Zuschauers. Das hat technologische
Gründe:
Gute Lichtverhältnisse sorgen für bessere Farbreflexionen, optimale Kontrastverhältnis-
se, sorgen für sauberere Kanten und Zeichnungen von Objekten. Sie verringern die
Ursache für das schon erwähnte Bildrauschen. Ist eine Szene schlecht ausgeleuchtet
oder herrschen einfach keine guten Lichtverhältnisse, entstehen bei zu wenig Licht un-
genaue Zeichnungen sowie hohe Rauschanteile und bei zuviel Licht hohe Kontraste
und zu harte Konturen. Die übermäßige Lichteinstrahlung ergibt dann überstrahlte Flä-
chen, dunkle Schatten und wenig Mitteltöne, welche nach dem Encoding in Flächen
münden, die jegliche Zeichnung verloren haben.
Alle genannten Aspekte sind natürlich teilweise idealistisch und im ,,wahren Leben" sel-
ten vollständig zu realisieren. Sie sollten aber als Anspruch für jeden Streamingprodu-
zierenden gelten.
6
vgl. Tobias Künkel, Streaming Media S.43-46, Addison-Wesley Verlag
17
3.3 WARUM KOMPRESSION
Eine der Grundlagen für das erstaunliche Funktionieren menschlicher Wahrnehmung ist
die gezielte Vernichtung von Informationen. In jeder Sekunde werden wir von visuellen,
akustischen und taktilen Informationen überschwemmt. Unser Nervensystem ist jedoch
perfekt dafür ausgelegt, diese Informationsflut aufgrund von bereits vorliegenden Infor-
mationen und Erfahrungen zu filtern, so dass nur ein kleiner Bestandteil der Signale neu
verarbeitet werden muss, um die darin enthaltenen Informationen aufzunehmen. Dieses
Konzept menschlicher Wahrnehmung und die biologischen Grenzen unserer Wahr-
nehmungsorgane, werden bei der Datenkompression gezielt genutzt, um nur wirklich
die Information zu übertragen, die unser Gehirn als mehr oder weniger relevant betrach-
tet. Bei der digitalen Datenübertragung bestimmt die zur Verfügung stehende Bandbrei-
te, wie viel Information entfernt werden muss und wie detailliert Bild und Ton übertragen
werden kann. Gerade für die Nutzung von Audiovisuellen Daten im Internet ist es von
besonderer Bedeutung eine hohe Datenreduktion vorzunehmen, denn hier sind die auf-
erlegten Zwänge einer geringen Bandbreite am intensivsten. Wie schon im vorherigen
Abschnitt erwähnt werden Kompressionsergebnisse immer von individuellen Einflüssen
begleitet. Was für den einen relevante Information darstellt, ist für den anderen irrele-
vant. Das wichtige informationshaltige Kernelement ist also nicht eindeutig definierbar
sondern immer abhängig von einer gestellten Anforderung.
7
Bei diesem ganzen Trubel um Kompressionsalgorithmen, Bandbreiten, Kernelementen
und Irrelevanzen stellt sich doch die Frage, warum Kompression überhaupt nötig ist?
Alle erdachten Funktionalitäten des Internets unterliegen zwar physikalischen Zwängen;
aber hätte man denn nicht, wo doch alles in unseren Köpfen gewachsen ist, ,,kompatib-
ler" Denken und Schaffen können? Ich würde diese mir selbst gestellte Frage mit einem
,,klaren" Jein beantworten. Es ja gerade die modulare Architektur des Internets die je-
derzeit völlig neue Anforderungen umsetzen kann. Es können natürlich auch nicht
Abermillionen von neuen Kabeln in alle Welt verlegt werden, um den riesigen Daten-
mengen gerecht zu werden. Und man hat dies auch nicht vorhersehen können.
Aber ich denke, etwas mehr Kongenialität und eine etwas weniger aggressive
Marktpolitik unter all den Entwicklern und Konzernen würde uns dem eigentlichen Ziel,
der gemeinsamen Forschung, ein Stück weit näher bringen. Aber zurück zum
eigentlichen Thema.
Da stehen wir nun mit unseren riesigen Datenmengen und versuchen sie unter dem
Anspruch der Qualitätserhaltung so weit zu komprimieren, dass sie mit Hilfe der vor-
handenen Infrastruktur im Internet übertragen werden können. Wie anspruchsvoll diese
Aufgabe ist, verdeutlichen folgende Fakten:
Ein unkomprimiertes Audiosignal in CD Qualität benötigt ungefähr 1400 kbit/s. Errech-
nen lässt sich dieser Wert mit Hilfe der Multiplikation von Samplingfrequenz, Auflösung
und Anzahl der Kanäle. Die erwähnten 1400 kbit/s müssen also so komprimiert werden,
dass sie mit geringsten Qualitätsverlusten an eine normale Internetverbindung ange-
passt werden können. Diese kann oftmals nur 50 kbit/s, also ca. 1/30 der Ausgangsda-
tenmenge transportieren.
8
7
Tobias Künkel, Streaming Media S.32, Addison-Wesley Verlag
8
vgl. Tobias Künkel, Streaming Media S.36, Addison-Wesley Verlag
18
Warum Kompression
Streaminginhalte sind aber nicht nur Audioträger, sondern Video und Audio wollen
durch die gleiche Leitung.
Das Videosignal ist noch viel speicherintensiver als das Audiosignal. Der Bandbreiten-
bedarf eines unkomprimierten Videosignals beträgt unter Berücksichtigung der hiesigen
PAL-Norm 265,4 Mbit/s! Auch dieser Wert ist ein Ergebnis der Multiplikation und ergibt
sich aus Bildauflösung, Farbtiefe und Anzahl der Bilder pro Sekunde. Nun kommt noch
die Audiorate von 1,4 Mbit/s dazu, dann erhält man einen Wert von 266,8 Mbit/s, den es
zu verarbeiten gilt.
Eine 1 Kanal ISDN Verbindung stellt 0,0625 Mbit/s für den Nutzkanal zur Verfügung.
Dies ist die Ausgangssituation, theoretisch. Praktisch kommt diesem Problemfall jedoch
zugute, das für die Übertragung im Internet kein Vollbild, keine 24 Bit Farbtiefe und
auch keine 25 Bilder pro Sekunde übertragen werden müssen. Aber selbst wenn man
davon ausgeht, dass eine Auflösung von 192x144 Pixel benutzt und nur 15 Bilder pro
Sekunde übertragen werden, bleibt bei 16 Bit Farbtiefe immer noch ein zu übertragener
Wert von ungefähr 6,4 Mbit/s. Dies ist immer noch zu viel für eine Übertragung im Inter-
net. Und das, obwohl das Bild nur noch Briefmarkengroß, die Farbnuancen erheblich
reduziert und 10 Bilder pro Sekunde weniger übertragen werden. Es müssen also unter
Berücksichtigung der menschlichen Wahrnehmung eine erhebliche Menge Informatio-
nen aus dem Audio und aus dem Videosignal entfernt werden, um eine Datenrate zu
erhalten, die den Bandbreiten im Internet angepasst ist.
Wie die verschiedenen Kompressionsalgorithmen arbeiten, welcher wahrnehmungsthe-
oretischen Tricks sie sich bedienen und warum sie nicht verlustlos komprimieren kön-
nen, soll aber nicht Thema der vorliegenden Arbeit sein. An dieser Stelle möchte ich auf
ein sehr interessantes Folienskript zur Vorlesung ,,Multimedia Systeme" SS99 Teil II der
FH Brandenburg verweisen, dass eine gute Übersicht zu diesem Thema bietet.
19
4. PROTOKOLLARCHITEKTUREN UND KOMMUNIKATIONSMODELLE
Eines der kompliziertesten und anspruchvollsten Themen im Zusammenhang mit den
verschiedenen Streaming Technologien im Internet ist das Arbeiten und Funktionieren
der verschiedenen Netzwerkprotokolle. Der Informationsaustausch zwischen einzelnen
Computersystemen in heterogenen Netzen wird in einem Modell abstrahiert. Dieses
Modell stellt einen Rahmen für die Entwicklung von Protokollen zur Datenübertragung
dar. Nachfolgend werden dieses Modell und die zur Übertragung multimedialer Daten
notwendigen Protokolle im einzelnen behandelt sowie eine Betrachtung von TCP/IP
durchgeführt.
4.1 ISO/OSI REFERENZMODELL
9
Das OSI (Open Systems Interconnection) ist ein Modell und wurde von der International
Organization for Standardisation (ISO) 1974 entwickelt. Es beschreibt die Kommunika-
tion zwischen Systemen in einem offenen Schichtenmodell. Das OSI-Referenzmodell
stellt keine Implementationsspezifikationen dar, sondern lediglich einen standardisierten
Formalismus zur Beschreibung vorhandener Architekturen. Weiterhin wird ein konzepti-
oneller Rahmen zur Entwicklung zukünftiger Protokolle dargestellt. Das OSI Refe-
renzmodell enthält sieben Schichten, welche jeweils die Funktionen der Datenkommu-
nikationsprotokolle beschreiben. Jede Schicht des OSI-Modells repräsentiert eine Funk-
tion. Diese Funktion wird ausgeführt, wenn Daten zwischen kooperierenden Anwen-
dungen über ein dazwischenliegendes Netzwerk übertragen werden.
Abbildung 2 - ISO/OSI Modell
9
vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S.4-7, O'Reilly Verlag
Eine Schicht des in Abbildung 2
dargestellten Modells definiert kein
einzelnes Protokoll, sondern eine
Funktion, die mit Hilfe verschiedener,
aufgesetzter Protokolle realisiert wer-
den kann. Jede Schicht kann mehrere
Protokolle enthalten, wobei jedes
Protokoll einen Dienst bereitstellt.
Dieser entspricht der jeweiligen
Schichtfunktion. Die oft beschriebene
unabhängige Funktionalität der
Schichten wird durch das Protokoll-
Peering realisiert.
20
ISO/OSI Referenzmodell
Jedes Protokoll kann mit einem Gegenstück, dem sogenannten Peer, kommunizieren.
Ein Peer ist die Implementierung des gleichen Protokolls im gleichen Layer auf einem
entfernten System. Die Kommunikation zwischen einem Peer-Paar ist unabhängig von
den es umgebenden Schichten. Es ergibt sich die Eigenschaft des ISO/OSI Modells,
dass die Ebenen isoliert voneinander funktionieren und auf sehr triviale Weise neue
Protokolle in die Schichten implementiert werden können. Das isolierte Funktionieren
der Modellschichten ist allerdings nur auf die Implementierung neuer Protokolle und
damit neuer Eigenschaften bezogen. Das ISO/OSI Architekturmodell für die
Beschreibung von Datenkommunikationsprozessen funktioniert natürlich nur in der
Gesamtheit seiner miteinander kommunizierenden Ebenen. Jede Ebene bietet ihrer
übergeordneten Ebene Dienste an und kann die Dienste der unter ihr liegenden Schicht
in Anspruch nehmen, ohne deren innere Funktionsweise zu kennen. Der tatsächliche,
physikalische Datenaustausch erfolgt nur auf der untersten Schicht. Alle anderen
,,Peerings" haben somit einen virtuellen Charakter.
10
10
vgl. http://www.mti.uni-duisburg.de/arbeiten/lenord/internet/knetdump/node5.html
21
4.2 PROTOKOLLARCHITEKTUR VON TCP/IP
11
Im vorangegangenen Kapitel ist mit ISO/OSI ein Modell für die Datenkommunikation
vorgestellt worden. Nun soll eine Protokollfamilie betrachtet werden, welche die
Kommunikationsgrundlage des Internets darstellt. Diese Protokollfamilie ist unter dem
Namen TCP/IP bekannt. Durch TCP/IP wird eine Vielzahl von Protokollen beschrieben.
Diese haben die Aufgabe, mehrere verschiedenartige Netzwerke für Kommu-
nikationszwecke zu verbinden. Mit Hilfe dieses im Jahre 1969 entwickelten Standards
wird versucht, ein heterogenes Netzwerk aufzubauen, das folgende Features verein-
heitlichen soll:
·
Offene Protokollspezifikationen: frei zugänglich und herstellerunabhängig
·
Unabhängigkeit von einem bestimmten Netzwerkmedium
·
Einheitliches Adressierungsschema
·
Standardisierte Schnittstelle zu Anwendungsprogrammen
Im Kapitel 4.1 ist beschrieben worden, dass das ISO/OSI Modell einen unabhängigen
Kommunikationsstandard zur Verfügung stellen soll. Es soll als Beschreibungshilfe für
TCP/IP dienen. Allerdings wurde die TCP/IP Protokollfamilie wesentlich früher als das
ISO/OSI Modell spezifiziert.
Die Abbildung 3 zeigt die Adaption des ISO/OSI Modells auf TCP/IP. Es wird deutlich
gemacht, dass auch TCP/IP als Schichtenmodell beschrieben werden kann.
Abbildung 3 - Schichtenverhältnisse von TCP/IP und ISO/OSI
12
11
vgl. http://www.rvs.uni-bielefeld.de/~heiko/tcpip/kap_1_2.html
12
http://www.ruhr-uni-bochum.de/~rothamcw/Lokale.Netze/tcpip.html
22
Protokollarchitektur von TCP/IP
Ein Datenpaket muss von der Anwendung bis zur physikalischen Datenübertragung
sämtliche Schichten durchlaufen. Mit jeder Schicht bekommt das Datenpaket einen
größeren Protokollkopf. Diese Protokollköpfe werden auf der Empfängerseite zwar
rekursiv wieder abgebaut, müssen aber trotzdem übertragen werden. Damit ist auch die
Frage geklärt, warum durch einen ISDN B-Kanal nicht 64 kbit/s Anwendungsdaten
übertragen werden können. Es müssen immer, je nach verwendetem Protokoll, zirka
20 % Overhead mit eingerechnet werden.
13
Das Herzstück des TCP/IP Modells befindet sich in der Internet Schicht und existiert als
IP (Internet Protokoll). IP ist ein verbindungsloses Protokoll und stellt die grundlegenden
Dienste zur Auslieferung von Paketen, in TCP/IP Netzwerken, zur Verfügung.
14
Über der Internetschicht liegt die Transportschicht. Hier existiert sich das Ziel unserer
Reise durch die Welt der Protokolle. In dieser Schicht liegen das User Datagram
Protocol und das Transmission Control Protocol, welche die Grundlagen der zum
Streaming benutzten Protokolle bilden.
13
vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.44-49, Addison-Wesley Verlag
14
vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S.11, O'Reilly Verlag
23
4.3 PROTOKOLLE FÜR STREAMINGANFORDERUNGEN
15
Welche Unterschiede sich aus UDP und TCP basierten Protokollszenarien ergeben, soll
kurz durch deren Eigenschaften aufgezeigt werden.
Das User Datagram Protocol
· UDP erlaubt Anwendungen den direkten Zugriff auf einen Datagramm-Transportdienst,
wie er durch IP bereitgestellt wird. UDP ist ein unzuverlässiges, verbindungsloses
Protokoll. Dieses bedarf keiner geöffneten Verbindung, um Datenpakete senden zu
können. Unzuverlässig bedeutet in diesem Sinne, dass keine Techniken vorgesehen
sind, um das Ankommen der Daten am Ziel-Host zu quittieren. Dadurch ist ein
Datenaustausch mit minimalem Protokoll Overhead möglich.
Das Transmission Control Protocol
· TCP wird von Anwendungen genutzt, die auf einen zuverlässigen Datentransport
angewiesen sind. Es wird sichergestellt, das die Daten vollständig und in richtiger
Reihenfolge übertragen werden. TCP ist demnach ein zuverlässiges,
verbindungsorientiertes Protokoll. Die Verbindungsorientiertheit bedeutet, dass der
Datenaustausch erst nach einem sogenannten ,,3-Wege-Handshake", also einer
aufgebauten Verbindung erfolgt.
Welche Form der Datenübertragung sollte nun für Streamingszenarien angewendet
werden?
Es gibt immer einen Balanceakt zwischen Schnelligkeit, Effizienz und Vollständigkeit
der zu übertragenden Daten.
Bei Streaming Anwendungen ist es entscheidend, dass die Daten mit hoher
Performance konstant übertragen werden. Eine Datensicherung, wie sie das TCP
Protokoll bietet, ist zwar nicht abträglich, kann aber nur zweitrangig sein. Wichtiger ist
die Eigenschaft von UDP, einen kontinuierlichen Datentransport zu gewährleisten. Beim
Abrufen eines Streams durch den Player wird erst ein interner Puffer gefüllt, bevor der
Datenstrom abgespielt wird. Dieser Puffer kann Leitungseinbrüche überbrücken, da der
Player dann die Daten aus dem gefüllten Puffer ausliest. Kommt es aber häufiger zu
Leitungseinbrüchen, ist eine konstante Wiedergabe nicht möglich. Das Transmission
Control Protocol verstärkt dies Ärgernis, indem es durch die Flusskontrolle
verlorengegangene Pakete erneut anfordert. Damit wird einer konstanten
Datenübertragung entgegengewirkt. Die Anforderung von audiovisuellen Daten,
konstant übertragen zu werden, wird auf inkonstanten Leitungen wie im Internet oft nur
ungenügend erfüllt.
16
15
vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S. 16-19, O'Reilly Verlag
16
vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.23, Addison-Wesley Verlag
24
Protokolle für Streaminganforderungen
Zusätzlich wird ein Datenpaket, das mit TCP transportiert wird, durch einen Header
repräsentiert, der mindestens 20 Oktetts lang ist. UDP gebraucht dieselben
Portnummern und Konventionen wie TCP, arbeitet aber in einem abgetrennten
Adressraum. So können TCP- und UDP-Verbindungen auf dem gleichen Port laufen.
UDP bietet zwar keine gesicherte Datenübertragung und keine Flusskontrolle, besticht
aber durch einen kleinen Paketkopf. Die Anwendung, die UDP zur Datenübertragung
benutzt, ist somit störungsunanfälliger gegen Leitungseinbrüche. Verlorengegangene
Datenpakete werden einfach ausgelassen und nicht durch eine Retransmission, wie bei
TCP, neu angefordert. Das User Datagram Protocol erfüllt damit eher als TCP die
Ansprüche einer Streaming Media Datenübertragung.
17
Es ist allerdings oftmals nötig auf TCP basierte Protokolle für die Datenübertragung
zurückzugreifen.
Für die Übertragung von Streaming Media Anwendungen sind spezielle Protokolle
entwickelt worden, die aus Mischformen von UDP und TCP bestehen. Im folgenden soll
ein kurzer Überblick gegeben werden, welche Art von Datentransfer bei Streaming-
szenarien angewendet werden kann:
Datentransfer Vorteil
Nachteil
UDP-Streaming
Enorm effizient und schnell,
keine Retransmission,
sowie kleine Header
Verlust von Datenpaketen
möglich, Kontrolle der
Datenpakete findet auf
höheren Ebenen statt, und
es kann somit zu einer
Netzwerküberflutung und
nachfolgendem Stau kom-
men
18
TCP-Streaming
Für den LAN Bereich oder
in zuverlässigen Netzen ein-
setzbar
Langsam, größere Header
als bei UDP, Akkumulation
der Störungen und dadurch
folgender Streamingabbruch
HTTP-Streaming
Keine zusätzlichen Port-
Freischaltungen nötig, da
HTTP den standardmäßig
freigelassenen Port 80
benutzt
Noch langsamer als TCP
und noch größere Header
Tabelle 2 - Arten von Datentransfer bei Streaminganwendungen
19
Bei den speziellen Streamingprotokollen wird versucht, die Vorteile von UDP und TCP
zu vereinen und effizient anzuwenden.
17
vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.22, Addison-Wesley Verlag
18
vgl. Technische Uni Ilmenau, Diplomarbeit : Webbasierte Datenübertragung
19
vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.80, Addison-Wesley Verlag
25
Protokolle für Streaminganforderungen
Das Realtime Streaming Protocol (RTSP) steuert den Datenstrom. Das RTSP ist
unter der Federführung von Real Networks und Netscape entstanden. Es dient der
effizienten Übertragung von Multimedia Streams über IP-Netzwerke. Datenquellen
können Live-Daten oder Aufzeichnungen sein. RTSP arbeitet mit Protokollen wie RTP
und HTTP zusammen. RSTP ist HTTP in Syntax und Operation sehr ähnlich.
20
Das Realtime Transport Protocol (RTP) sorgt für den Transport der Daten. Unter
Verwendung von Zwischenpuffern, Zeitstempeln und Folgenummern ermöglicht RTP
der empfangenden Station, fehlende, doppelte oder in falscher Reihenfolge empfange-
ne Pakete zu erkennen und den Empfangsstrom zu korrigieren. Durch RTP (RTCP)
kann die Synchronisation zwischen den Audio-, Video- und Dateninformationen herge-
stellt werden.
Das Resource Reservation Protocol (RSVP) reserviert die erforderlichen Netzwerk-
ressourcen für den Datenstrom. Gerade bei der Übertragung von Videoinformationen
haben schon geringe Paketverluste oder Schwankungen (Jitter) negative Auswirkungen
auf die Qualität. RSVP, das von der RSVP Working Group spezifiziert wurde, soll die-
ses Problem lösen. Es erlaubt dem Empfänger, Ressourcen für den Datenstrom zu re-
servieren. Diese Reservierung wird von Router zu Router bis zum Empfänger vorge-
nommen. Der einzige Nachteil des RSVP ist die zusätzliche CPU Belastung und eine
Hardwareabhängigkeit. Unterstützt auch nur ein Gerät auf dem Sendeweg RSVP nicht,
kommt keine Verbindung zustande.
21
Das Web Proxy Autodiscovery Protocol (WPAD) ist ein relativ neuer
Protokollvorschlag der Firmen Inktomi, Microsoft, Real Networks und Sun
Microsystems. Dieses soll automatisch Caching Proxies lokalisieren und damit einer
Konfiguration von Netzwerkanbietern oder Endanwendern vorbeugen.
22
Mit diesem Protokoll ergibt sich eine gute Überleitung zu dem nächsten Thema. Es soll
betrachtet werden, welche innovativen Netzwerkstrategien und Serverlösungen dem
Internet als schmalbandigem Netzwerk begegnen.
20
vgl. http://www.bachert.de
21
Technische Uni Ilmenau, Diplomarbeit : Webbasierte Datenübertragung
22
Wegner & Bachmeier, Streaming Media im Business Bereich S.82, Addison-Wesley Verlag
26
Protokolle für Streaminganforderungen
Zunächst soll aber die Abbildung 4 eine Übersicht zur Einordnung der Streaming-
protokolle in das ISO/OSI Modell geben und das Thema Protokollarchitekturen ab-
runden.
Abbildung 4 - Einordnung der Streamingprotokolle in das ISO/OSI Modell
27
4.4 INTELLIGENTE NETZ- UND SERVERSTRUKTUREN
Intelligente Netzwerkstrategien und darauf aufbauende Servertechnologien, stellen die
grundlegende Art der Informationsverbreitung dar. Es existieren Begriffe wie Unicast,
Multicast und Broadcast, zur Beschreibung der Funktionalität. Für diese wird auf Basis
von IP der Adressraum in verschiedene reservierte Bereiche aufgeteilt.
23
Im fortlaufenden Text sollen für die genannten Begriffe folgenden Definitionen gelten:
· Unicast
Der Begriff Unicast beschreibt eine Form der Datenübertragung, bei der ein Sender ei-
nen Datenstrom an einen Empfänger übergibt. Ein Unicast Paket ist an nur einen Host
adressiert. Es muss also beispielsweise für 1000 auf einen Datenstrom zugreifende
User, auch 1000 mal der gleiche Datenstrom gesendet werden.
24
· Multicast
Die Semantik von Multicast erfordert, dass ein Sender einen Datenstrom an eine Gruppe
von Empfängern sendet. Ein Multicast Paket ist also an eine Gruppe von Hosts adres-
siert.
25
Für Multicast Pakete ist der IP-Adressraum von 224.0.0.0 bis 239.255.255.255
reserviert. Eine einzige Adresse aus diesem Bereich wird Multicast-Gruppe genannt,
weil eine Gruppe von Hosts adressiert wird. Der große Vorteil dieser Technologie ist,
dass nicht 1000 einzelne Streams gesendet werden, sondern nur einer. Dieser wird
dann an sogenannten MRoutern ,,gesplittet". Da sich nur der Router, der einem oder
mehreren Clients am nächsten steht, wie ein Splitter verhält, wird bei dieser Art der Da-
tenübertragung die zur Verfügung stehende Bandbreite am sparsamsten ausgenutzt.
26
Durch eine jedem Paket zugeordnete TTL, wird die Lebensdauer der Pakete einge-
schränkt. Wenn der Begriff Multicast im Zusammenhang mit Datenübertragung fällt,
müssen auch noch Begriffe wie dense- und sparse mode, sowie shortest path und sha-
red tree genannt werden. Die Begriffe dense mode und sparse mode beschreiben die
Art der Initialphase beim Verbindungsaufbau, wogegen shortest path und shared tree
die Signalverteilung nach verschiedenen Prämissen handhaben.
27
· Broadcast
Der Broadcast Begriff hat einen historischen Ursprung. Ein Sender sendet an alle
Clients, die an das gleiche Netzwerk angeschlossen sind. Schon das Fernsehen oder
auch der Rundfunk sind in diesem Sinne Broadcaster. Ein Broadcast Paket ist, auf die
Netzwerktechnologie bezogen, an alle Hosts des gleichen Netzwerkes adressiert. Alle
Systeme eines Netzwerks werden über die Hostadresse (etwa 172.16.255.255) ange-
sprochen. Es handelt sich bei einem Broadcast Szenario nicht um einen bidirektionalen
Kommunikationsweg, sondern um einen unidirektionalen. Dadurch ist dieser Begriff in
dieser Arbeit auch dem Livestreaming zugeordnet. Während eines Livestreamings kön-
nen keine Steuerbefehle an den Datenstrom weitergereicht werden.
23
vgl. Elizabeth D.Zwicky, Simon Cooper & D.Brent Chapman, Einrichten von Internet Firewalls S.563,
O'Reilly Verlag
24
vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S. 31, O'Reilly Verlag
25
vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S. 32, O'Reilly Verlag
26
vgl. Wegner & Bachmeier, Streaming Media im Business Bereich S.94, Addison-Wesley Verlag
27
vgl. Wegner & Bachmeier, Streaming Media im Business Bereich S.95/96, Addison-Wesley Verlag
28
Intelligente Netz- und Serverstrukturen
Multicast
Unicast
MMS (Microsoft Media Server)
>--------------- Rollover --------------->
MMSU
MMST
HTTP
MSBD (Media
Streaming
Broadcast
Distribution)
Multicast
Streaming
UDP
(User Datagram
Protocol)
TCP (Transmission Control Protocol)
connectionless
Connection-oriented
IP Multicast
IP (Internet Protocol)
Abbildung 5 - Unicast, Multicast und Protokolle
Abbildung 5 zeigt die Einordnung der Streamingprotokolle in die mit ihnen benutzten
Technologien. Die effiziente Multicast Technologie hat allerdings noch den Nachteil,
dass jede am Multicasting Prozess beteiligte Komponente auch multicastfähig sein
muss. Dadurch werden mit Unicast andere ,,Hilfstechnologien" eingeführt. Zum einen
gibt es die serverseitige Möglichkeit des Load Balancing. Hier wird die lokale Verteilung
der Last auf mehreren Maschinen realisiert, in dem mit Hilfe eines Round Robin DNS
ein Name auf mehrere verschiedene IP-Adressen verteilt wird.
28
Zum anderen gibt es die Möglichkeit des Splittings. Die Idee des serverseitigen Split-
tings dient der weitflächigen Lastverteilung. Der Datenstrom eines Servers wird an wei-
tere sogenannte Splitting Server gereicht. Dadurch kann ein Client aus einem regional
weit vom Ausgangsserver entfernten Gebiet den Datenstrom durch einen in seiner Nä-
he stehenden Splittingserver bekommen.
Es sind auch noch weitere Szenarien möglich, die in den Servereigenschaften der vor-
gestellten Anwendungssysteme erläutert werden. Es wird in das Push-Splitting, welches
Real Networks benutzt und das Pull-Splitting, welches von Windows Media angewandt
wird, unterschieden. Die Splitting Technologie erfordert einen sehr hohen Programmie-
rungsaufwand. Es können auch Performanceverluste auftreten. Damit ist diese Lösung
nur eine Zwischenlösung auf dem Weg zu Multicast.
Andere Möglichkeiten kommen aus dem Bereich der Caching Technologie. Dateien
werden mit Hilfe eines transparenten Caching-Systems zwischengespeichert und
gesplittet. Diese Technologie ist für den Einsatz in großen Backbones sehr wichtig.
Für Rich Media Content Delivery hat sich die Kombination von Caching Appliances und
zentral vorgehaltenen Media Servern an POP's und Gateways bewährt. Das so
genannte ,,At the Edge Delivery".
29
28
Wegner & Bachmeier, Streaming Media im Business Bereich S.86-91, Addison-Wesley Verlag
29
Iwt Magazin Verlags GmbH, e.media 1-2001 S.71
29
Intelligente Netz- und Serverstrukturen
Abbildung 6 - Intellivision Data Center
30
Ausfallsicherheit und Skalierbarkeit besser umgesetzt werden können. Beim
Hochleistungsstreaming müssen sich die Lasten auf mehrere Caches verteilen lassen.
Für den Benutzer sind solche Szenarien nicht transparent. Die Caching Appliances
präsentiert sich ihm gegenüber wie ein normaler Media Server. Der einzige Unterschied
dürfte hier die URL sein, da die Anfrage über HTTP realisiert wird. Es gibt derzeit
verschiedene Anbieter auf dem Markt, die als Netzwerkbetreiber intelligente Lösungen
für eine optimale Datenverteilung anbieten. Tiscali, Akamai und Intellivision, die in
vielen Ländern der Welt verteilte Server und große zusammenhängende Netzwerke
betreiben, sind nur einige. Viele Streaming Media Datenströme sind von breitbandigen
Netzen abhängig. Die Datenverteilung ist das eigentliche Problem. Heute beschäftigen
sich selbst Softwarefirmen wie Real Networks mit Hardware-Lösungen. Seit der CEBIT
2001 hat Real Networks eine neue und weitgehend offene Server-Architektur, namens
RealSystemiQ im Programm. Hier werden mit Hilfe einer als Neuralcast bezeichneten
Technologie verschiedene Real Server vernetzt, um die Videoinhalte ,,näher" an den
Client zu bringen.
31
Die Abbildung 7 zeigt, dass im Unterschied zum ,,Edge Networking"
die Daten von mehreren miteinander kommunizierenden Servern gleichzeitig
eingespeist werden.
Abbildung 7- Neuralcast Funktionalität
30
http://www.intellivision.com
31
c't 10/2001 S.136
Die Datenverteilung zu den
Appliances erfolgt bei der ersten
Anfrage auf Basis von HTTP
(Pull-Prinzip). Requests werden
automatisch auf den nächst-
liegenden Cache geroutet und
direkt beantwortet. Dadurch
bleibt die Netzbelastung gering.
Die Kopplung an die POP's und
Gateways kann mit Hilfe von
Switching oder durch Router
erfolgen. Hersteller von Caches
empfehlen den Einsatz von
Switches, da hier die
30
5. ANWENDUNGSMODELLE DER STREAMING MEDIA TECHNOLOGIE
5.1 STREAMING MEDIA MARKT
Nach den Technologieausführungen zu Streaming Media soll die Marktsituation des
Streaming Geschäftes erläutert werden.
Der Run von Medienübertragungen auf das plattformunabhängige IP, sowie gute
Entwicklungsprognosen im Zuge der Internetentwicklung, die immer besser werdende
Kompressionstechnik und die Konvergenzvorhersagen im Endgerätesektor, lassen den
Streaming Media Markt als einen der spannendsten der nächsten Jahre erscheinen.
Allerdings sehe ich diesen Markt eher als wichtigen ,,Submarkt" der Konkurrenten, da
das große Geldverdienen zwar durch Platzkämpfe im Streamingsektor vorbereitet, aber
die Kasse auf anderen Märkten gemacht wird. So ist die Situation im Jahre 2001. Im
Zuge einer globalen Digitalisierung werden viele Dienste zusammenwachsen. Immer
mehr Fusionen machen die Runde und am Ende einer solchen Entwicklung bleiben nur
die Größten übrig. Im Streaming Markt sind diese durch Real Networks, Windows
Media (Microsoft) und Quicktime (Apple) repräsentiert und sollen auf den folgenden
Seiten vorgestellt sowie ihre Technik und Technologien analysiert werden.
31
5.2 REAL NETWORKS EINE ERFOLGSGESCHICHTE
33
Der Erfolg der Firma Real Networks ist sicherlich mit der charismatischen Person des
Rob Glaser verbunden, der 1989 als Projektmanager für Win Word und für das
Multimedia-PC-Projekt zur Integration von Multimediakomponenten wie CD-ROMs oder
fotorealistischen Grafiken bei Microsoft startete und schließlich zum Vizepräsidenten für
Multimedia und Verbraucherfragen emporstieg. In dieser Zeit diskutierte Glaser
strategische Fragen und berichtete direkt an Bill Gates. 1992 hatte Glaser in einem
Alter von 30 Jahren bereits das erreicht, wofür andere Jahrzehnte brauchen. Es folgte
das, was gemeinhin als ,,midlife crisis" bezeichnet wird.
Rob Glaser suchte nach neuen Inhalten, kündigte 1993 bei Microsoft und trat eine
Europareise an, um Abstand für neue Ideen zu gewinnen. Es hält sich jedoch das
Gerücht, dass Gates und Glaser uneins über die strategische Ausrichtung Microsofts
hinsichtlich der Entwicklung im Internet waren. Gates verfolgte die Strategie eines in
sich geschlossenen Microsoft Networks (MSN), während Glaser die Öffnung Microsofts
zum Internet hin vertrat die letzten Endes auch erfolgte. Der Erfolg der Webbrowser
Mosaic und Netscape, letzterer mit der radikal neuen Idee, Profi-Software weltweit zu
verschenken, um erst einmal eine nicht mehr wegzudenkende Marktdurchdringung zu
erreichen ließen Glaser spätestens 1994 seine Vision von Echtzeitmultimedia für das
Internet als realistische Idee erscheinen. Die Einschätzung, Informationen mit maximal
14,4 kbit/s Datengeschwindigkeit rund um die Welt zu verschicken, engte dabei die Art
der zu übertragenden Multimediadaten auf Audio ein. Glaser gründete zusammen mit
Marketing-, Kompressions- und Netzwerkspezialisten im Jahre 1994 seine eigene
Firma. Diese nannte sich Progressive Networks.
Gemäß dem Erfolgsbeispiel von Netscape erschien 1994 der erste Beta Release des
Real Audio Players 1.0 als freie Software. Als Business Modell sollte, ähnlich wie bei
Netscape, der Player frei bleiben, während der Server kostenpflichtig war. Bis Ende Juli
1995 waren bereits mehr als zweihunderttausend Decoder heruntergeladen. Eine Zahl,
die sich während der nächsten drei Monate sogar noch verdreifachte. Die Schwelle von
einer Million Player wurde dann Anfang des Jahres 1996 überschritten. Progressive
Networks verfeinerte parallel dazu das Real Audio System immer weiter. Ein erster Live
Encoder wurde erstmals im September 1995, anlässlich eines Baseballspiels zwischen
den Seattle Mariners gegen die New York Yankees in der ESPNET Sport Zone
präsentiert. Der amerikanische Sender ABC verwendete die gleiche Technologie, um
wenig später die ersten Nachrichten im Web auszustrahlen. Real Audio 2.0 wurde im
folgenden Monat veröffentlicht. Die verwendete Audiodatenrate von 18 kbit/s war nun
doppelt so groß wie die des Vorgängers. Diese Eigenschaft gab dem neuen Release
eine weit größere Klangtreue und lockte völlig neue Inhaltsanbieter in die Real Audio
Gemeinde. Sprachinhalte wie Talkshows waren in der ersten Version zwar
einigermaßen erträglich, aber nach längerer Zeit des Zuhörens kaum noch zumutbar.
Echos und verwaschene Töne waren nach einigen Minuten Spieldauer keine Seltenheit.
Real Audio 2.0 machte hingegen von seinem erweiterten Daten- und Klangraum
gebrauch und war mit UKW Qualität vergleichbar. Selbstverständlich waren 18 kbit/s
Signale jenseits der Reichweite von 14 kbit/s Modems, aber Real Audio zielte mit
seinem Produkt auf die immer größer werdende Fangemeinde von 28,8 kbit/s
Modembesitzern ab.
33
Wegner & Bachmeier, Streaming Media im Business Bereich S.44-49, Addison-Wesley Verlag
32
Real Networks Eine Erfolgsgeschichte
Die damalige Entscheidung von Progressive Networks stützte sich auf die neuesten
Statistiken über Internetanschlüsse im Privatbereich: Bis zum Frühling 1996 wurden
39 % der Internetanschlüsse mit 28,8 kbit/s Anschlüssen betrieben und nur noch
25,5 % benutzen eine Datenübertragungsrate von 14,4 kbit/s.
Der nächste Release Real Audio 3.0, der im Herbst 1996 erschien, arbeitete bereits mit
variablen Datenraten, wobei die meisten Verbindungen immer noch auf 20 kbit/s
basierten. Progressive Networks demonstrierte schon mit diesem Produkt, dass Signale
erzeugt und verarbeitet werden können, die mit ISDN-ähnlichen Bandbreiten
Tonqualitäten von absoluter Rundfunkqualität realisieren. Diese Qualität wurde von
Progressive Networks in Zusammenarbeit mit einer in Seattle ansässigen Musikstation
namens KING FM in einer Aufsehen erregenden Präsentation gezeigt. An einem
Nachmittag während seiner besten Sendezeit verschob KING FM tapfer seine
Rundfunksendequelle von seinen eigenen Studios auf einen Real Audio Strom, der
durch das Internet von der Unternehmenszentrale von Progressive Networks auf der
anderen Seite der Stadt angeliefert wurde. Anscheinend bemerkte keiner der vielen
Tausend Zuhörer die Änderung, da weder Beschwerdeanrufe noch Erkundigungen
eingingen. Seit dieser Zeit versahen viele Radiostationen, aber auch Printmedien und
Newcaster ihre Webseiten mit Real Audio Strömen. Mit dem Release 4.0 wurde 1997
der zunehmenden Internet-Bandbreite sowie den immer besser werdenden
Datenkompressoren Rechnung getragen und als Erweiterung auch der
Videodatenaustausch integriert. Zu dieser Zeit waren bereits auch einige andere
Internet Video Produkte, wie z.B. VDO-Live oder Streamworks, auf dem Markt
erhältlich. Um das Release 4.0 auf dem Markt durchzusetzen, startete PN einen harten
Verdrängungswettbewerb. Xing Streamworks als ernstzunehmender Techno-
logiekonkurrent wurde durch vergleichende Werbung attackiert. PN nannte sich
zusätzlich nach seinem viel bekannteren Produktnamen um und hieß von nun an Real
Networks.
Auch einen weiteren Vorteil von Xing, der Softwaredistribution über das Compuserve
Kundennetz, beantwortete Glaser mit einem strategischen Schulterschluss. Er besann
sich auf seine Beziehungen zu Microsoft und schmiedete eine Allianz, die bewirkte,
dass mit dem Microsoft Betriebssystem der Real Video Player 4.0 verteilt wurde. Diese
Allianz ergab einen ungewollten aber nicht dramatischen kuriosen Fakt, der Real
Networks Verkaufsstrategien etwas durcheinander brachte. Mit Microsofts eigenem
Netshow Server wurde auch der Real Server 4.0 Basic verteilt, der im Gegensatz zu
Real Networks bei Microsoft ohne Streambegrenzung verteilt wurde. Während Real
Networks für den Server also Geld nahm, gab es ihn bei Microsoft kostenlos. Dies sollte
jedoch die unaufhaltsame Verbreitung von Real Video nicht schmälern, wusste Glaser
doch, dass das Release 5.0 mit noch besseren Kompressoren bald marktreif war. Als
dieses dann 1998 auf dem Markt erschien, gestand sogar die Gartner Group ein, dass
mit dieser Videosoftware ernstzunehmende Multimediadienste im Internet generiert
werden können. Im Gegensatz zu dem Release 4.0 gab es bei 5.0 einen Audiocodec,
der bei einer Übertragungsrate von 5 kbit/s noch relativ saubere Werte zustande
brachte und die bis dahin geringst mögliche Grenze von 8 kbit/s (Nyquist Theorem)
unterschritt. Dies wurde durch die spezielle Anpassung der Kompression an spezifische
Klangspektren möglich. Auch bei einer Bitrate von 20 kbit/s gab es noch einmal eine
deutliche Qualitätsverbesserung im Audiobereich.
33
Real Networks Eine Erfolgsgeschichte
Der Real Video Encoder, der seit dem Release 4.0 bereits in seiner einfachsten Version
kostenlos verteilt wurde, sollte ähnlich wie schon der Player für eine Marktpenetrierung
des Real Formats sorgen. Durch den Einsatz des Real Encoders als Live Encoder mit
zusätzlicher Archivierungsfunktion durfte davon ausgegangen werden, dass bereits eine
beträchtliche Anzahl von Real Audio und Video Strömen vorlag. Der sich immer weiter
konsolidierende Echtzeitmarkt führte dazu, dass ehemalige Konkurrenten wegbrachen
oder aufgekauft wurden. Die Hauptkonkurrenten von heute sind die ehemaligen Partner
von gestern. Real Networks streitet mit Microsoft derzeit um die Marktführerschaft im
Streamingbereich. Dass hierbei selbst Monopole leicht und unerwartet wegbrechen
können, hat bereits der Einbruch von Netscape im Browsermarkt gezeigt. Mit einer
Anstrengung, die im Softwaregeschäft ihresgleichen sucht, hatte Microsoft mit seinem
Internet Explorer Monat für Monat die Marktanteile von Netscape erobert und hält heute
bereits die Marktführerschaft in diesem Segment. Insofern blickt Glaser nicht unbesorgt
in die Zukunft.
Dies erklärt auch den schnellen Releasewechsel von 5.0 auf die Version 6.0 oder auch
G2. Mit diesem Erscheinen im Jahr 1999 versucht Glaser seinen ehemaligen
Arbeitgeber technologisch so weit abzuhängen, dass sich die andeutende Vorsprung im
Streamingbereich bis ins Unendliche verlängert. Die technischen Neuerungen bei der
G2 Produktpalette waren enorm. Neben einem völligen Reengineering des gesamten
Client Server Systems auf objektorientierte Klassenbibliotheken wurde die
Vererbungstechnik genutzt, um das Streaming auch auf Texte, Bilder und
unterschiedlichste Formate wie MPEG1 auszudehnen. Zusätzlich wurde die XML
Variante SMIL präsentiert, die als Steuerskriptsprache zur Bündelung und Präsentation
unterschiedlicher Streaminginhalte fungieren sollte. Der Real Player G2 mauserte sich
vom einfachen Decoder zum SMIL Browser. Leider hatte die neue Technologie auch
ihren Preis. Die Serversoftware war mit heißer Nadel gestrickt und lief am Anfang sehr
labil. Erst mit der Version 7.0, die nichts anderes als Korrekturen der G2 enthielt, lief der
Serverdienst stabil. Die meisten Kinderkrankheiten waren geheilt.
Die nagelneue Release 8.0 sollte neue Dimensionen erreichen : VHS Bildqualität bei
einer Datenrate von 500 kbit/s und voller Auflösung. Der dabei eingesetzte neue Codec
wurde mit der Unterstützung von Intel entwickelt. Noch kann Microsoft Windows Media
Streaming System dem Real System nicht ganz das Wasser reichen. Aber Fakten wie
kostenlose Distribution und Untervertragnahme des MS Audio Codec von Real
Networks sprechen eine deutliche Sprache. Insgesamt zeigt die Entwicklung von
Glasers Firma und seiner Konkurrenz, dass die technische Entwicklung, die im Internet
schon mit einer Halbwertzeit von einem halben Jahr anvisiert wird, im Streamingbereich
noch schnelllebiger ist. Die Erweiterung des Real Players zum SMIL Browser zeigt
einen möglichen Vorstoß in den Browser Markt. So sind z.B. Informationsdienste,
Cross-Media, Direkt Marketing, Advertising oder Portale Marketingwerkzeuge, die allein
mit dem SMIL Browser auskommen würden. Die Zukunftsvision von Real Networks ist
aber sicherlich die absolute Marktführerschaft im Streamingbereich und damit
verbundenen Möglichkeiten und Erweiterungen, andere Medien integrieren zu können.
Ende der Leseprobe aus 158 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2001, Spezifische Anforderungen der Streamingtechnologie und Entwicklung einer mobilen Übertragungseinheit, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221049
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare