Spezifische Anforderungen der Streamingtechnologie und Entwicklung einer mobilen Übertragungseinheit

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

von Bastian Rutsch (Autor:in)

Informatik - Internet, neue Technologien

Zusammenfassung

Inhaltsangabe:Einleitung:
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.
Gang der Untersuchung:
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 […]

Leseprobe

Inhaltsverzeichnis

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

INHALT

Seite

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS 5

1. EINLEITUNG

1.1 Ziele der Diplomarbeit und Motivation

TECHNOLOGISCHE

BETRACHTUNGEN

2.1

Entwicklung

einer

Technologie 8

2.2 Zielstellungen von Streaming Media

2.3

Ein

Definitionsversuch

2.4

Als

alles

begann 11

STREAMINGTECHNOLOGIE

3.1 Grundlegende Funktionsweise eines Streamingszenarios

3.2 Audiovisuelle Grundlagen für die Erstellung von Streaming Content 15

3.3

Warum

Kompression

4. PROTOKOLLARCHITEKTUREN UND KOMMUNIKATIONSMODELLE 19

4.1

ISO/OSI

Referenzmodell

4.2

Protokollarchitektur

von

TCP/IP

4.3 Protokolle für Streaminganforderungen

4.4 Intelligente Netzstrukturen und Servermodelle

5. ANWENDUNGSMODELLE DER STREAMING MEDIA TECHNOLOGIE

5.1

Streaming

Markt 30

5.2 Real Networks Eine Erfolgsgeschichte

5.2.1 Grundlegende Komponenten und Funktionsphilosophie

5.2.2 Contentgenerierung - Real

Producer

5.2.3 Contentdistribution - Real Server

5.2.4

Contentdarstellung

Real

Player

5.2.5

Metasprache

SMIL

5.2.6

Schlussbemerkung

und

Ausblick

5.3 Windows Media Technologie Der große Verfolger Microsoft

5.3.1 Grundlegende Komponenten und Funktionsphilosophie

5.3.2 Contentgenerierung - Windows Media Encoder

5.3.3

Contentdistribution

- Windows Media Server

5.3.4

Contentdarstellung

Windows Media Player

5.3.5

Schlussbemerkung

und

Ausblick

5.4 Quicktime von Apple Der schlafende

Streamingriese

5.4.1 Grundlegende Komponenten und Funktionsphilosophie

5.4.2 Contentgenerierung - Sorenson

Broadcaster

5.4.3

Contentdistribution

Quicktime

Server

5.4.4

Contentdarstellung

Quicktime

Player

5.4.5

Schlussbemerkung

und

Ausblick

ENTWICKLUNG

DER

MSU

6.1 Motivation für die Entwicklung einer solchen Einheit

6.2 Anforderungen an eine mobile Übertragungseinheit

6.3 Definition einer Zielgruppe und von Einsatzgebieten

6.4

Finanzielle

Aspekte

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

108

6.6.5

Internes

Audiomodul

109

6.6.6

Internes

Audiomodul

111

6.6.7

Encoder

Netzwerkmodul

112

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

LITERATURVERZEICHNISS

136

GLOSSAR

139

ANHANG

145

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

TABELLENVERZEICHNIS

Tabelle 1:

Entwicklung der Streamingformate von Real Networks, Microsoft und Apple

Tabelle 2:

Arten von Datentransfer bei Streaminganwendungen

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.

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.

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.

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.

vgl. Internet Society, Die definitive Geschichte des Internets

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.

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.

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.

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.

vgl. http://www.tuwien.ac.at/histu/histu/www_history.html

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

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

vgl. Tobias Künkel, Streaming Media S.58-59 S.107, Addison-Wesley Verlag

vgl. http://mediasrv.cs.uni-dortmund.de/lehre/Dtvideo_SS2001/pdf/QTVideo_kap4.pdf

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.

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.

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:

· 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.

vgl.

Panasonic 1999, Das Videokompressionsbuch, Matsushita Electric Industrial Co., Ltd. Video Systems Division

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.

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.

vgl. Tobias Künkel, Streaming Media S.43-46, Addison-Wesley Verlag

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.

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.

Tobias Künkel, Streaming Media S.32, Addison-Wesley Verlag

vgl. Tobias Künkel, Streaming Media S.36, Addison-Wesley Verlag

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.

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

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

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.

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.

vgl. http://www.mti.uni-duisburg.de/arbeiten/lenord/internet/knetdump/node5.html

4.2 PROTOKOLLARCHITEKTUR VON TCP/IP

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

vgl. http://www.rvs.uni-bielefeld.de/~heiko/tcpip/kap_1_2.html

http://www.ruhr-uni-bochum.de/~rothamcw/Lokale.Netze/tcpip.html

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.

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.

Ü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.

vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.44-49, Addison-Wesley Verlag

vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S.11, O'Reilly Verlag

4.3 PROTOKOLLE FÜR STREAMINGANFORDERUNGEN

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.

vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S. 16-19, O'Reilly Verlag

vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.23, Addison-Wesley Verlag

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.

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

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

Bei den speziellen Streamingprotokollen wird versucht, die Vorteile von UDP und TCP

zu vereinen und effizient anzuwenden.

vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.22, Addison-Wesley Verlag

vgl. Technische Uni Ilmenau, Diplomarbeit : Webbasierte Datenübertragung

vgl. Wegner & Bachmeier, Streaming Media im Business-Bereich S.80, Addison-Wesley Verlag

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.

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.

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.

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.

vgl. http://www.bachert.de

Technische Uni Ilmenau, Diplomarbeit : Webbasierte Datenübertragung

Wegner & Bachmeier, Streaming Media im Business Bereich S.82, Addison-Wesley Verlag

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

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.

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.

· 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.

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.

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.

· 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.

vgl. Elizabeth D.Zwicky, Simon Cooper & D.Brent Chapman, Einrichten von Internet Firewalls S.563,

O'Reilly Verlag

vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S. 31, O'Reilly Verlag

vgl. Craig Hunt & Robert Bruce Thompson, TCP/IP S. 32, O'Reilly Verlag

vgl. Wegner & Bachmeier, Streaming Media im Business Bereich S.94, Addison-Wesley Verlag

vgl. Wegner & Bachmeier, Streaming Media im Business Bereich S.95/96, Addison-Wesley Verlag

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.

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".

Wegner & Bachmeier, Streaming Media im Business Bereich S.86-91, Addison-Wesley Verlag

Iwt Magazin Verlags GmbH, e.media 1-2001 S.71

Intelligente Netz- und Serverstrukturen

Abbildung 6 - Intellivision Data Center

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.

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

http://www.intellivision.com

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

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.

5.2 REAL NETWORKS EINE ERFOLGSGESCHICHTE

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.

Wegner & Bachmeier, Streaming Media im Business Bereich S.44-49, Addison-Wesley Verlag

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.

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.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2001
ISBN (eBook): 9783832455552
ISBN (Paperback): 9783838655550
DOI: 10.3239/9783832455552
Dateigröße: 5.1 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Brandenburg – unbekannt
Erscheinungsdatum: 2002 (Juni)
Note: 1,3
Schlagworte: digital kompression multimedia internet

Autor

Bastian Rutsch (Autor:in)