„Auswahl einer Software zur Übertragung von Audio- und Videodaten über das Intranet/Internet für die

(1)

Studienarbeit

„Auswahl einer Software zur Übertragung von Audio- und Videodaten über das Intranet/Internet für die

VOLKSWAGEN AG“

Bearbeitung: Markus Winter, Matr.-Nr.: XXX Firma: Volkswagen AG Wolfsburg

Abteilung: K-DOI 24 – Bürokommunikation Neue Medien

betreut von: ;;;

Herr Prof. Rolf Isernhagen

Zeitraum: März 2000 – Juni 2000 Fachhochschule Braunschweig/Wolfenbüttel Fachbereich Informatik

(2)

Erklärung

Hiermit erkläre ich an Eides statt, die vorliegende Studienarbeit nur mit den angegebenen Hilfsmitteln erstellt zu haben.

Wolfsburg, 30.06.2000

(3)

Inhalt

Inhaltsverzeichnis

1 Einleitung und Aufgabenbeschreibung ... 2

1.1 Aufbau der Studienarbeit ... 3

2 Grundanforderungen ... 4

2.1 Mögliche Einsatzgebiete ... 4

3 Technische Grundlagen ... 6

3.1 Transportmechanismen im Internet ... 6

3.1.1 Entstehungshintergrund der Internetprotokolle ... 6

3.1.2 Das ISO/OSI-Referenzmodell ... 7

3.1.3 Das Internetmodell ... 8

3.1.4 Protokolle im Hinblick auf Streaming ... 10

3.2 Grundlagen der Streaming-Technik ... 12

3.2.1 Kontinuierliche Datenübertragung ... 13

3.2.2 Verteilermechanismen ... 13

3.2.2.1 Unicast...14

3.2.2.2 Multicast...14

3.2.3 Datenkompression ... 15

4 Produktauswahl für die Volkswagen AG ... 16

4.1 Marktübersicht ... 16

4.2 Vorauswahl ... 17

4.3 Vergleich zwischen Real System G2 und Windows Media Technologies 4 ... 17

4.3.1 Benötigte Softwarekomponenten ... 17

4.3.2 Systemanforderungen ... 18

4.3.3 Funktionsübersicht ... 20

4.3.4 Fazit ... 21

5 Beschreibung der ausgewählten Software ... 23

5.1 Bestandteile der Microsoft Media Technologies 4 ... 23

5.1.1 Microsoft Media Services... 23

5.1.2 Microsoft Media Tools ... 23

5.1.3 Microsoft Media Player ... 24

5.2 Grundprinzip des Verbindungsaufbaus ... 25

5.3 Testbetrieb der Media Technologies 4 ... 26

6 Literatur und Quellen ... 28

(4)

1 Einleitung und Aufgabenbeschreibung

Bei der Volkswagen AG ist das firmeninterne Intranet zu einer der wichtigsten Kommunikationsgrundlagen im Unternehmen geworden. Die dort eingesetzten Techniken und Verfahren basieren auf den Kommunikationsverfahren und Übertragungsprotokollen, die auch im Internet verwendet werden. Wie bei der Benutzung des Internet bilden auch im Volkswagen-Intranet herkömmliche Webbrowser (Netscape Navigator und Microsoft Internet Explorer) und ein gebräuchlicher E-Mail-Client (Microsoft Outlook) die Basis, um Informationen abzurufen. Technische Neuerungen, die sich im Internet durchsetzen und als nützliche Erweiterung der bisher eingesetzten Techniken erscheinen, können also grundsätzlich auch im Intranet eingesetzt werden.

In den letzten Jahren konnte man im Internet eine verstärkte Verbreitung von multimedialen Inhalten, wie Bilder, Tondokumente und Videodateien beobachten. Die Abkehr von ausschließlich textbasierten Informationen hat neben dem gesteigerten Unterhaltungswert auch durchaus nützliche und sinnvolle Aspekte. So kann beispielsweise ein Lehrvideo, in dem bestimmte technische Arbeitsschritte gezeigt werden, zeiteffizienter und verständlicher sein, als eine schriftliche Anleitung, die in den meisten Fällen einen Interpretationsspielraum läßt.

Auch verschiedene Abteilungen der Volkswagen AG signalisieren in zunehmenden Maße Bedarf an der Bereitstellung von Video- und Audiodokumenten im Intranet. Diese Studienarbeit beschäftigt sich daher mit den technischen Grundlagen von Audio-/Videoübertragung und der Auswahl einer für die Volkswagen AG geeigneten Softwarelösung.

(5)

Einleitung

1.1 Aufbau der Studienarbeit

Im Folgenden Abschnitt werden die wesentlichen Anforderungen und die möglichen Einsatzgebiete einer Software zur Übertragung von Audio- und Videodaten beschrieben.

Weil eine solche Software besondere Ansprüche an die Verbindungsqualität stellt, sie sich aber mit den vorhandenen Netzwerktechnologien arrangieren muss, werden in Kapitel 3 die technischen Grundlagen etwas näher betrachtet.

Danach folgt ein Überblick über die am Markt verfügbaren Produkte. Die Produkte werden auf ihre Eignung für die Volkswagen AG überprüft und miteinander verglichen, so dass schließlich ein Produkt ausgewählt werden kann.

Abschließend geht Kapitel 5 auf die ausgewählte Software ein. Es werden die wichtigsten Bestandteile und Merkmale erläutert, und es wird eine kurze Darstellung eines ersten Funktionstests gegeben.

(6)

2 Grundanforderungen

Ein wichtiges Kriterium in einem Netzwerk ist die sinnvolle Aufteilung der zur Verfügung stehenden Bandbreiten. Man muss insbesondere bei Videodateien, die in der Regel ein relativ großes Datenvolumen erfordern, die Möglichkeit haben, steuernd in die Bandbreitenverteilung einzugreifen.

Weiterhin sollte die Software in der Lage sein, analoge Videosignale (z.B.

von einer Kamera oder einem Videorecorder) direkt in das verwendete Medienformat zu konvertieren. Dabei ist auch die Fähigkeit gewünscht, Inhalte live zu versenden, d.h. bereits während die Inhalte von der Software kodiert werden, sollen die Daten über das Netzwerk gesendet und von den Clientrechnern dargestellt werden.

Dies ist mit den Techniken des herkömmlichen Dateidownloads von Mediendateien, z.B. im AVI- oder MPEG2-Format nicht möglich. Es muß ein Softwarepaket zum Einsatz kommen, welches das sogenannte 'Streamen' von Informationen unterstützt.

2.1 Mögliche Einsatzgebiete

Die Möglichkeit, Videos über das Intranet zu übertragen, bietet vielfältige neue Anwendungsbereiche. Es gibt beispielsweise einige Berufsgruppen, die aufgrund von Überwachungs- oder Bereitschaftstätigkeiten (Werksfeuerwehr, Krankenstation etc.) nicht an Informationsveranstaltungen und Betriebsversammlungen teilnehmen können. Diesen Mitarbeitern könnte man durch eine Live-Sendung über das Intranet zumindest die indirekte Teilnahme an solchen Veranstaltungen ermöglichen. In diesem Zusammenhang könnten diese Videodateien auch zur Archivierung und Protokollierung von geeigneten Veranstaltungen dienen.

(7)

Grundanforderungen

Weiterhin können Videos bei Schulungen und Weiterbildungen über das Intranet eine sinnvolle Ergänzung zur konventionellen Wissensvermittlung bieten.

Auch für die Präsentation von Produkten und Dienstleistungen im Intranet/Internet bieten Videos interessante Möglichkeiten.

(8)

3 Technische Grundlagen

3.1 Transportmechanismen im Internet

3.1.1 Entstehungshintergrund der Internetprotokolle

Ende der sechziger Jahre wurde vom amerikanischen Verteidigungsministerium die Entwicklung eines zunächst kleinen Computernetzwerkes vorangetrieben. Ziel dabei war einerseits das Teilen von Computerresourcen und andererseits die Kommunikation zwischen den Einzelrechnern. Ein wichtiger Aspekt bei diesem Netzwerk war die Vorgabe, dass die Kommunikationswege zwischen den Rechnern nicht statisch vorgegeben wurden. Es sollte auch bei einem Defekt oder bei der Zerstörung eines großen Teils der Netzinfrastruktur noch möglich sein, mit den verbleibenden Netzwerkbestandteilen zu arbeiten. Es musste also eine Netzwerktechnologie entwickelt werden, die nicht von einer zentralen Steuereinheit abhängig war. Das Grundprinzip bestand in der Versendung von kleinen Datenpaketen, die jeweils mit einer Zieladresse versehen waren.

So konnte jeder Netzrechner individuell entscheiden, ob das empfangene Datenpaket für ihn bestimmt war, oder ob es weitergeleitet werden muss.

Aus dieser Forschung ging 1971 das sogenannte ARPANET (benannt nach einer Abteilung des US-Verteidigungsministeriums) hervor, welches als Ursprung des Internets gilt und in dem zunächst etwa 30 Universitäten miteinander kommunizieren konnten¹. Aus verschiedenen Verbindungsvarianten setzte sich eine informelle Sammlung von Protokollen durch, die heute unter dem Sammelbegriff TCP/IP-Protokolle bekannt sind².

1 Vgl. http://www.service24.de/pe/ink.htm

2 Vgl. Saaro: Internet, S.62

(9)

Technische Grundlagen

3.1.2 Das ISO/OSI-Referenzmodell

Das Open-System-Interconection-Referenzmodell beruht auf einem Vorschlag der International Standards Organisation. Es dient derzeit als allgemeines Modell zur Beschreibung von Protokollcharakteristika und Protokollfunktionen³. Das Modell teilt das Feld der Netzwerkkommunikation in sieben Schichten (auch Layer genannt). Es beschreibt dazu, welche Aufgaben von welcher Schicht übernommen werden soll. In der folgenden Tabelle werden diese 7 Schichten dargestellt und kurz erläutert⁴:

Application Layer

Diese Schicht enthält Protokolle, die die Anwendungen zur Erbringung ihrer Dienste benötigen. Die Anwendung könnte beispielsweise ein E-Mail-Server sein.

Presentation Layer

Die Darstellungsschicht regelt die Darstellung der

Übertragungsdaten. Z.B. werden verschiedene Kodierungen von Zeichenketten bei verschiedenen Computersystemen (z.B. ASCII und Unicode) in einer standardisierten Form kodiert.

Session Layer

Hier wird der Verbindungsauf- und abbau geregelt. Außerdem wird festgelegt, ob der Datenaustausch bi- oder unidirektional verläuft.

Transport Layer

Die Transportschicht hat die Aufgabe den Datenfluss zu steuern und die Korrektheit der übertragenen Daten sicherzustellen.

Network Layer

Diese Schicht steuert den Datentransport über die verschiedenen Knoten eines Netzwerkes (z.B. Paketrouting)

Data Link Layer

Die Aufgabe ist die gesicherte Übertragung von Daten. Die Daten werden dazu in Frames aufgeteilt und sequentiell gesendet. Der Empfänger quittiert den Empfang durch Bestätigungsframes.

Physical Layer

Hier werden die physikalischen Eigenschaften der

Datenübertragung geregelt (z.B. Spannungswerte, Bit-Kodierungen, Übertragungsgeschwindigkeit etc.)

Tab. 3.1

3 Vgl. http://www.rvs.uni-bielefeld.de/~heiko/tcpip/kap_1_3.html

4 Vgl. http://www.rvs.uni-bielefeld.de/~heiko/tcpip/kap_1_3.html und Naik: Internet Standards and Protocols, S.3ff

(10)

3.1.3 Das Internetmodell

Das Prinzip der Schichtenarchitektur des unter 3.1.2 dargestellten OSI- Referenzmodells bildet die Grundlage für das Internetmodell. Jede Schicht benutzt dabei die Dienste der darunterliegenden und stellt gleichzeitig Dienste an die darüberliegende Schicht zur Verfügung⁵. Das Internetmodell wird jedoch im allgemeinen als vierschichtiges Modell dargestellt, es werden dabei einige Schichten aus dem OSI-Referenzmodell zusammengefasst.

Die folgende Tabelle zeigt die Abbildung des Internetmodells auf das OSI- Referenzmodell und nennt einige der gebräuchlichsten Protokolle für die jeweilige Schicht⁶:

OSI-Modell Internetmodell gebräuchliche Protokolle Application

Layer

Application Layer

Simple Mail Transfer Protocol (SMPT) File Transfer Protocol (FTP)

Hypertext Transfer Protocol (HTTP) Presentation

Layer Session Layer Transport Layer

Transport Layer

Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Network

Layer

Internet

Layer Internet Protocol (IP) Data Link

Layer Network

Layer

IEEE 802-3 Ethernet Physical

Layer

Tab. 3.2

5 Vgl. Stainov: IPnG - Das Internetprotokoll der nächsten Generation, S.12

6 Vgl. Naik: Internet Standards and Protocols, S.6

(11)

Bei der Übertragung eines Internetpaketes werden die Schichten (je nachdem, ob ein Paket gesendet oder empfangen werden soll) von der Applikationsschicht zur Netzwerkschicht oder umgekehrt durchlaufen.

Wird beispielsweise in einem Webbrowser eine bestimmte URL angefordert, so wird die URL zunächst von der Applikationschicht mit einem Header versehen, welcher der Verständigung von HTTP-Client und HTTP-Server dient. Auch die darunterliegenden Schichten addieren jeweils einen eigenen Header und kapseln die Nutzdaten immer mehr ein (encapsulation)⁷. Die nachfolgende Abbildung soll diesen Ablauf veranschaulichen:

Abb. 3.1

Sind die Daten beim Empfänger angekommen, so verwerten die jeweiligen Protokollschichten die Headerinformationen, entfernen den jeweiligen Header (und Trailer bei Ethernent) und reichen das Datenpaket an die nächsthöhere Schicht weiter. Auf diese Weise werden schließlich die Nutzdaten (in diesem Beispiel die angeforderte URL) zurückgewonnen.

7 Vgl. Stainov: IPnG - Das Internetprotokoll der nächsten Generation, S.15f Application

(HTTP)

Transport (TCP )

Internet (IP)

Network

(Ethernet) _Eth-

Header IP- Header

TCP- Header

HTTP-

Header URL Trailer ^Eth- IP-

Header

TCP- Header

HTTP-

Header URL

TCP- Header

HTTP-

Header URL

HTTP-

Header URL URL

Senden Empfangen

(12)

3.1.4 Protokolle im Hinblick auf Streaming

Das Internetmodell lässt auf der Transportschicht nur TCP und UDP zu⁸. Alle höher angesiedelten Protokolle basieren auf diesen beiden Protokollen. Im Folgenden sollen daher die wesentlichen Merkmale von TCP und UDP erläutert werden, sowie die wichtigsten darauf aufbauenden Protokolle für Echtzeitanwendungen angesprochen werden.

 TCP:

Das Transmission Control Protocol ist ein sicheres, verbindungsorientiertes Protokoll. Es stellt sicher, dass die Datenpakete beim Empfänger ankommen.

Der Empfänger quittiert zu diesem Zweck jedes erhaltene Datenpaket. Bleibt die Quittierung beim Sender aus, so wird das Datenpaket nach einer gewissen Zeit erneut übertragen. TCP stellt nicht nur sicher, dass die Daten ankommen, sondern enthält auch einen Mechanismus um zu gewährleisten, dass die Datenpakete beim Empfänger wieder in die richtige Reihenfolge gebracht werden können⁹.

Diese Sicherheit ist natürlich auch mit einigen Nachteilen verbunden. Zum einen ist der TCP-Header relativ groß und erzeugt somit einen nicht unerheblichen Overhead (Nutzdaten im Verhältnis zu Kontrolldaten), zum anderen vergeht gerade im Hinblick auf Echtzeitanwendungen kostbare Zeit, bis der Verlust eines Datenpaketes festgestellt, und es erneut gesendet wird.

 UDP:

Das User Datagram Protocol ist ein unsicheres, verbindungloses Protokoll.

Es bildet nur eine dünne Hülle um das darunterliegende IP¹⁰. Datenpakete werden bei UDP nicht durch den Empfänger quittiert. Die Verbindung ist also einseitig und unsicher, weil der Sender nicht davon in Kenntnis gesetzt wird, ob die Daten den Empfänger erreicht haben. Unsicher bedeutet jedoch nicht,

8 Vgl. Stainov: IPnG - Das Internetprotokoll der nächsten Generation, S.13

(13)

dass die Daten verfälscht sein könnten, es bedeutet nur, dass sie ggf. nicht ankommen.

Bei UDP wird jedes Datenpaket unabhängig von den anderen zugestellt, d.h.

ohne die Reihenfolge beim Senden zu beachten. Sie kommen also nicht zwingend in der richtige Reihenfolge beim Empfänger an.

Die Vorteile von UDP liegen in dem geringeren Protokolloverhead und im Wegfall einer Übertragungsverzögerungen durch eine Flusskontrolle.

Für Videoübertragungen kann man feststellen, dass UDP die geeignete Grundlage für den Transport von Daten bietet, während TCP für die Über- mittlung von Kontrollnachrichten zwischen Client und Server geeignet ist. Bei Multimedia-Anwendungen ist es in der Regel besser, verlorengegangene Datenpakete durch eine Fehlerkorrektur in der Wiedergabesoftware zu kompensieren, als die Verzögerungen einer Flusskontrolle in Kauf zu nehmen¹¹.

 RTP

Das Real Time Protocol basiert auf dem unsicheren UDP. Es kann ebenso wie UDP keine Garantie für die Ankunft oder die Reihenfolge der Daten übernehmen, aber es ergänzt die Daten mit einer Sequenznummer, welches den Multimedia-Anwendungen ermöglicht, die Daten zu sortieren und fehlende Pakete zu erkennen. RTP ist für 1 zu 1 und für 1 zu n Über- tragungen definiert¹².

 RTCP

Das Real Time Control Protocol arbeitet mit RTP zusammen. Teilnehmer einer RTP-Verbingung senden von Zeit zu Zeit RTCP-Pakete, welche unter anderem statistische Angaben über fehlende und empfangene Datenpakete

11 Vgl. Sitaram, Dan: Multimedia Servers, S.38

(14)

enthalten. Der Sender kann diese Informationen nutzen, um dynamisch auf Veränderungen in der Verbindungsqualität zu reagieren¹³.

Beispielsweise kann bei einer Videoübertragung mit nachlassender Verbindungsqualität die Bandbreite der Übertragung verringert werden. Oder es werden ggf. nur noch die Audiodaten gesendet und auf die Videosignale wird verzichtet.

 RTSP

Im Internetmodell ist das Real Time Streaming Protocol etwa auf der Ebene von HTTP angesiedelt. RTSP ist im gegensatz zu HTTP bidirektional, d.h.

der Server und der Client können Anfragen an den anderen ausgeben¹⁴, so entsteht eine Interaktion zwischen den Verbindungspartnern.

Bei einer Videoübertragung können so beispielsweise Kommandos wie Vor- und Zurückspulen oder das gezielte Anfordern einer bestimmten Sequenz realisiert werden.

3.2 Grundlagen der Streaming-Technik

Das Prinzip der Streaming-Technik beruht im wesentlichen auf drei Schritten.

Zunächst wird ein multimedialer Inhalt mit Audio- und Videokompressoren auf eine möglichst geringe Datenmenge reduziert und in ein Streaming- Format konvertiert.

Danach wird die Datei auf einem Server abgelegt (bei sogenannten Live- Broadcasts geschieht das Kodieren der Daten und das Bereitstellen auf dem Server zur gleichen Zeit).

Als letztes muss ein Client die Daten vom Server abrufen.

(15)

3.2.1 Kontinuierliche Datenübertragung

Beim Streamen von Video- und Audiosequenzen werden die Inhalte bereits während der Übertragung der Daten wiedergegeben. Es muss also nicht wie beim sonst üblichen Store-and-forward-Prinzip erst abgewartet werden, bis eine Mediendatei komplett übertragen wurde, bevor die Datei wiedergegeben werden kann. Man spricht daher auch von Echtzeitübertragungen, da Daten ohne größere Zeitverschiebung vom Client wiedergegeben werden¹⁵.

Eines der größten Probleme dabei ist die Aufrechterhaltung eines kontinuierlichen Datenstromes. Dies ist notwendig, damit bei der Wiedergabe keine Lücken oder Aussetzer entstehen.

Um die Kontinuität des Datenstromes zu gewährleisten gibt es im wesentlichen zwei Lösungsansätze. Zum einen wird auf der Clientseite vor Beginn der Wiedergabe ein Teil der Daten zwischengespeichert (Cachen), um kurzzeitige Übertragungsschwankungen zu kompensieren. Bei dauerhafter Verschlechterung der Verbindung ist andererseits der Server in der Lage, auf eine Übertragung mit geringerer Bandbreite umzuschalten.

3.2.2 Verteilermechanismen

Im Folgenden soll ein kurzer Blick auf die zwei grundsätzlichen Verfahren zur Verbreitung von Media-Streams geworfen werden. Die Verfahren heißen Unicast und Multicast.

15 Vgl. Reibold: Streaming Video, PC Professionell, Ausgabe 8/2000

(16)

3.2.2.1 Unicast

Bei einer Unicast-Verbindung handelt es sich um eine traditionelle Punkt-zu- Punkt-Kommunikation. Es existiert genau ein Sender und ein Empfänger.

Der Austauscht von Nutzdaten ist dabei unidirektional, Kontrolldaten können aber auch in umgekehrter Richtung fließen¹⁶. Punkt-zu-Punkt bedeutet, dass jeder Client einen eigenen Datenstrom vom Server empfängt.

Unicastdatenströme werden nur an den Client gesendet, der sie angefordert hat.

3.2.2.2 Multicast

Bei einer Multicast-Verbindung sendet die Datenquelle Nutzdaten an mehrere Empfänger. Die Verbindung ist grundsätzlich unidirektional, jedoch können wie bei Unicast Kontrolldaten entgegengesetzt übermittelt werden¹⁷. Das Multicast-Verfahren ermöglicht, dass Datenpakete, die von mehreren Clients empfangen werden sollen, nur einmal in das Datennetz eingespeist werden müssen. Die Netzwerkrouter übernehmen dann die notwendige Duplizierung der Datenpakete.

Dieses Verfahren stellt jedoch spezielle Anforderungen an die Netzwerkhardware. Für IP-Multicast wird ein besonderer Bereich von IP- Nummern, sogenannte Class-D Adressen, benutzt. Die Router müssen für die Benutzung von IP-Adressen der Klasse D geeignet und konfiguriert sein¹⁸.

Viele Anwendungen, die Multicast unterstützen, setzen in der Transportschicht auf UDP auf.

16 Vgl. Wittmann, Zitterbart: Multicast, S.8

17 Vgl. Wittmann, Zitterbart: Multicast, S.9

18 Vgl. Froitzheim: Multimedia Kommunikation, S.193f

(17)

3.2.3 Datenkompression

Ein einzelnes unkomprimiertes Bild in True-Color-Qualität (24 Bit Farbtiefe) und PAL-Fernsehauflösung (720*576 Pixel) verbraucht etwa 1,2 MByte Speicher. Bei 25 Bildern pro Sekunde würde ein entsprechender Videodatenstrom auf eine Bandbreitenanforderung von 30 MB/s kommen.

Dies ist für heutige Intranet-/Internetanwendungen deutlich zu viel. Bei einem Herabsetzen der Auflösung auf übliche 320*240 Pixel und einer Reduktion der Framerate auf 10 bis 15 Bilder pro Sekunde blieben immer noch 2 bis 3 MB/s Datenstromanforderung allein für die Bildinhalte.

Dies ist für praktikable Lösungen im Internet-/Intranetbereich noch etwa um den Faktor 300 zu hoch. Um diesem Problem zu begegnen werden die Audio- und Videodaten vor dem Streamen komprimiert und vor der Wiedergabe am Clientrechner dekomprimiert.

Dazu wurden verschiedene Codecs (von Compression/Decompression) entwickelt, die vor allem die im allgemeinen recht hohe Redundanz bei Videobildern ausnutzen¹⁹. Weil aufeinanderfolgende Bilder eines Videos oft große Ähnlichkeiten aufweisen, ist es günstiger nur die Unterschiede zwischen den Bildern zu speichern und nur noch etwa jede Sekunde ein unabhängiges Bild (Keyframe) mit aufzunehmen.

Auch das Weglassen von feinen Details und die Abstufung von Farbverläufen sind Mittel, um die Datenmenge weiter zu reduzieren.

Bei der Kompression der Audiodaten wird vor allem versucht, die vom menschlichen Ohr nicht wahrnehmbaren Teile aus dem Datenstrom zu entfernen.

19 Vgl. Sitaram, Dan: Multimedia Servers, S.13f

(18)

4 Produktauswahl für die Volkswagen AG 4.1 Marktübersicht

Im Jahre 1995 hat RealNetworks den ersten RealPlayer vorgestellt. Seitdem haben sie sich zum führenden Anbieter von Streaming-Software entwickelt.

Seit etwa 1998 konnte jedoch die Firma Microsoft mit dem Net-Show-Player und später mit dem Windows-Media-Player und den dazugehörigen Produkten stetig an Verbreitung zunehmen.

Weiterhin ist das von Apple vertriebene QuicktTime zu nennen. Dieses Format ist seit der Version 4.0 ebenfalls streaming-fähig.

Vor einiger Zeit versuchten noch die Firmen Vivo-Software, XingTechnologies und VDOnet in diesem Anwendungsbereich eigene Lösungen anzubieten. Vivo-Software gehört jedoch inzwischen zu RealNetworks und XingTechnologies scheinen ihr ‚Stream-Works‘ genanntes Projekt aufgegeben zu haben.

Die Firma VDOnet hat ebenfalls im Mai 2000 den Verkauf ihrer Produkte eingestellt.

Als ernstzunehmende Wettbewerber in dem Segment der Streaming- Software erscheinen also folglich nur dir Firmen RealNetworks, Microsoft und Apple.

Das Marktforschungsinstitut Dataquest stellt in diesem Zusammenhang für Oktober 1999 fest, dass der Real Player mit 70 Millionen Downloads vor dem Microsoft Media Player mit 40 Millionen Benutzern den weitesten Verbreitungsgrad besitzt. Quicktime von Apple wird laut Dataquest von 15 Millionen Menschen benutzt²⁰.

20 Vgl. http://www.computerwoche.de/, Artikel vom 22.10.1999

(19)

Produktauswahl

4.2 Vorauswahl

Aufgrund der oben geschilderten Marktsituation kommen für die weitere Betrachtung lediglich die Produkte von Apple, RealNetworks und Microsoft in Frage.

Das Softwarepaket von Apple hat jedoch einen entscheidenden Nachteil: Die Server-Software von Apple läuft ausschließlich auf einem PowerMac G3/G4 mit MacOS X Server. Andere Plattformen werden von Apple nur für die Player-Software unterstützt.

Bei der Volkswagen AG werden jedoch keine Server mit Macintosh Betriebssystem eingesetzt, deshalb fällt auch das Produkt von Apple aus der Wahl heraus.

Der nachfolgende Vergleich beschränkt sich daher auf das Real System G2 von RealNetworks und die Windows Media Technologies 4 von Microsoft.

4.3 Vergleich zwischen Real System G2 und Windows Media Technologies 4

4.3.1 Benötigte Softwarekomponenten

Zu den wesentlichen Bestandteile einer Streaming-Software gehört als erste ein Content Creation Tool, also ein Encoder, der das benötigte Datenformat aus anderen Dateien konvertieren, oder es direkt aus Livequellen erstellen kann. RealNetworks hat zu diesem Zweck den RealProducer, welcher sowohl zum Konvertieren von Dateien, als auch als Live-Encoder dient.

Bei Microsoft übernimmt diese Aufgabe der Media Encoder. Darüber hinaus gibt es noch den On-Demand-Producer, welcher speziell zum Konvertieren von Dateien geeignet ist.

(20)

Weiterhin wird eine Serversoftware benötigt, um die Inhalte bereitzustellen.

Dies erledigen die Microsoft Media Services und der RealServer.

Auf der Clientseite wird eine Abspielsoftware zur Wiedergabe der Media- Dateien benötigt. Dort kommen entweder der Microsoft Media Player oder der RealPlayer zum Einsatz.

Dies sind die mindestens erforderlichen Komponenten. Darüber hinaus bieten beide Firmen einige Authoring Tools zur weiteren Bearbeitung der Media-Dateien an. Damit ist es z.B. möglich, bestimmte Dateipositionen mit Indices zu versehen, Untertitel einzublenden oder PowerPoint- Präsentationen in das jeweilige Streamingformat zu konvertieren.

4.3.2 Systemanforderungen

Systemanforderungen für die Erstellung von Streaming-Files:

RealSystem Microsoft Media

Tool RealProducer 7.0 Media Tools

Mögliche Plattformen

Windows 95/98 Windows NT/2000 Linux

Unix MacOS 8.5

Windows 95/98 Windows NT/2000

CPU Pentium 400 Pentium II 266

RAM 48 MB 64 MB

Sound-Karte Soundblaster 16 kompatible Soundblaster 16 kompatible Video-Capture-

Karte

VideoForWindows kompatible Karte

Tab. 4.1

(21)

Produktauswahl

Systemanforderungen für die Serversoftware:

RealSystem Microsoft Media

Server RealServer 7.0 Media Services

Mögliche Plattformen

Windows 95/98 Windows NT/2000 Linux

Solaris

Windows 95/98 Windows NT/2000

CPU Pentium Pentium II 266

RAM 64 MB +(12kB pro 1kbps) z.B. 1000 Streams mit 50 kbps

 600MB + 64MB

Mind. 128 MB

Bandbreiten- Anforderungen

Streamrate * Anzahl Streams z.B. 1000 Streams mit 50kbps

 5Mbps

k.A.

Tab. 4.2

Die Daten in den Tabellen 4.1 und 4.2 beruhen auf den Herstellerangaben für eine empfohlene Systemkonfiguration.

(22)

4.3.3 Funktionsübersicht

Die folgende Tabelle gibt einen vergleichenden Überblick über die wichtigsten Eigenschaften und Funktionen der Produkte.

RealSystem G2 Windows Media Technologies 4.0

Hersteller RealNetworks Microsoft

Audio Codec RealAudio Windows Media Audio

Video Codec RealVideo G2 MPEG-4

Fenstergröße 3 feste Größen Stufenlos

HTTP only Ja Ja

Ausgabeformat RealMedia (.rm) Advanced Streaming Format (.asf)

Max. Encoding bit rate 1 Mbps 5 Mbps Prioritätsvergabe für

Streams möglich

Ja Ja

Encoding für mehrere Bit-Raten in einem File

Ja Ja

Auto-Shifting Ja Ja

Multicasting Ja Ja

Splitting Ja (benötigt Zusatztool) Ja (enthalten) Benötigt einen

Streaming-Server

Ja

RealServer

Ja

Windows Media Services Server Plattformen WindowsNT4.0

WindowsNT4.2 Unix

WindowsNT Windows2000

Fernverwaltung Ja Ja

Parallele Streams 60 (Bei Plus Version) 2000

Übertragungsprotokolle UDP, TCP, HTTP, RTSP UDP, TCP, HTTP Kosten des Streaming-

Servers

1.995 $ (Plus-Version) Kostenlos

In Windows2000 enthalten Tab. 4.3

(23)

Produktauswahl

4.3.4 Fazit

Betrachtet man die obenstehenden Vergleichstabellen zwischen den Softwarelösungen von Microsoft und RealNetworks, so gleichen sich die Produkte in Bezug auf Hardwareanforderungen und integrierten Features sehr stark. Beide Systeme bieten die wichtige Unterstützung von Multicast, um die Belastung in einem geeigneten Netzwerk möglichst gering zu halten (vgl. 3.2.2.2 auf Seite 14). Auch die variable Anpassung der Bitrate an veränderliche Verbindungsqualitäten (Auto-Shifting) wird beiderseits geboten. Eine weitere wichtige Eigenschaft, die beide bereitstellen, ist die Fähigkeit, die Streamingdaten in HTTP-Pakete einzukapseln. Dies bietet eine Möglichkeit, Daten über Firewallgrenzen zu vermitteln, die oftmals keine anderen Protokolle zulassen.

Für das Verteilen von Inhalten auf mehrere Server (Splitting) wird von RealNetworks allerdings ein separates Zusatztool benötigt. Auch bei den maximal abgehenden Streams von einem Server und bei der Live-Encoding- Bit-Rate hat Microsoft die besseren Werte.

Der wesentliche Vorteil des RealSystems G2 liegt in der vielfältigeren Plattformunterstüzung. Dieses ist jedoch für die Volkswagen AG kein wesentliches Argument, da die Software-Infrastruktur des Unternehmens hauptsächlich auf Microsoft Windows NT beruht. Das gilt sowohl für die Arbeitsplatzrecher, auf denen bereits zum großen Teil der Media Player standardmäßig installiert ist, als auch für die Anwendungsserver.

Der Kostenvergleich der Produkte fällt eindeutig zu Gunsten der Windows Media Technologies von Microsoft aus. Sämtliche Bestandteile stehen als kostenloses Download bereit und sind Bestandteil von Windows 2000 und neueren Versionen von Windows NT Server. RealNetworks bietet lediglich die im Funktionsumfang eingeschränkten 'Basic'-Produkte kostenlos an. Für weiteren Funktionsumfang muss man die kostenpflichtigen Produktlinien 'Plus' oder 'Professional' wählen.

Die Zeitschrift 'Internet Professionell' hat in der Ausgabe 01/2000 einen Vergleichstest zwischen Streaming Media Produkten durchgeführt. Die

(24)

folgende Tabelle²¹ stellt die Ergebnisse bezüglich Microsoft und RealNetworks dar. Höhere Werte beschreiben dabei eine höhere Leistungsfähigkeit.

RealSystem G2 Media Technologies 4

Serverleistung 80% 80%

Encoding 60% 90%

Authoring 75% 85%

Player 65% 85%

Gesamtwertung 72% 84,5%

Tab. 4.4

Auf weitere Einzelheiten zu den Test- und Bewertungskriterien wird an dieser Stelle nicht eingegangen, sie sind in dem genannten Artikel nachzulesen.

Zusammenfassend kann man sagen das die Microsoft Media Technologies 4 bezüglich der gebotenen Features, der geringeren Kosten, der vorhandenen Unternehmensinfrastruktur und der Bewertung in der Fachpresse für die Volkswagen AG die geeignetere Alternative ist. Es wird daher die Microsoft Lösung ausgewählt.

21 Vgl. Dreyer: Auf Sendung - Streaming Media im Test, Internet Professionell, Ausgabe 01/2000

(25)

Beschreibung der ausgwählten Software

5 Beschreibung der ausgewählten Software

5.1 Bestandteile der Microsoft Media Technologies 4

5.1.1 Microsoft Media Services

Die Server-Software ist für die Bereitstellung und Versendung von Media- Daten verantwortlich. Um den Server zu konfigurieren und zu verwalten stellt Microsoft den Windows Media Administrator zur Verfügung, welcher in einem Browserfenster des Internet Explorers ab Version 5 dargestellt wird. Man kann auf diese Weise auch von einem Remotecomputer aus auf den Server zugreifen.

Die Hauptaufgabe des Administrators ist dabei das Anlegegen und Verwalten von Veröffentlichungspunkten. Diese stellen die Schnittstellen bei einem Verbindungsaufbau zwischen Client und Server dar. Man hat dabei die Möglichkeit, Veröffentlichungspunkte für Multicastsendungen (Stationen) oder für Unicastverbindungen zu erstellen. Letztere werden noch einmal in On-Demand (Abruf der Dateien vom Client) und Broadcast (für Unicast-Live- Inhalte) eingeteilt.

Der Server bietet vielfältige Einstellungsmöglichkeiten zur Kontrolle von Zugriffszahlen und Bandbreitenanforderung für die einzelnen Veröffentlichungspunkte. Weiterhin werden dem Administrator Informationen zur Serverüberwachung gegeben, dazu gehören unter anderem Infos über die Datenstöme, die Connectraten und Ereignismeldungen.

5.1.2 Microsoft Media Tools

Die Microsoft Media Tools umfassen eine ganze Reihe von Programmen, um Streaming Media Dateien zu erstellen und um sie zu bearbeiten.

(26)

Das wichtigste Tool zur Inhaltserstellung ist der Media Encoder. Damit ist man in der Lage, Streaming-Dateien sowohl aus Live-Quellen (Videokamera etc.), als auch aus gespeicherten Dateien (z.B. AVI-Dateien) zu erstellen.

Diese Datenströme können bereits während der Kodierung an den Media Server übertragen werden, um Live-Sendungen zu ermöglichen. Das erstellte Streaming-Dateiformat wird 'Advanced Streaming Format' (ASF) genannt.

Der Media Encoder bietet diverse Einstellungsmöglichkeiten für die verwendeten Codecs und die gewünschten Zielbandbreiten. Es ist ebenfalls möglich in eine einzige Datei mehrere Zielbandbreiten zu kodieren, um während der Datenübertragung zum Client automatisch die beste Bandbreite auswählen zu lassen (wird als 'Intelligent Streaming' bezeichnet).

Mit dem Media Author lassen sich Bild- und Tondokumente synchronisieren, um z.B. Slideshows und Präsentationen zu erstellen.

Der Media Presenter ist ein Add-In für PowerPoint. Damit lassen sich PowerPoint-Präsentationen mit dem Media Encoder in einen Streaming- Datenstrom konvertieren.

Ein Tool zur Inhaltsbearbeitung ist der Media ASF Indexer. Er ermöglicht die Indizierung von bestimmten Stellen einer Datenstromdatei. Diese können dann vom Client direkt ausgewählt und wiedergegeben werden, wodurch man sich die Übertragung von unerwünschten Teilen der Datei erspart.

5.1.3 Microsoft Media Player

Der Media Player stellt die Clientkomponente der Media Technologies 4 dar.

Er wird benötigt, um die Datenströme zu dekodieren und wiederzugeben. Der Media Player kann dazu als eigenständige Applikation aufgerufen werden, er kann durch einen Hyperlink auf eine Metadatei (*.asx) gestartet werden, oder er kann in eine Webseite eingebettet werden. Die Protokolle, die beim Wiedergeben von ASF-Datenströmen zum Einsatz kommen sollen, können im einzelnen ausgewählt werden. Während der Wiedergabe stehen

(27)

umfangreiche Informationen zu den verwendeten Codecs, der Framerate und den Netzwerkeigenschaften (verwendetes Protokoll, Bandbreite etc.) zur Verfügung

5.2 Grundprinzip des Verbindungsaufbaus

Bei Hyperlinks auf einen Streaming-Datei erfolgt der Verbindungsaufbau über eine Metadatei (*.asx). Diese ist eine einfache Textdatei, die vom Browser über das normale HTTP-Protokoll empfangen werden kann.

Die ASX-Datei enthält ihrerseits einen Verweis auf den eigentlichen ASF- Datenstrom und Angaben über das zu verwendende Streaming-Protokoll.

Die Metadatei kann dabei auch zum Erstellen einer Wiedergabeliste genutzt werden, wobei Verweise auf mehrere ASF-Datenströme enthalten sind, die in der angegebenen Reihenfolge nacheinander abgespielt werden.

Ist der Media Player auf dem Client-Rechner installiert, so wird dieser automatisch zum Öffnen der Metadatei veranlasst. Der Media Player wertet nun die darin enthaltenen Angaben aus, und kann den ASF-Datenstrom vom Media Server anfordern. Die Kommunikation zwischen Player und Media Server geschieht nun unabhängig vom Browser und kann über eigene, nicht vom Browser abhängige Protokolle ablaufen.

Auf der Applikationschicht wird dabei standardmäßig das MMS-Protokoll verwendet. Es versucht zunächst auf der Transportschicht einen UDP- Datentransport zu etablieren, ist dies nicht möglich, so wird auf TCP zurückgegriffen. Dieses Verfahren wird als Protokollübergabe bezeichnet.

(28)

5.3 Testbetrieb der Media Technologies 4

Um erste praktische Erfahrungen mit den Microsoft Media Technologies 4 zu sammeln, wurden von mir auf einem Server die Media Services, auf einem weiteren Server der Media Encoder und auf einem Clientrechner der Media Player und der Media Administrator installiert. Alle Rechner befanden sich dabei in einem LAN-Segment. Dies hatte den Vorteil, dass auch Multicastübertragungen getestet werden konnten, da die Router bei Volkswagen aus Sicherheitsgründen bisher nicht für einen Multicastbetrieb konfiguriert sind.

Die Installation der einzelnen Komponenten gestaltete sich problemlos. Die Media Services waren bereits nach der Installation für die Übertragung von On-Demand Inhalten vorkonfiguriert, so waren nur wenige Einstellungen nötig, um eine erste Datei auf dem Clientrechner wiederzugeben. Die Konfiguration von Unicastveröffentlichungspunkten und von Multicast- stationen wird durch die Media Services bei Bedarf mit Assistenten unterstützt.

Die Einstellungen des Media Servers konnten mit dem Windows Media Administrator auch von dem Clientrechner aus vorgenommen werden.

Um einen Funktionstest durchzuführen wurde von mir eine Intranetseite erstellt, die über Metadateien Verweise auf die verschiedenen Inhalte auf dem Media Server enthielt. Die Intranetseite enthielt Links zu den folgenden Übertragungsarten, welche erfolgreich eingesetzt werden konnten:

 Unicast On-Demand-Verbindungen

 Unicast On-Demand-Verbindungen mit Playliste in der Metadatei

 Multicastübertragung mit konstanter Bitrate

 Multicastübertragung mit variabler Bitrate

 Live-Multicastübertragung

(29)

Für die Live-Multicastübertragung wurde das S-VHS-Signal einer Videokamera über eine Videokarte an den Media Encoder geleitet. Dieser kodierte die Informantionen und sendete einen ASF-Datenstrom an den Media Server, welcher die Inhalte über eine Multicaststation zur Verfügung stellte. Auf mehreren Clientrechnern konnte das Videosignal mit etwa 10 Sekunden Verzögerung wiedergegeben werden. Die leichte Verzögerung kommt dabei vor allem durch das Füllen des Cache-Puffers vor Beginn der Wiedergabe zustande.

Auf diese Weise konnte die gesamte Übertragungskette, die für eine Liveübertragung nötig ist, mit den wesentlichen Bestandteilen eingerichtet werden.

(30)

6 Literatur und Quellen

Bücher

 Dinkar Sitaram, Asit Dan: "Multimedia Servers"; Morgan Kaufmann Publishers, 2000

 Konrad Froitzheim: "Multimedia Kommunikation"; dpunkt.verlag; 1.

Auflage 1997

 Dilip C. Naik: "Internet – Standards and Protocols"; Microsoft Press;

1998

 Ralph Wittmann, Martina Zitterbart: "Multicast"; dpunkt.verlag; 1999

 Helmut Saaro: "Internet"; Markt&Technik; 1999

 Rumen Stainov: "IPnG – Das Internetprotokoll der nächsten Generation"; International Thomson Publishing; 1997

Artikel

 c't 6/2000: "Privatfernsehen – Video-Übertragung per Internet"; Heise- Verlag

 PC Professionell 8/2000: "Streaming Video"; Ziff-Davis-Verlag

 Internet Professionell 1/2000: "Auf Sendung - Streaming Media im Test"; Ziff-Davis-Verlag

Internet

 http://www.realnetworks.com

 http://www.microsoft.com/windows/windowsmedia

 http://www.service24.de/pe/ink.htm

 http://www.rvs.uni-bielefeld.de/~heiko/tcpip/kap_1_3.html

 http://www.computerwoche.de

 http://www.terran.com/CodecCentral/index.html