Streaming Media und RealVideo

Transkript

1 Streaming Media und RealVideo Arno Erpenbeck Februar 1999 Inhaltsverzeichnis 1 Einleitung 2 2 Audio und Video Vorbemerkungen Audio Formate Video Formate Streaming Idee Protokolle Produkte The RealSystem Überblick RealAudio und RealVideo RealPix RealText RealFlash Einbindung in Webseiten RealServer SMIL Überblick Beispiel Produkte Ausblick 12 7 Links Software Protocols, Specifications Sonstige Informationen

2 1 Einleitung In diesem Artikel wird die Idee von Streaming Media und das RealSystem vorgestellt. Um multimediale Inhalte über das Internet zu verteilen, müssen neue Methoden und Techniken angewandt werden, eine davon ist Streaming. Zuerst werden derzeitige Standard Audio- und Video-Formate beschrieben. Dabei werden einige Probleme angesprochen, die beim Einsatz dieser Formate im Internet entsehen. Es folgt ein Überblick über Streaming Technologien und spezielle Protokolle wie RTP und RTSP. Als Beispiel für den praktischen Einsatz von Streaming wird das RealSystem von Real Networks vorgestellt. Die neue Markup Sprache SMIL eröffnet viele Möglichkeiten, um Präsentationen zu erstellen, die aus synchronisierten Media Objekten bestehen. Abschließend erfolgt ein Ausblick über die weitere Entwicklung im Streaming Media Bereich und konkurrierende Vorschläge. 2 Audio und Video 2.1 Vorbemerkungen Zuerst sollen zwei Begriffe geklärt werden, die im Multimedia Bereich häufiger gebraucht werden: Multimedia Architektur und Codec. Eine Architektur definiert einen Rahmen für Software Komponenten zur Erstellung, Wiedergabe und Speicherung von multimedialen Daten. Dabei werden z.b. Dateiformate und Schnittstellen zu Audio- und Video-Codecs definiert. Die einzelnen Architekturen haben meistens einen schwerpunktmäßigen Einsatzbereich (Internet, CD-ROM) und dementsprechend unterschiedliche Stärken und Schwächen. Beispiele für Multimedia Architekturen sind QuickTime (Apple), RealMedia (RealNetworks), Video for Windows, DirectShow, NetShow (Microsoft). Codec steht für Compressor/Decompressor. Speichert man Audio oder Video Daten unkomprimiert ab, hat man das Problem, das sehr schnell sehr große Dateien entstehen. Man versucht also, mit einem geeigneten Algorithmus unwichtige Informationen zu löschen, so das der Gesamteindruck unverändert bleibt. Es läuft dabei auf einen Kompromiß aus Qualität und (Datei-)Größe hinaus. Manche Codecs eignen sich eher für Bilder, manche für Audio oder Video, einige spielen ihre Stärken im Netzbereich aus, während andere mehr für CD-ROM oder DVD geeignet sind. Sie unter-scheiden sich auch in Geschwindigkeit der Komprimierung und Größe der komprimierten Datei. Bei der Komprimierung sind verschiedene Algorithmen im Einsatz wie DCT 1, DWT 2 oder Fractal Imaging. Hierbei gibt es Software und Hardware Lösungen. Einige bekannte Codecs sind CinePak (SuperMac), CinePak Pro (CTi), Indeo (Intel), MJPEG 3 und MPEG. 2.2 Audio Formate Zur Speicherung von Audio-Daten gibt es zahlreiche Dateiformate, von denen die wichtigsten hier kurz vorgestellt werden sollen. Sie unterscheiden sich u.a. in der sampling rate, bit rate und Anzahl der Kanäle. Als Faustregel kann man sagen, daß ein besserer Klang auch zu einer größeren Datei führt. 1 DCT: Discrete Cosine Transformation 2 DWT: Discrete Wavelet Transformatiom 3 MJPEG: Motion JPEG 2

3 AU Das sogenannte -law Format trifft man am häufigsten in UNIX-Welt an (insb. Sun). Es ist auch Standard-Audio-Format bei Java. AU ist ein 8-bit Format mit einer 8 khz sampling rate; es sind ein oder zwei Kanäle möglich (mono/stereo). WAV Das WAV-Format wurde von Microsoft und IBM eingeführt und ist sozusagen Standard in der Windows-Welt. Es bietet sampling rates von 8 bis 48 khz und eine bitrate von 8 oder 16 bit. Es stehen zwei Kanäle zur Verfügung (mono links, mono rechts, mono gemischt, stereo). AIFF Das Audio Interchange File Format wird hauptsächlich von Apple und Silicon Graphics genutzt. Bei verschiedenen samplig rates sind 8 bit in mono und stereo möglich. Eine Variante ist AIFFC (AIFF Compressed), das zusätzliche Komprimierung erlaubt. MPEG-Audio Die Motion Picture Expert Group hat verschiedene Audio und Video Standards ausgearbeitet. Zur Zeit gibt es im Audio Bereich MPEG-1 und MPEG-2, die in verschiedene Layer unterteilt werden. MPEG-1 bietet in den Layern I-III sampling rates von 32 bis 48 khz und bit rates von 32 bis 448 kbit/s in 2 Kanälen. MPEG-2 stellt darüber hinaus 5 Hauptkanäle und 1 low frequent enhancement channel (LFE) und bitrates bis 1 Mbit/s zur Verfügung. Bei MPEG-2 AAC (Advanced Audio Coding) werden schließlich alle Register gezogen: 1-48 Kanäle, sampling rate 8-96 khz und bitrates kbit/s. Das führt natürlich zu sehr großen Dateien (20 Sekunden MPEG-1 Layer II 360 KB). VQF Von Yamaha stammt dieses relativ neue Format ab, was klanglich bessere Ergebnisse als MPEG-1 Layer III (auch bekannt als MP3) liefern soll, bei etwas kleinerer Dateigröße. Zur Zeit ist zum Abspielen aber ein spezieller Player oder Plug-in erforderlich. MIDI Das Musical Instrument Digital Interface soll noch kurz erwähnt werden, obwohl es nicht ganz in diese Reihe paßt. Im Gegensatz zu obigen Formaten entstehen MIDI Daten nicht durch sampling einer Audio-Quelle, sondern sie dienen zur Beschreibung von Musik. Über MIDI können z.b. Synthesizer oder Soundkarten gesteuert werden. Eine MIDI Datei enthält Noten mit Angaben zur Höhe, Dauer und Lautstärke und dem "Instrument", auf dem sie erzeugt werden sollen. 2.3 Video Formate Wie im Audio-Bereich, so gibt es auch im Video-Bereich verschiedene Dateiformate. Komprimierung ist hier noch stärker erforderlich, da sonst die Dateigrößen alle Grenzen sprengen (unkomprimiertes Video verbraucht ca. 27 MB pro Sekunde!). Charakteristika einzelner Video Formate sind die Größe des dargestellten Videos (pixel) und die frame rate (frames per second, fps), d.h. wie häufig ein frame (Bild) wiederholt wird. Die drei häufigsten Formate sind: 3

4 AVI Das Audio Video Interface ist Grundlage von Microsofts Video for Windows. Es bietet eine Auflösung von pixel und eine frame rate von 30 fps. Vorteil von AVI ist, das keine extra Hardware erforderlich ist. Es unterstützt verschiedene Codecs, wie z.b. Intel Indeo oder CinePak. MPEG MPEG-1 ermöglicht pixel und 30 fps. MPEG-1 ist eine Software Lösung, die Qualität ist aber eher gering. MPEG-2 soll als Basis von HDTV 4 und DVD 5 dienen und bietet neben Audio in CD-Qualität Auflösungen von bis bei maximal 60 fps. MOV Apples QuickTime Format ist qualitativ und auch von der Dateigröße mit AVI vergleichbar. Die QuickTime 3 Architektur erweitert das Angebot um Animation und Virtual Reality. 3 Streaming 3.1 Idee Ausgangssituation beim Streaming ist der Wunsch, daß ein Benutzer Multimedia-Daten (Audio, Video) ohne lange Wartezeiten betrachten kann. Stellt man ein Video z.b. als AVI im Internet zur Verfügung, so muß der Benutzer erst die ganze Datei auf seinen Computer herunter laden. Das kann insbesondere bei einer langsamen Netzanbindung (Modem) wegen der Größe der Dateien (s.o.) sehr lange dauern. Streaming ermöglicht es, mit dem Abspielen eines Films quasi sofort zu beginnen: Einkommende Pakete werden decodiert und abgespielt. play packet decompress packet receive packet Zu den Komponenten eines Streaming Systems gehören Möglichkeiten zur Erstellung und Bearbeitung von Multimedia Daten, entsprechende (Datei-)Formate, sowie Media-Server und Player. An ein Streaming System werden gewisse Anforderungen gestellt: Wichtig ist ein möglichst gleichmäßiger Datenfluß, die Server-Belastung soll möglichst gering sein, und das ganze System muß skalierbar sein. Für den Client sollten sowohl on-demand (unicast) als auch near-on-demand (time-staggerd multicast) Services angeboten werden können, ebenso wie z.b. Live-Events. Wichtig ist auch die Integrationsmöglichkeit in bestehende Applikationen. 4 HDTV: High-Definition Television 5 DVD: digital versatile disc 4

5 3.2 Protokolle Beim Streaming kommen verschiedene Transport- und Kontroll-Protokolle zum Einsatz. Das Standard-Protokoll des Internet (TCP 6 ) eignet sich aus folgenden Gründen nur bedingt zum Streaming: Zum einen haben die Pakete keine feste Route vom Server zum Client, zum anderen ist die zur Verfügung stehende Bandbreite nicht fest. Beides führt dazu, daß eine quality-of-service Garantie nicht gegeben werden kann. Retransmission von Paketen führt zur Unterbechung der Übertragung, ein Effekt der hier unerwünscht ist. Beim Streaming kommt es auf einen gleichmäßigen Datenfluß an. Die Wiedergabe wird weniger durch fehlende Pakete (die übersprungen werden können) gestört, als durch eine Unterbechung des Streams. Diese Punkte führten dazu, daß u.a. folgende Protokolle entwickelt wurden und im Einsatz sind: RTP Das Realtime Transport Protocol (RFC 1889, 1890) ist ein paket-basiertes Protokoll für Multimedia Data Streams. Es ist ein Proposed Standard von der IETF 7 und auch ITU 8 Standard. RTP unterstützt unicast und multicast und benutzt (üblicherweise) UDP, d.h. es ist kein reines Transport Protokoll. RTP arbeitet mit derzeitigen und kommenden Standards zusammen: IPv4, IPv6, ATM, ADSL - alles ist möglich. Der RTP header eines jeden Paketes enthält einen timestamp, eine payload type id und eine sequence numbering. Durch den timestamp läßt sich die Reihenfolge der einkommende Pakete ermitteln, was wichtig ist für Synchronisation und zum Feststellen, ob Pakete verloren wurden. Das payload format macht z.b. Angaben zum verwendeten Audio/Video Encoding. RTP kann natürlich eine (rechtzeitige) Zustellung der Pakete nicht garantieren, genauso wenig wie eine feste Reihenfolge bei der Ankunft der Pakete. Ein quality-ofservice Garantie kann aus diesen Gründen nicht gegeben werden. RTP wird u.a bei Internet-Telephony, Microsoft NetMeeting, Netscape LiveWire und Cu- SeeMe eingesetzt. RTCP Das Realtime Control Protocol arbeitet mit RTP zusammen. Es kontrolliert die Übertragung von RTCP Paketen in einer RTP Session und ermöglicht Rückmeldung vom Empfänger an den Sender. Mit RTCP können so Informationen über den Datenfluß (packets sent/lost) ausgetauscht werden. Durch einen canonical name kann die RTP Quelle eindeutig identifiziert werden. RTSP Das Realtime Streaming Protocol (RFC 2326) ist ein von der MMUSIC 9 Group ausgearbeiteter IETF Proposed Standard. Entwickelt wurde es von Progressive Networks, Netscape, un der University of Columbia. RTSP ist ein applicationlevel protocol, das Multimedia Streams eröffnet und kontrolliert. Es benutzt RTP und ist somit für unicast und multicast einsetzbar. RTP bietet einige Möglichkeiten, die für Streaming Systeme sehr wichtig sind: Caching von Daten (ähnlich wie bei HTTP), load balancing, d.h. Wechseln des Servers innerhalb eines Streams, und Synchronisation verschiedener Streams von mehreren Servern. Eine beliebige Positionierung innerhalb des Streams ist möglich, was den Begriff "Internet VCR" geprägt hat. Es eignet sich ebenso für große Zielgruppen wie einzelne User (media-on-demand). 6 TCP: Transmission Control Protocol 5

6 RSVP Das Resource Reservation Protocol schließlich soll eine quality-of-service Garantie ermöglichen und einmal angeforderte Bandbreiten dauerhaft zur Verfügung stellen. Das kann zur Zeit allerdings höchstens in Test-Konfigurationen erreicht werden, ein tatsächlicher Einsatz steht noch aus. HTTP GET session description Web Server PLAY Client RTP audio RTP video RTCP Media Server PAUSE TEARDOWN Diese Protokolle arbeiten so zusammen, daß mit RTSP eine Verbindung hergestellt und kontrolliert wird (stream control), während RTP und RTCP den Datentransfer übernehmen (media transport) und RSVP (wenn es denn zum Einsatz kommt) die nötigen Ressourcen liefert und garantiert (resource reservation). 3.3 Produkte Im folgenden sollen nur kurz einige Streaming Systeme vorgstellt werden, für weitere Informationen sei auf die HTML-Fassung verwiesen. RealNetworks hat im Dezember 1998 sein RealSystem G2 aus der Beta-Phase entlassen, Microsoft bietet mit dem NetShow Theater Server ebenfalls ein leistungsstarkes Server System. Daneben werden im Internet auch noch Digital Bitcasting s Net Toob und das VDOLive System häufiger eingesetzt. Das RealSystem G2 besteht aus RealServer, RealPlayer und RealProducer, mit denen stream-basierte Multimedia-Daten erstellt, bereitgestellt und wiedergegeben werden können. Plug-ins für PowerPoint und Adobe Premiere erlauben Integration in bestehende Multimedia Systeme. Es werden zahlreiche Windows- und UNIX-Plattformen unterstützt, was einen breiten Einsatzbereich ermöglicht. Der NetShow Theater Server nutzt Windows NT als Server-System und den Microsoft MediaPlayer zur Wiedergabe. Ein Title Server sowie bis zu 14 Content Server stellen die Inhalte bereit. Bandbreiten bis 8 Mbps können genutzt werden, was z.b. zum Streaming von fullscreen MPEG Videos genutzt werden kann. 7 IETF: Internet Engineering Task Force 8 ITU: International Telecommunication Union 9 MMUSIC: Multiparty Multimedia Session Control Working Group 6

7 Net Toob ist ein Beispiel für eine Lösung ohne speziellen Server, Streaming erfolgt über den Webserver und HTTP bzw. TCP/IP, was auch oben genannte Probleme mit sich bringt. Net Toob kann z.b. MPEG-1 Videos streamen. 4 The RealSystem 4.1 Überblick Das RealSystem G2 läßt sich in die drei Bereiche Create, Serve und Play einteilen. Create bedeutet Erstellung und Bearbeitung von Streaming Media mit dem RealProducer, der Audio- und Video-Daten in das RealMedia Format umwandelt. Standardmäßig werden zahlreiche Audio- und Video-Formate unterstützt. Außerdem können Text, Grafik (JPEG, GIF) und Animation in der Präsentation verwendet werden. RealText bietet zahlreiche Gestaltungsmöglichkeiten für Textinformationen, RealPix optimiert Grafiken für den Streaming Einsatz und stellt z.b. Überblend-Effekte bereit. RealFlash schließlich ist eine Schnittstelle zu Macromedia Flash Animationen. Natürlich können nicht nur bereits vorhandene Daten als Stream geschickt werden, der LiveEncoder kann z.b. als Basis für Internet-Radio und Internet-TV dienen. Der RealServer stellt diese Daten zum Streaming bereit. RealNetworks bietet verschiedene Lösungen an, die für Intranet (z.b. Schulung) oder Internet (z.b. Video-on-demand) optimiert sind. Auf Betrachter-Seite kommt der RealPlayer zum Einsatz. 4.2 RealAudio und RealVideo Bis ein Video zum Streaming bereit steht, werden i.a. folgende Schritte durchlaufen: Mit Kamera, Mikrophon, etc. wird ein Film produziert (capture), dieser dann digitalisiert und bearbeitet (optimize) und mit dem RealProducer in ein passendes Format umgewandelt (encode). Die so entstanden Dateien können nun vom RealServer geliefert werden (deliver). Der RealProducer G2 ermöglicht es hierbei, in einer Datei Inhalte für verschiedene Bandbreiten (target bandwith) zu speichern. RealNetworks SureStream Technologie wählt beim Abspielen dann immer die beste zu erreichende Qualität aus, die der Client erreichen kann. So kann eine Datei z.b. ein Musik-Stück in unterschiedlichen Qualitäten für Modem, ISDN oder schnelle LANs enthalten. Beim Erstellen der RealMedia Dateien (.rm) sollte je nach Zielgruppe und Inhalt ein passender Codec gewählt werden. Legt man seinen Schwerpunkt auf hohe Klangqualität, wird man einen anderen Codec nehmen als bei einem Video, das nur talking heads zeigt. Die vom RealProducer zur Verfügung stehenden Codecs ermöglichen es, selbst für eine 28.8K Modem Verbindung Videos in aktzeptabler Qualität zu erstellen. Bei Codecs für schnelle Netzanbindung (Dual ISDN und aufwärts) sind die Ergebnisse wirklich sehenswert. Im Video Bereich kann der RealProducer komprimierte und unkomprimierte AVI Dateien ebenso verwenden wie MPEG-1 und QuickTime 2.0 (.mov). Als Audio Formate können AIF, AU, MPEG-1, Sound (.snd) und WAV eingesetzt werden. 4.3 RealPix Mit RealPix hat man die Möglichkeit, Bilder (Grafik) im Internet oder Intranet in einem Stream zu verwenden (streaming image). Standardmäßig können mit RealPix folgende Formate zum Streaming verwendet werden: 7

8 GIF89a und GIF87 (.gif) Es können sowohl interlaced als auch non-interlaced GIFs verwendet werden, wobei die interlaced Variante keine Vorteile bringt. Animated GIFs werden nicht unterstützt. JPEG (.jpg) Es werden nur Standard JPEGs (baseline) unterstützt, nicht aber progressive oder grayscale JPEGs. Iterated Sting (.stg) Ein sehr neues Format von Iterated Systems, das Bilder auflösungs-unabhängig abspeichert und so Qualitätsverluste beim Skalieren/Weiterverarbeiten vermeidet. Windows Bitmap (.bmp) Da Bitmaps unkomprimiert abgespeichert werden, wird ihre Verwendung nicht empfohlen. Sie sollten nur lokal zum Einsatz kommen. Da der RealPlayer G2 keinen disk cache (sondern nur memory cache) verwendet, hat der Betrachter keine Möglichkeit, empfangene Bilder abzuspeichern und weiterzuverarbeiten. So können in einer Streaming Präsentation z.b. auch Copyright geschützte Bilder benutzt werden. Um Grafiken in einer Präsentation zu verwenden, muß eine sogenannte RealPix- Datei (.rp) erstellt werden. Diese ist eine einfache Textdatei, die verschieden Tags enthält, die die Präsentation steuern. So gibt es beispielsweise Tags wie <fadein>, <fadeout>, <crossfade>, <wipe> und <viewchange>, mit denen sich Bilder überlagern lassen und Effekte wie Panning und Zoom erzielt werden können. RealPix Dateien haben folgenden Aufbau: <imfl> <head... Attribute... />... andere Tags... </imfl> Das <imfl> Tag umschließt die ganze Datei, im <head> Tag werden u.a. Einstellungen zu Größe, Timing, Bitrate und Preroll gemacht. Für weitere Erläuterungen zur Syntax von RealPix Dateien und genauen Verwendung der Tags sei auf die HTML-Version von diesem Vortrag verwiesen. 4.4 RealText Mit RealText kann einfacher Text in einer Präsentation als Stream eingebaut werden. Dies eignet sich z.b. für Nachrichtenticker, Börsendaten, etc. Der Vorteil liegt in der geringen benötigten Bandbreite, so daß andere Elemente der Präsentation nicht gestört werden. Ein eigenes RealText-Format (.rt) steuert Timing und Effekte über HTMLähnliche Tags. Der grobe Aufbau einer RealText Datei sieht so aus: <window... options... >... andere Tags... </window> Das <window> Tag regelt Einstellungen zur Fenstergröße, Farbe, usw. Mit anderen Tags wird der Text formatiert (Schriftgröße, Farbe, Position, usw.). Auch hier findet man in der HTML-Version genauere Informationen. 8

9 4.5 RealFlash Um Animation in einer Präsentation einzubauen, kann RealFlash eingesetzt werden. RealFlash kombiniert Animationsmöglichkeiten von Macromedia Flash mit RealAudio. Bei Flash hat man das Problem, daß bei Verwendung von Audio-Clips (je nach Qualität) die Flash Dateien sehr groß werden. RealFlash verschafft hier Abhilfe: Die Animation wird ohne Ton abgespeichert und bleibt deshalb klein, der Ton kommt als RealAudio Stream dazu. So kann man auch hochwertige Audio-Streams in die Animation einbauen. Zu beachten ist jedoch, das der Bandbreiten-Verbrauch von Flash Animationen nicht gleichmäßig verläuft. Bei großen Änderungen in der Szene kommt es zu sog. Spikes, die parallel laufende Streams eventuell negativ beeinflußen. 4.6 Einbindung in Webseiten Um die fertige Präsentation im Internet bereitzustellen, gibt es zwei Möglichkeiten. Zum einen wird über einen einfachen Hyperlink wird ein externer RealPlayer gestartet. <a href="rtsp://my.realserver.com/my/file.rm"> Eine andere Möglichkeit ist, den RealPlayer mit einem <embed> Tag in die Webseite einzubetten: <embed src="..." width=300 height=200"> <noembed>realplayer benutzen</noembed> Die Einbettung erfolgt als Plug-in (Netscape) oder Active-X (Microsoft). Durch die Einbettung hat man größere Freiheiten für Kontrolle und Layout. Ferner gibt es Möglichkeiten, den RealPlayer über Java oder JavaScript zu steuern, zur Zeit aber nur mit wechselndem Erfolg. 4.7 RealServer Der RealServer stellt die Daten für den Streaming Einsatz bereit. Im Gegensatz zu Microsofts NetShow Theater Server, der nur auf NT läuft, gibt es den RealServer G2 für zahlreiche Plattformen (Windows 9x, NT, Linux, FreeBSD, IRIX, Solaris, HP/UX, etc.). RealNetworks bietet verschiedene Lösungen je nach Zielgruppe und Geldbeutel an, ein BasicServer ist kostenlos erhältlich. Im getesten Fall (BasicServer auf Windows 95, NT, Linux) lief die Installation und Zusammenarbeit mit dem Webserver problemlos. 9

10 HTTP RAMGEN HTTP 1 WebBrowser RealServer SMIL RTSP 2 3 Media Clip RTSP 4 RealPlayer Das Zusammenspiel von RealServer, Web-Server und Browser verläuft so: 1. Über HTTP fordert der Web Browser ein SMIL File. In der URL steht der Parameter RAMGEN Die Antwort vom RealServer veranlasst den Web Browser, den RealPlayer als externe Applikation zu starten. 3. Der RealPlayer fordert über RTSP das SMIL File an. 4. Mit den Informationen aus dem SMIL File, fordert der RealPlayer Streaming Media Files vom RealServer an. 5 SMIL 5.1 Überblick Die Synchronized Multimedia Integration Language wurde entwickelt um Multimedia Objekte in einer Präsentation (synchronized multimedia presentation) zu integrieren. Mit SMIL kann man 1. das zeitliche Verhalten der Präsentation steuern 2. das Layout der Präsentation festlegen 3. ausgewählte Media Objekte mit Hyperlinks versehen SMIL 1.0 ist seit dem 15. Juni 1998 offizielle W3C Recommendation. Maßgeblich an der Entwicklung beteiligt waren Netscape, RealNetworks, CWI und Lucent/Bell Labs. Microsoft ist kurz vor der Veröffentlichung der Recommendation aus dem Projekt ausgestiegen. SMIL Dokumente sind XML 1.0 Dokumente, die DTD 11 ist beim W3C erhältlich. 10 Beispiel: <a href=" </a>. 11 DTD: Document Type Definition 10

11 Eine SMIL Datei regelt das zeitliche und räumliche Zusammenspiel von verschiedenen Media Objekten. Die wichtigsten Fähigkeiten sind Gruppierung und Timing von Clips, Layout, Bedingungen und Hyperlinks (Hotspots). So kann in einem Fenster beispielsweise in einem Bereich ein Video abgespielt werden, nach 10 Sekunden fängt in einem anderen Bereich ein Animation an und gleichzeitig werden in einem Scrolling Text Informationen angezeigt. Clips können also parallel oder sequentiell angezeigt werden. Wenn der Betrachter im Video an einer bestimmten Stelle (zeitlich/räumlich) klickt, kann eine andere Präsentation gestartet werden oder eine Webseite im Browser aufgerufen werden. 5.2 Beispiel Eine SMIL Datei hat folgenden Grundaufbau: <smil> <head> Erscheinung und Layout der SMIL Präsentation </head> <body> Timing und Inhalt </body> </smil> Folgendes Beispiel zeigt, wie eine einfache SMIL Datei aussieht. Zwischen den <head> Tags stehen Angaben zum Layout: Aufteilung des root windows in regions, Größe der einzelnen regions, und deren Bezeichnung (id). Dazu dienen die Tags <layout> und <region>. Das Layout kann auch alternativ mit CSS2 12 beschrieben werden, dies wird zur Zeit vom RealPlayer aber nicht unterstützt. Die <body> Tags umschließen Referenzen zu den einzelnen Clips (hier zwei Textstreams und ein Video-Clip). Das <par> Tag gibt an, daß diese Clips parallel abgespielt werden sollen (<seq> wäre die sequentielle Variante). <smil> <head> <!--SMIL Präsentation mit 2 Text Clips und 1 Video Clip--> 12 CSS: Cascading Style Sheets 11

12 <meta name="title" content="music of the Week"/> <layout> <root-layout width="430" height="165"/> <region id="newsregion" top="0" left="0" width="250" height="144"/> <region id="videoregion" top="0" left="250" width="180" height="144"/> <region id="stockregion" top="145" left="0" width="430" height="20"/> </layout> </head> <body> <par> <!--Diese 3 Clips parallel spielen--> <textstream src="news.rt" region="newsregion"/> <video src="newsvid.rm" region="videoregion"/> <textstream src="stocks.rt" region="stockregion"/> </par> </body> </smil> 5.3 Produkte Mittlerweile gibt es auch schon einiges an Software, was einem bei der Arbeit mit SMIL hilft. Player: Neben dem RealPlayer G2 von RealNetworks sind der GRiNS Player von niederländischen CWI 13, der Helio Player und das HPAS System von Digital zu erwähnen. Authoring Tools: Das RealNetworks G2 AuthoringKit besteht aus einigen kleinen Programmen, die z.b. Bandbreiten Nutzung berechnen können. Außerdem findet man dort ausführliche Dokumentation. Veon liefert mit V-Active ebenso wie Digital Renaissance mit dem TAG-Editor eine komplette Entwicklungsumgebung für anspruchsvolle SMIL Präsentationen. 6 Ausblick Die Streaming Technologie steht zwar erst am Anfang, mit den aktuellen Produkten können aber wirklich schon brauchbare Resultate erzielt werden. Sicher gibt es keine Lösung, die alle Probleme gleich gut bewältigt. Stattdessen werden je nach Insatzgebiet spezialisierte Produkte für Internet oder Intranet immer leistungsstärker. Neben RSVP wird auch IP Multicasting eine bedeutende Rolle spielen. 13 CWI: Centrum voor Wiskunde en Informatica (National Research Institute for Mathematics and Computer Science) 12

13 Zwei neuere Entwicklungen sollen zum Schluß kurz angesprochen werden. Microsoft hat mat HTML+TIME einen eigenen Vorschlag für Timing, Interaktion und Streaming mit HTML eingebracht. Unterstützt wird dieser Vorschlag von Compaq, Macromedia und Digital Renaissance. HTML+TIME baut auf existierenden Standards wie HTML 4.0, CSS und XML. Idee ist, HTML um solche Tags zu erweitern, die ähnliche (oder mehr) Möglichkeiten bieten wie SMIL. Das HTML+TIME Dokument wird dann aber im Browser und nicht wie bei SMIL in einem eigenen Player angezeigt. Somit soll eine volle Einbindung in das HTML Document Object Model (DOM) möglich sein. Ein Problem ist aber auch die erneute Vermischung von Inhalt und Gestaltung, die man gerade mit CSS umgehen wollte. Ebenso scheint Microsofts Active Streaming Format (ASF) erwähnenswert. ASF ist ein Multimedia Dateiformat, in dem Daten in Paketen gespeichert werden, die direkt in einem Transport Protokoll verschickt werden können. ASF Streams können über HTTP Server oder spezialisierte Media Server verschickt werden, mit TCP/IP, UDP/IP, RTP und IPX/SPX. Version 1.0 ist schon seit längerem im Einsatz, bietet aber nur einen geringen Teil dieser Möglichkeiten. Version 2.0 soll als Bestandteil von Windows NT 5.0 (Windows 2000?) aufgenommen werden und wird Basis für NetShow 3.0 sein. 7 Links Weitere Informationen bekommt man im Internet u.a. bei folgenden Adressen: 7.1 Software RealNetworks: Microsoft NetShow TheaterServer: Macromedia Flash: Apple Quicktime: Protocols, Specifications RTP: hgs/rtp RTSP: hgs/rtsp SMIL Specification: SMIL DTD: HTML+TIME: 13

14 7.3 Sonstige Informationen Iterated STiNG: JustSMIL: Microsoft ASF: Eine HTML Version dieses Vortrag ist zu finden unter: www2.informatik.uni-osnabrueck.de/web_pub_8/ Dieser Text wurde mit lyx und LATEX erstellt, die PDF Version mit ps2pdf. Die Zeichnungen wurden mit Xfig gemacht. Für die HTML Seiten wurde HotDog Professional eingesetzt. 14