Seminar / Projekt
Realtime-Streaming Herbert Sojnik - 9331074 E-Mail:
[email protected]
Keywords: Real-Audio, Real-Video, MS-Media, MP3-Streaming, Internetradios, Audio-Streaming, Video-Streaming, AKM, Austro Mechana, Live-Streams
Kurzfassung: Die Entwicklung von Komprimieralgorithmen für Audio- und Videodaten, vor allem MPEG, macht es erstmals möglich, Audio- und Videodaten auf eine Internet-taugliche Größe zu bringen. Der gemeinsame Einsatz von Realtime Protokollen und Kompressionsmechanismen führt schließlich zur Streaming Technologie. Diese Arbeit gibt einen Einblick in die verschiedenen Einsatzgebiete der neuen Medien und stellt die Technik vor, die dahinter steht. Ein weiteres Augenmerk richtet sich auf Internetradios und die gesetzlichen Bestimmungen, die in Österreich dafür gelten.
IICM TU-Graz, Austria Graz, Juni 2000
Inhaltsverzeichnis 1 EINLEITUNG........................................................................................................................3 2 ANWENDUNGSMÖGLICHKEITEN ................................................................................4 2.1 RADIOSTATIONEN IM INTERNET.........................................................................................4 2.2 VIDEO-STREAMING ...........................................................................................................5 3 ÖSTERREICHISCHE INTERNETRADIOS.....................................................................7 4 DIE RECHTLICHE SITUATION IN ÖSTERREICH .....................................................9 4.1 DIE AKM ..........................................................................................................................9 4.2 DIE AUSTRO MECHANA ...................................................................................................10 4.3 DIE PLATTENFIRMEN .......................................................................................................10 5 TECHNISCHE GRUNDLAGEN.......................................................................................11 5.1 VIER STANDARDS ............................................................................................................11 5.2 DER DATENFLUSS ............................................................................................................11 5.3 PROXIES UND FIREWALLS ................................................................................................12 6 DAS RTSP PROTOKOLL .................................................................................................15 6.1 EIGENSCHAFTEN ..............................................................................................................15 6.2 PROTOKOLLPARAMETER ..................................................................................................16 6.3 DATENAUSTAUSCH ..........................................................................................................16 6.4 BEISPIELE ........................................................................................................................17 7 REAL-AUDIO CONTRA MP3-STREAMING................................................................19 8 ZUKUNFTSPERSPEKTIVEN ..........................................................................................21 9 GLOSSAR ............................................................................................................................22 10 BIBLIOGRAPHIE ............................................................................................................24
Seite 2
1 Einleitung Realtime-Streaming bezeichnet die Möglichkeit Audios und Videos aus dem Internet zu laden und gleichzeitig anzuhören bzw. anzusehen. Die Wiedergabe beginnt sobald eine bestimmte Datenmenge übertragen ist, es muss nicht der vollständige Download der Datei abgewartet werden. Mit diesem Begriff assoziiert man unweigerlich Real-Audio oder Real-Video. Hinter diesen beiden Produkten steht die Firma RealNetworks1, die zwar maßgeblich an der Entwicklung des wichtigsten Protokolls für Realtime-Streaming RTSP beteiligt war, aber nicht der einzige Entwickler auf diesem Gebiet ist. Kapitel 6 dieser Arbeit ist dem RTSP Protokoll gewidmet. Apple beispielsweise unterstützt mit dem Quicktime-4-Player den RTSP Standard und arbeitet daneben im Rahmen eines Open-Source Projektes an einem Media Server namens Darwin, der ebenfalls RTSP unterstützt [DARWIN]. Ein weiteres Open-Source Projekt namens IceCast arbeitet mit MP3-Streams, die mit den meisten gängigen Software MP3Playern abgespielt werden können [ICECAST]. In Kapitel 7 wird auf diese kostengünstige Alternative zum Real-Audio Streaming näher eingegangen. Microsoft dagegen geht mit der Windows Media Technologie 4.0 wieder eigene Wege – abseits von offenen Standards. Das MS-Audio Format soll MP3 als Format für komprimierte Musikdateien und Real-Audio als derzeitigen Standard beim Streaming ablösen. Das KombiDateiformat ASF (Active Streaming Format) für das Übertragen von Audio- und Videodaten, Indizierung und die Vergabe von Rechten, sieht Microsoft schon als Nachfolger von RealVideo und Quicktime [MSAUDIO]. In den Anfängen war es undenkbar Sprache, Musik oder gar Videos über das Internet zu übertragen. Mit der Entwicklung von Komprimieralgorithmen für Audio- und Videodaten, vor allem der MPEG–Technologie, war es erstmals möglich diese ungeheuren Datenmengen auf eine Internet-taugliche Größe zu bringen. Der gemeinsame Einsatz von Streaming Protokollen und Audio- bzw. Videokompression führte schließlich zum Audio- und Videostreaming und es ergaben sich dadurch ungeahnte neue Möglichkeiten. Diese Arbeit gibt einen Einblick in die verschiedenen Einsatzgebiete von Streaming Medien und stellt die Technik vor, die dahinter steht. Ein weiterer Schwerpunkt richtet sich auf Internetradios in Österreich. Kapitel 4 beschäftigt sich ausführlich mit den rechtlichen Vorschriften, die in diesem Zusammenhang zu beachten sind.
1
http://www.realnetworks.com
Seite 3
2 Anwendungsmöglichkeiten Das meist genutzte Einsatzgebiet der Realtime-Streaming Technologie findet man momentan in Form von Real-Audio Anwendungen. Der benötigte Player von RealNetworks, mittlerweile in der Version G2 erhältlich, gehört zum Installationsumfang der Standardbrowser Microsoft Internet-Explorer und Netscape Navigator und kann außerdem kostenlos von der Webseite der Firma heruntergeladen werden. Die Audiodaten werden bei Real-Audio mit aufwendigen Algorithmen derart gut komprimiert, dass sogar Benutzer mit älteren 33.6kBaud-Modems den Ton in einer akzeptablen Qualität empfangen können. Die gute Verbreitung der Abspielsoftware und die entsprechende Tonqualität führten zu einer weiten Akzeptanz des Formates. Eine beliebte Einsatzmöglichkeit findet man bei Plattenläden im Internet, beispielsweise bei Amazon2. Der Kunde kann rund um die Uhr im angebotenen Sortiment schmökern und hat die Möglichkeit, einen kurzen Ausschnitt der Titel sofort in Form eines Real-Audio Streams anzuhören. Aus Gründen des Copyrights darf nicht der ganze Track zur Verfügung gestellt werden. Einen ähnlichen Anwendungsfall findet man auf der Internetseite MP3.com. Die gleichnamige Firma ermöglicht unbekannten Musikern die Veröffentlichung ihrer noch nicht lizenzierten Titel und bietet sie allen Interessenten zum kostenlosen Download an. Die Seite umfasst über 424.000 Titel von 67.000 verschieden Interpreten (Quelle: MP3.com), die entweder im MP3-Format heruntergeladen, oder als Real-Audio Stream probegehört werden können [WWWMUSIK].
2.1 Radiostationen im Internet Ein weiterer Anwendungsfall, der vor allem in letzter Zeit an großer Bedeutung gewonnen hat, sind Internetradios. Diese „Radiostationen“ strahlen ihr Programm nicht über einen terrestrischen Sender aus, sondern stellen es den Hörern über Live-Stream im Internet zur Verfügung. Abbildung 1 zeigt den Fluss der Audiodaten vom Mischpult über eine BroadcastSoftware bis zum Streaming Server im Internet.
Abbildung 1:Datenfluss bei Internetradios Auf diese Weise bieten auch immer mehr konventionelle Radiostationen ihre Sendungen parallel zum normalen Sendebetrieb an. Auf der Suche nach einem Internetradio mit einem bestimmten Format gibt es verschiedenste Möglichkeiten. Der traditionelle Ansatz über Suchmaschinen ist ebenso möglich wie das 2
http://www.amazon.com
Seite 4
Verwenden von Radio-Linksammlungen wie sie bei neuen Browsern und Playern meist dabei sind. Der große Nachteil ist allerdings, dass der Name bzw. der Suchmaschineneintrag relativ wenig aussagt. Eine bessere Alternative sind Übersichts- oder Portalseiten, wo Radios von den Betreibern selbst eingetragen werden können (siehe Tabelle 1). Diese „dynamische Linksammlungen“ bieten neben Titel und Hyperlink jede Menge zusätzlicher Informationen an, beispielsweise Stil und aktuelle Hörerzahl, wie lange man bereits „on air“ ist, benötigte Bandbreite und Übertragungsformat etc. Bei vielen derartigen Seiten hat der Hörer die Möglichkeit, die einzelnen Links nach ihrer Qualität zu bewerten. Name Live365 (http://www.live365.com)
Kommentar Beim Wählen der Station kann gleich eine Bewertung abgegeben werden; Möglichkeit direkt das gespielte Lied auf CD kaufen Shoutcast (von Nullsoft) Anzeige von aktuellem Titel, Anzahl der Hörer, (http://www.shoutcast.com) Genre und der Bitrate. Real Guide – Radio Tuner Von RealNetworks betrieben; zwischen 2500 http://realguide.real.com/tuner Sendern kann gewählt werden Radio Station Guide (von Microsoft) Auswahl der Stilrichtungen, Unterscheidung zw. (http://windowsmedia.com/radio/radio.asp) US- und internationalen Stationen Sunset Radio Links zu Radiostationen in aller Welt (http://www.sunsetradio.com) IceCast Hörerzahl, durchschnittliche Hörzeit, Format (http://yp.icecast.org) des Radios Tabelle 1: Portalseiten für Live-Radios
2.2 Video-Streaming Der Real-Player G2 eignet sich nicht nur zum Abspielen von Musik sondern er ermöglicht auch das Betrachten von Echtzeitvideos im Real-Video Format. Die zwei wichtigsten Konkurrenzprodukte sind MS-Media von Microsoft und Quicktime von Apple. Die Bildqualität ist bei allen Formaten aufgrund der großen benötigten Bandbreite noch relativ schlecht, es existieren trotzdem schon viele Internetseiten, die das neue Medium verwenden. Viele Anbieter stellen bereits Nachrichten, Berichte oder Filmausschnitte als gestreamte Videoclips auf ihre Webserver. Videotelefone und Videokonferenzen fallen in eine andere Kategorie möglicher Anwendungen. Internet Learning, eine neue Form des verteilten Lernen über Internet, gewinnt immer mehr an Bedeutung und verwendet auch Streaming-Techniken [SVIDEO]. Am 1. Jänner 2000 fand auf der Homepage der Stadt Graz3 eine Österreich-Premiere statt: Es wurde erstmals eine Hochzeit live ins Internet übertragen, der Server war aber aufgrund Tausender Zugriffe relativ bald überlastet. Das Bandbreitenproblem stellt für die meisten Anbieter momentan noch die größte Schwierigkeit dar, denn bei einer Anbindung über Telekabel oder ADSL können nicht einmal zehn Clients gleichzeitig bedient werden. ADSL ermöglicht Übertragungsraten bis zu 6MBps über herkömmliche Telefonleitungen, die Upload-Bandbreite ist aber in Österreich auf 64kBps beschränkt.
3
http://www.graz.at
Seite 5
Das Projekt „Big Brother4“ des Fernsehsenders RTL II, das Anfang des Jahres 2000 im deutschsprachigen Raum für großes Aufsehen sorgte, ist ein weiterer Anwendungsfall für Video-Streaming. 10 Personen leben in einem gemeinsamen Haushalt und werden rund um die Uhr gefilmt, teilweise sogar von Infrarotkameras. Die Bilder werden über Real-Video live ins Internet übertragen und täglich als Zusammenfassung im Fernsehen gezeigt. Die Zuschauer im Netz haben dabei den Vorteil, zwischen verschiedenen Perspektiven wählen zu können. Ein Beispiel für „Fernsehen im Internet“ findet man bei WebFreeTV5. Die Wiener „Multimedia Dienstleistungs AG“ publiziert Amateur-Videos verschiedenster Kategorien auf ihrer Homepage und stellt sie jedermann kostenlos per MS-Media Live-Stream zur Verfügung. Der Internetsender TV1.de6, betrieben von der gleichnamigen deutschen Firma, versorgt Surfer mit aktuellen Nachrichten aus verschiedensten Themenkreisen. Die Beiträge aus den Bereichen Politik, Wirtschaft, Internet, Sport, etc. sind in den drei gängigen Formaten Real-Video, MS-Media und Quicktime verfügbar.
4
http://www.bigbrother-haus.de http://www.webfreetv.com 6 http://www.tv1.de 5
Seite 6
3 Österreichische Internetradios Das vorliegende Kapitel untersucht die Verbreitung von Internetradios in Österreich und zeigt welche Chancen sich durch das neue Medium ergeben. Der 15 Jährige Harry Just macht im Sommer 1999 sein Hobby „Webradio“ zum Beruf. Er stellt dem Geschäftsführer von Lion.CC das Projekt vor und gemeinsam entsteht daraus XXL Radio7. Der Sender sorgt dank 14 DJs rund um die Uhr für musikalische Unterhaltung und ist derzeit das größte Internetradio Österreichs. Für die Übertragung wird das kostenlose MP3Streaming verwendet, auf das in Kapitel 7 noch genau eingegangen wird [RADIOS]. XXL Radio war aber nicht die erste Radiostation, die abseits von Real-Audio neue Wege beschritt. Im März 1999 wird dem Grazer Jugendsender Radio MPV8, der fünf Stunden pro Woche auf den Frequenzen der Antenne Steiermark sendet, die Sendeerlaubnis widerrechtlich verweigert. Während der Zeit bis zum Abschluss der Gerichtsverfahren wird das Programm im Internet weiter ausgestrahlt. Ein ähnliches Schicksal ereilt etwa zeitgleich den regierungskritischen jugoslawischen Radiosender B2-929. Während des Kosovo-Krieges wurde den Betreibern von der Belgrader Regierung die (terrestrische) Sendelizenz entzogen. Als Reaktion auf die Sanktionen sendet man im Internet weiter, diesmal unzensiert und weltweit empfangbar. Auf der Suche nach österreichischen Internetradios wird man relativ bald fündig, bei genauerer Betrachtung stellt sich allerdings heraus, dass es sich meist um traditionelle Radiostationen handelt, die Beiträge und Musik zusätzlich als Audio-Stream anbieten. Betreiber, die rund um die Uhr nur im Internet senden, sind selten, weil es sehr schwer bis unmöglich ist, Werbeeinschaltungen zu verkaufen und damit etwas zu verdienen. Es bedarf zwar keiner besonderen Ausgaben für die Technik aber um ein Vollprogramm bieten zu können, müssen genauso Moderatoren und DJs angestellt und bezahlt werden. Tabelle 2 listet einige in Österreich produzierte Web-Radios auf, der Großteil davon ist allerdings auch ohne Computer zu hören. Gesondert erwähnt seien „AIR“, das erste Internetradio einer Universität und „Just-4-Fun“, das von Ing. Andreas Holy betrieben, nur Musik aus Österreich bringt und 24 Stunden live sendet.
7
http://xxlradio.lion.cc http://www.radio-mpv.com 9 http://broadcast.freeb92.net 8
Seite 7
Radiostation 92.9 RTL Wien (http://www.929rtlwien.at)
Kommentar Sendet zusätzlich auf Frequenzen in Wien und Umgebung.
Air – Abele Internet Radio (http://air.wu-wien.ac.at)
Radiostation der WU-Wien. Erstes Nachrichten, universitäres Internetradio Österreichs. Berichte und Reportagen Internationales Radio der Radio für österreichischen Regierung Auslandsösterreicher Privatradio aus Salzburg Schlager und Oldies Wiener Privatradio Hitradio
RA
Freies Linzer Stadtradio
Beiträge und Musik Hitradio
RA
Jugendradio
MP
Beiträge und Musik Hitradio
RA
Schülerradio
MP
Radio Austria International (http://roi.orf.at) Radio Arabella (http://www.arabella.at) Radio Energy (http://www.energy.at) Radio FRO (http://www.fro.at) Radio W4 (http://www.radiow4.at) Radio MPV (http://www.radio-mpv.com) Orange 94.0 (http://www.orange.or.at) XXLarge Radio Austria (http://www.xxlradio.at) Bulme – Radio (http://srb.bulme.at) Just-4-Fun (http://www.just4-fun.at)
Regionalradio aus dem Waldviertel (Niederösterreich) Sonntags zwischen 20 und 1 Uhr auf den Frequenzen der Antenne Steiermark und im Internet Freies, nicht kommerzielles Radio in Wien Reines Internetradio, betrieben von Libro Online Nur zu bestimmten Zeiten hörbares Radio der Bulme10 Graz Reines Internetradio von Ing. Andreas Holy.
Stil, Format Hitradio
Typ MS
RA RA RA
RA
MP
Österreichische MP Musik
RA … Real Audio, MS … Microsoft Audio, MP … MP3-Streaming
Tabelle 2: Österreichische Radios im Internet
Neben Kosten für die benötigte Infrastruktur fallen weitere Abgaben an, wenn man nicht mit dem österreichischen Recht in Konflikt kommen will. Im nächsten Kapitel wird geschildert, was noch beachtet werden muss, wenn man beispielsweise die eigenen Lieblingsplatten im Internet auflegen möchte.
10
Höhere Technische Bundes- Lehr- und Versuchsanstalt
Seite 8
4 Die rechtliche Situation in Österreich Im folgenden soll näher auf die rechtlichen Vorgaben für den Betrieb eines Internetradios in Österreich eingegangen werden. Zum Zeitpunkt der Recherche (Mai 2000), hat es sich als schwierig erwiesen, kompetente Auskünfte zu diesem Thema zu erhalten, da es sich bei den Internetradios um ein relativ junges Medium handelt. Der erste und wohl bekannteste Ansprechpartner wenn es um die öffentliche Aufführung von Musik, ob im Internet oder bei einer terrestrisch Radiostation, geht, ist die AKM, die Vereinigung der Autoren, Komponisten und Musikverleger. Internetradios und Radios generell fallen aber nicht in den alleinigen Zuständigkeitsbereich der AKM, es gibt vielmehr noch zwei weitere Rechte, die zur Anwendung kommen. Einerseits das Recht der mechanischen Vervielfältigung, das von der Austro Mechana vertreten wird und andererseits die Leistungsschutzrechte, die neuerdings von den einzelnen Plattenfirmen selbst geltend gemacht werden.
4.1 Die AKM Die AKM ist eine Interessengemeinschaft zur Wahrung urheberrechtlichen Nutzungsrechte der öffentlichen Aufführung und Sendung in Österreich. Damit diese Rechte auch im Ausland gewahrt bleiben, gibt es mit über 60 Schwestergesellschaften überall auf der Welt Gegenseitigkeitsverträge. Sobald man Musik kommerziell hörbar macht, muss man Tantiemen an die AKM abliefern. Im konkreten Fall eines Internetradios heißt das, wenn man Werbeeinschaltungen bringt, müssen Beiträge gezahlt werden. Die Höhe richtet sich nach dem Musikanteil des Radios und der durchschnittlichen Höreranzahl, der genaue Betrag wird von der AKM individuell berechnet. Unter der Voraussetzung eines 100%igen Musikanteiles wird ein Basissatz von 8 % der Bruttoerlöse angenommen. Eine durchschnittliche Radiostation hat einen Musikanteil von etwa 70 %, in diesem Fall ergibt sich ein Betrag von 5,6 % der Erlöse, der an die AKM abgeführt werden muss. Viele Firmen machen mit Internetradios keine oder nur sehr kleine Gewinne, daher schreibt die AKM einen Mindestbetrag vor, der gezahlt werden muss. Dieser Betrag richtet sich nach der durchschnittlichen Hörerzahl. Für weniger als 1.000 Zuhörer müssen monatlich mindestens 1.000 ATS entrichtet werden, liegt die Zahl der Hörer zwischen 1.000 und 10.000 so sind mindestens 5.000 ATS fällig und Radios mit über 10.000 Hörern pro Monat bekommen von der AKM eine individuelle Vorschreibung. Der Großteil der Firmen, die einen Radiosender im Internet betreiben, lässt nicht einen eigenen Streaming Server aufstellen, sondern mietet bei einem Provider die benötigten Ressourcen. Die meisten dieser Server stehen im Ausland, daher könnte man schnell auf die Idee kommen, dass das österreichische Recht dafür nicht zuständig ist. Der Zuständigkeitsbereich richtet sich jedoch nicht nach dem Serverstandort sondern nach dem Sitz der Firma. Zur europaweiten Klärung dieser Frage wird derzeit ein EU-Gesetz vorbereitet.
Seite 9
4.2 Die Austro Mechana Als zweites Recht beim Betrieb eines Radiosenders im Internet stößt man auf das Recht der mechanischen Vervielfältigung, das in Österreich durch die Austro Mechana vertreten wird. Unter dem Begriff „Mechanische Vervielfältigung“ versteht man traditionellerweise das Pressen von CDs, neuerdings fällt darunter auch das Speichern auf Datenträgern oder das Bereitstellen auf Servern. Handelt es sich bei der Radiostation um ein reines Internetradio, das heißt das Programm wird nicht gleichzeitig über einen Sender ausgestrahlt, dann spricht man von Web-Casting. Bei regulären Sendern muss ein Liste der ausgestrahlten Musiktitel abgegeben werden und daraus berechnet sich die Höhe der Lizenzgebühren. Im Falle eines Web-Casting wäre dieser Berechnungsmodus auch denkbar, momentan wird aber noch der Umsatz des Internetradios als Basis herangezogen. Pro Monat müssen 1,5 % des Umsatzes an die Austro Mechana abgeführt werden, mindestens aber 1.000 ATS. Bietet ein terrestrischer Radiosender sein Programm zusätzlich auch im Internet an, so fallen keine weiteren Abgaben an die Austro Mechana an, da ohnehin schon für den normalen Radiobetrieb Lizenzgebühren gezahlt werden. Ein Beispiel dafür ist die Antenne Steiermark, die ihr Programm zusätzlich zu den normalen Radiofrequenzen auch im Internet anbietet.
4.3 Die Plattenfirmen Neben der Zahlung von Tantiemen an AKM und Austro Mechana bedarf es in letzter Zeit noch der Zustimmung der einzelnen Plattenfirmen, wenn man lizenzierte Musikstücke spielen will, sowohl im Internet als auch bei normalen Radiostationen. Bis vor kurzem wurden diese „Leistungsschutzrechte“ durch die Gesellschaft zur Wahrnehmung von Leistungsschutzrechten (LSG) vertreten, über die alle Formalitäten abgewickelt werden konnten. Diese Rechte werden neuerdings von den Plattenlabels selbst vertreten und es gibt noch keine einheitlichen Vereinbarungen auf diesem Gebiet. Momentan müsste man mit jedem Plattenlabel einen eigenen Vertrag abschließen und gegebenenfalls direkt dorthin Lizenzgebühren zahlen, wenn man einen lizenzierten Titel im Programm hat. Der Austro Mechana ist zu dieser Thematik ein konkreter Fall bekannt, bei dem ein Internetradio alle Platten eines bestimmten Labels nicht spielen durfte, da kein gültiger Vertrag vorhanden war. Die folgenden Abschnitte beschäftigen sich mit den Techniken und Protokollen, die zur Bereitstellung von Streaming-Daten im Internet benötigt werden. Kapitel 5 gibt einen Überblick über die technischen Grundlagen und Kapitel 6 geht genauer auf das Realtime Streaming Protokoll (RTSP) ein.
Seite 10
5 Technische Grundlagen Die Übertragung von Audio- und Videodaten in Echtzeit setzt ausgefeilte Mechanismen voraus. Am Beginn der Entwicklung von Realtime Streaming erarbeitete jede Firma ihre eigene Technik und es bildeten sich verschiedene Standards heraus. Diese Ansätze waren zwar weitgehend identisch doch die Protokolle waren nicht kompatibel, daher versuchten die wichtigsten Firmen in Zusammenarbeit mit Standardisierungsgremien einen Vereinheitlichung zu erreichen. Man einigte sich schließlich auf vier zentrale Standards, die in Zukunft die Entwicklungen auf dem Gebiet des Realtime Streaming regulieren sollen [SVIDEO].
5.1 Vier Standards •= Das Realtime Transport Protocol (RTP) sorgt für den Transport der Audio- und Videodaten. Das Protokoll besteht aus einem Datenteil und einem Kontrollteil (RTCP). RTP benutzt Timestamps und Sequenznummern für die übertragenen Pakete und korrigiert den Stream des Empfängers, damit dieser die Daten in der richtigen Reihenfolge erhält. Eine weitere Aufgabe von RTP ist die Synchronisation der unterschiedlichen Daten (Audio-, Video- und weitere Informationsdaten) [RTP]. •= Das zweite Protokoll, das zum Standard erklärt wurde, nennt sich Reservation Protocol (RSVP) und dient zur Bereitstellung der benötigten Netzwerkressourcen für den Datenstrom. Der Empfänger erhält damit die Möglichkeit eine bestimmte Bandbreite für die Echtzeitdaten zu reservieren, um zum Beispiel die Qualität eines Videos konstant zu halten. Diese Reservierung wird von allen betroffenen Routern und vom Sender vorgenommen [RSVP]. •= Die Synchronized Multimedia Integration Language (SMIL) dient für die Beschreibung und Formatierung von Streams. Die Sprache basiert auf XML und ermöglicht eine textgesteuerte Synchronisation von Multimedia Anwendungen, deren Erscheinungsweise und die Verwendung von Hyperlinks. Durch SMIL können beispielsweise in eine Präsentation zu genau definierten Zeitpunkten Bilder eingeblendet oder Musikdateien abgespielt werden [SMIL]. •= Der vierte Standard ist das Realtime Streaming Protokoll (RTSP). RTSP steuert den Datenstrom und wurde für die effiziente Übertragung von Multimedia Streams über IPStreams entwickelt. Syntax und Funktionsweise von RTSP sind stark an HTTP angelehnt, und werden in Kapitel 4 genauer untersucht [RTSP].
5.2 Der Datenfluss Am Anfang eines Produktionsablaufes für Echtzeit-Streams, wie er in Abbildung 2 dargestellt ist, steht aber nicht die Übertragung und die verwendeten Protokolle, sondern die unbehandelten Audio- und Videodaten. Diese Datenmengen müssen vor der Bereitstellung im Internet, mit Hilfe sogenannter Codecs komprimiert werden. Erst nach der Komprimierung werden die Daten auf einen Web- oder Mediaserver übertragen, dort werden die StreamingFiles entweder dauerhaft gespeichert (zB. Videos, die jederzeit abrufbar sind) oder nur gepuffert und sofort an die Clients weiterverteilt, wie es beispielsweise bei LiveÜbertragungen der Fall ist. Der Empfänger muss die kodierten Daten vom Server mit dem Seite 11
richtigen Codec dekomprimieren und stellt sie anschließend dar bzw. gibt sie über die Soundkarte aus. Die Komprimierungsverfahren der einzelnen Hersteller sind nicht kompatibel, daher muss für jeden Anbieter ein eigenes Browser Plugin oder ein entsprechender Player installiert werden.
Abbildung 2: Datenfluss bei Realtime Anwendungen Es ist theoretisch auch denkbar, dass der Client den Stream nicht nur abspielt sondern die entsprechenden Audio- und Videodaten auch auf der Festplatte speichert. Dieses Feature ist aber aus Gründen des Copyrights bei keiner kommerziellen Software eingebaut. Bei AudioStreaming besteht die einzige Möglichkeit darin, die Daten mit Hilfe der Soundkarte analog aufzuzeichnen. WinAmp11 bietet die Möglichkeit zwar an, bricht aber auch mit einer „Copyright-Fehlermeldung“ ab, nur der Open-Source Player FreeAmp12 schafft es, den Stream als MP3-File auf der Festplatte abzulegen.
5.3 Proxies und Firewalls Eine Firewall ist ein Computer mit einer entsprechenden Software, der zwei Gruppen von Clients trennt. Computer innerhalb der Firewall sollen von Zugriffen von außerhalb geschützt werden. Es gibt viele Ansätze, die meist in Kombination verwendet werden, um diesen Schutz zu gewährleisten. Ein Mechanismus, der fast immer Anwendung findet ist das Sperren bestimmter Ports. Es kann beispielsweise nur HTTP, E-Mail und FTP erlaubt sein und alle Daten, die auf anderen Ports ankommen, lässt die Firewall nicht durch. Die Media- und Webserver bieten die Realtime Streams auf verschiedenen Ports an, es ist auch denkbar, dass der Client je nach Auslastung auf ein anderes Port oder gar einen anderen Server umgeleitet wird. Durch diese Arbeitsweise kommt es für Anwender die sich hinter Firewalls befinden, zu Problemen, weil die betreffenden Ports fast immer gesperrt sind. Eine Möglichkeit dieses Problem zu lösen, bieten Proxy-Server. Das sind Rechner, die ähnlich einer Firewall, zwischen den Clients und den Servern im Internet installiert sind und deren Hauptaufgabe das Cachen von Daten ist. Der bekannteste Anwendungsfall sind HTTPProxies zum Zwischenspeichern von Webseiten, aber auch für alle Streaming-Daten, die sich an das RTSP-Protokoll halten, sind Proxy-Server verfügbar.
11 12
http://www.winamp.com http://www.freeamp.org
Seite 12
Die Firma RealNetworks bietet für Real-Audio und Video einen derartigen Cache-Server an, der sowohl Live-Streams als auch „On Demand“-Daten unterstützt [REALPROXY]: •= Bei Live-Streams (siehe Abbildung 3) fordert der Benutzer im ersten Schritt die Daten vom RealProxy an. Dieser kontaktiert den Streaming-Server und führt eine Authentifizierung durch. In zweiten Schritt wird der Stream vom Server zum RealProxy und dann zum Client übertragen. Möchte ein zweiter Anwender auf den gleichen LiveStream zugreifen, dann werden die Daten direkt vom RealProxy zur Verfügung gestellt.
Abbildung 3: RealProxy bei Live Streams •= Bei Daten die “on demand”, das heißt auf Wunsch des Anwenders, übertragen werden, funktioniert die Vorgehensweise ähnlich (siehe Abbildung 4). Die Anforderung und Authentifizierung im ersten Schritt und läuft gleich wie bei Live-Streams ab. Anschließend werden die Daten zum Client übertragen und gleichzeitig im Cache des RealProxy abgelegt. Bei einem gleichen Request von einem anderen Benutzer werden die Daten direkt vom Cache zum Client übertragen (Schritt 3), Voraussetzung dafür ist allerdings deren Aktualität.
Abbildung 4: RealProxy bei “On Demand“-Streams
Seite 13
Durch Installation eines Proxy-Servers auf einer Firewall gelangen nur Echtzeitdaten in das interne Netz und es entstehen keine Sicherheitslöcher. Möchte man aber an der Konfiguration der Firewall nichts ändern, bietet HTTP-Tunneling eine Alternative. Unter Tunneling versteht man prinzipiell die Übertragung von Daten eines Netzwerks A über eine Netzwerkverbindung B. Zu diesem Zweck wird das Protokoll von A in Pakete von B verpackt und übertragen. Viele Firewalls sind so eingestellt, dass nur das HTTP-Protokoll auf Port 80 erlaubt ist und keine anderen Daten, zB. Realtime Streams, empfangen werden können. HTTP-Tunnelung löst dieses Problem indem Anforderungen an einen Media-Server in HTTP-Requests umgewandelt und an CGI-Scripts oder andere serverseitige Programme geschickt werden. Diese installierten Gateway-Programme kontaktieren den Streaming-Server und übertragen die erhaltenen Daten als HTTP-Response auf dem gleichen Weg wieder zum Client. Der Player bzw. das Browser-Plugin macht daraus einen Stream und stellt ihn dar bzw. spielt ihn ab. Die zwischengeschaltete Firewall kann nicht zwischen den getunnelten Streams und normalen Webseiten unterscheiden und lässt die Daten passieren.
Seite 14
6 Das RTSP Protokoll Das Realtime Streaming Protokoll wird in RFC 2326 spezifiziert und ist das wichtigste Protokoll für die Übertragung von Echtzeitdaten. RTSP wurde 1996 beim IETF, der internationalen Vereinigung für die Entwicklung des Internets, eingereicht und ist seit April 1998 empfohlener Standard für die Kontrolle von Streaming Medien im Internet. Maßgeblich an der Entwicklung beteiligt waren RealNetworks, Netscape und über 40 führende Firmen aus der Medienbranche [REALRTSP]. Die Autoren des RFC sind Henning Schulzrinne vom Institut für Computerwissenschaften der Universität Columbia, Anup Rao von Netscape und Robert Lanphier von RealNetworks. Diese folgenden Abschnitte beziehen sich ausschließlich auf das RFC 2326 [RTSP]. RTSP wurde entwickelt zur Kontrolle von einem oder mehreren zeitsynchronisierten Streams, die zwei typischen Anwendungsfälle sind Audio und Video. Die Übertragung der Daten erfolgt typischerweise getrennt von den Kontrollsequenzen, RTSP unterstützt aber auch Interleaving, das heißt Echtzeitdaten und Kontrollinformationen werden in einen gemeinsamen Stream gepackt. Für die Übertragung der Daten kann RTP (siehe Kapitel 5.1) verwendet werden, RTSP ist aber nicht an diesen Transportmechanismus gebunden. Die grundlegenden Funktionen sind Abspielen und Aufnehmen, sowie die Möglichkeit, an einer existierenden Konferenz teilzunehmen. Beim Empfangen von Streams erhält der Client im ersten Schritt die Beschreibung der Präsentation über HTTP oder einen anderen Weg, beispielsweise per E-Mail. Die Beschreibung enthält zumindest eine Präsentation mit der entsprechenden Adresse des Media Servers, die Kodierung des Streams, Sprache, etc. Beim Empfangen von Streams unterschiedet man zwischen drei verschiedenen Modi: •= Unicast: Es bezieht nur ein Client Daten, dieser muss dem Server vor Beginn der Übertragung seine IP-Adresse und das entsprechende Port bekannt geben. •= Multicast, Server wählt Adresse: Dieser Fall ist typisch bei Live Präsentationen, wo viele Benutzer gleichzeitig Streams empfangen. •= Multicast, Client wählt Adresse: Dieser Modus findet bei Videokonferenzen seine Anwendung.
6.1 Eigenschaften Die Syntax des Protokolls ist an HTTP/1.1 [HTTP] angelehnt, es gibt aber doch einige wichtige Unterschiede: •= Ein RTSP Server benötigt immer einen aktuellen Status, zum Beispiel ob der Stream gerade abgespielt wird oder ob Daten aufgezeichnet werden. •= Bei HTTP kann nur der Client Requests abschicken, bei RTSP muss auch der umgekehrte Weg möglich sein, beispielsweise wenn der Server dem Client eine neue Adresse bekannt geben will. •= Die Daten werden „out-of-band“ von einem anderen Protokoll übertragen, einzige Ausnahme bildet das Interleaving. Das RTSP Protokoll lässt sich sehr leicht um neue Methoden und Parameter erweitern, denn es handelt sich wie bei HTTP um ein textbasiertes Format, das mit Standardparsern sehr leicht verarbeitet werden kann. Ein großes Augenmerk wurde von den Entwicklern auf die Seite 15
Sicherheit gelegt, zu diesem Zweck wurden die Authentifizierungsmechanismen von HTTP eins zu eins implementiert. RTSP ist unabhängig von der Transport Schicht, es unterstützt sowohl UDP [UDP] für große Datenmengen als auch RDP [RDP] und TCP [TCP] für die zuverlässige Übertragung von Daten. Es ist oft der Fall, dass die Kontrolle über das zuverlässige TCP läuft und die Datenverbindung UDP verwendet, weil dort Bandbreite wichtiger ist als Datensicherheit. Eine weitere wichtige Eigenschaft ist die gleichzeitige Verwendung verschiedener Media Server, es ist möglich jeden Stream von einem eigenen Server zu beziehen.
6.2 Protokollparameter Der wichtigste Parameter im RTSP Protokoll ist die URL zur Angabe der Datenquelle(n). Der Aufbau ist hierarchisch und ähnelt einer normalen HTTP URL wie sie von Webseiten bekannt ist. Als Protokollpräfix werden „rtsp“ für verbindungsorientierte (zB. TCP) und „rtspu“ für verbindungslose (zB. UDP) Connections angeboten. Der Standardport ist 554, es kann aber auch jeder andere Port angegeben werden. Die URL „rtsp://my_movie.at:554/matrix/audio” bezeichnet beispielsweise nur den Audiotrack des Films „The Matrix”, während „rtsp://my_movie.at:554/matrix“ Audio- und Videodaten gemeinsam zurückliefert, falls die Verzeichnisse auf dem Server dementsprechend angelegt sind. „SMPTE Realtive Timestamps“ dienen der Zeitangabe in Streams und können im Protokoll auch als Parameter mitgegeben werden. SMPTE steht dabei für „Society of Motion Picture and Television Engineers“ und bezeichnet eine Vereinigung, die sich mit der Entwicklung von Standards betreffend Video und Fernsehen beschäftigt. Diese Timestamps geben die Zeit an, die seit Beginn des Clips vergangen ist, die Angabe erfolgt in „Stunden:Minuten:Sekunden:Frames.Subframes“. Es gibt verschiedene Möglichkeiten Timestamps zu verwenden, man kann Beginnzeiten und Abspielbereiche festlegen, die Framerate in Videos angeben, etc. Der Parameter „smpte-25=10:07:0010:07:33:05“ definiert zum Beispiel einen Bereich beginnend bei 10 Stunden und 7 Minuten mit einer Länge von 33 Sekunden und 5 Frames. Die Framerate beträgt 25 Frames pro Sekunde. Ein ähnlicher Parameter findet sich in der „Normal Play Time“ (NPT), er gibt die aktuelle Position in einem Stream an. Die Zeit wird in „Stunden:Minuten:Sekunden.Hundertstel“ oder in „Sekunden.Hundertstel“, wieder betrachtet vom Beginn des Streams, angegeben. Die „Absolut Time“ stellt einen weiteren Zeitparameter dar der die Angabe eines absoluten Zeitpunkts in Form von Datum und Zeit ermöglicht. Dieser Parameter wird im UTC-Format dargestellt, das weltweit überall gleich definiert ist und beispielsweise für die Navigation von Schiffen und Flugzeugen verwendet wird. Der 8. November 1996, 14:37 Uhr, 20 Sekunden und 25 Hundertstel wird beispielsweise als „19961108T143720.25Z“ geschrieben. Als letzte beiden Parameter dieser kurzen Auflistung seien noch „Conference Identifier“ und „Session Identifier“ erwähnt. Sie dienen zur eindeutigen Kennzeichnung von Konferenzen bzw. Sessions. Auf das genaue Format soll hier nicht näher eingegangen werden.
6.3 Datenaustausch Bei RTSP haben Client und Server die Möglichkeit „Request-Messages“ an den jeweils anderen Teilnehmer zu schicken, Voraussetzung für das Schicken von Requests zum Client ist allerdings eine persistente Transportverbindung. In der ersten Zeile dieser Nachricht müssen zumindest die auszuführende Methode, der Identifier der Ressource und die Seite 16
verwendete Protokollversion angegeben werden. RTSP benötigt außerdem bei jedem Request eine „Sequence Number“ im Abschnitt „CSeq“. Diese Nummer wird bei jeder erfolgreichen Message automatisch erhöht und ermöglicht so die Erkennung und Synchronisation von Übertragungsfehlern, speziell bei verbindungslosen Protokollen. Es gibt eine Vielzahl weiterer Parameter, einige wichtige werden in den Beispielen von Kaptitel 4.4 verwendet, für eine genaue Auflistung sei aber auf RFC 2326 verwiesen. Ein minimaler Play-Request an den Server „videoserver.at“ unter Verwendung der Version 1.0 könnte wie folgt aussehen: PLAY rtsp://videoserver.at/public/klassentreffen.rm RTSP/1.0 Als Reaktion auf einen Request muss der entsprechende Gegenpart mit einer „Response Message“ antworten, außer es handelt sich um Empfänger eines Multicast Streams. Diese Nachricht beinhaltet immer eine Statuszeile bestehend aus Protokollversion, Statuscode und der entsprechenden Statusmeldung als Text. Es besteht daneben die Möglichkeit sogenannte „Response Header Fields“ mit zusätzlichen Informationen mitzuschicken, beispielsweise eine Timeout. Schickt der Client innerhalb dieser Zeit kein RTSP Kommando, dann beendet der Server die Verbindung. Die Statuscodes lassen sich in fünf Klassen einteilen: •= 1xx: Rein informell - Der Request wurde erhalten und der Prozess wird normal forgesetzt •= 2xx: Request wurde erfolgreich ausgeführt (zB. 200 OK) •= 3xx: Redirection - Es müssen weitere Aktionen unternommen werden, damit der Request erfolgreich beendet wird (zB. 302 Moved Temporarily) •= 4xx: Fehler beim Client – Die Syntax ist falsch oder der Request kann nicht durchgeführt werden (zB. 404 Not Found, 408 Request Timeout ) •= 5xx: Fehler beim Server – Der Request war zwar korrekt, aber der Server konnte ihn nicht ausführen (zB. 503 Service Unavailable) Die folgende Nachricht erhält man beispielsweise nach jedem erfolgreichen Request: RTSP/1.0 200 OK
6.4 Beispiele Im vorliegenden Abschnitt werden die wichtigsten Methoden vorgestellt, die bei der Übertragung von Realtime Streams benötigt werden. Das offene RTSP-Protokoll ermöglicht es beliebige neue Methoden einzuführen, aber die implementierten Streaming Server und Clients sollten zumindest die folgenden Messages richtig verstehen und behandeln um mit Standardprogrammen kompatibel zu sein. Zu Beginn jeder Session muss der Client einen Setup-Request an den Server schicken, dieser generiert einen „Session Identifier“ und sendet ihn in der Response-Message zurück: C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port=4588-4589 S->C: RTSP/1.0 200 OK CSeq: 302 Date: 23 Jan 1997 15:35:06 GMT Seite 17
Session: 47112344 Transport: RTP/AVP;unicast; client_port=4588-4589;server_port=6256-6257 Im Anschluss an ein erfolgreiches Setup kann bereits der Stream abgespielt bzw. aufgezeichnet werden. Neben den entsprechenden „Play“ und „Record“ Methoden ist es auch sinnvoll, eine Funktion „Pause“ zum Anhalten der Übertragung zu implementieren. Folgendes Beispiel startet die Wiedergabe des ganzen Films „Twister“ um 15:36 am 23. Jänner 2001 und zeigt ihn zur Gänze: C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 CSeq: 833 Session: 12345678 Range: smpte=0:10:20-;time=20010123T153600Z S->C: RTSP/1.0 200 OK CSeq: 833 Date: 23 Jan 2001 15:35:06 GMT Range: smpte=0:10:22-;time=20010123T153600Z Zum Beenden sollte man den Request “Teardown” verwenden. „Teardown“ stoppt den Stream und gibt alle Ressourcen wieder frei, damit werden alle beteiligten Session Identifier ungültig. C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 892 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 892 Als letzte Methode sei an dieser Stelle noch das „Redirect“ erwähnt. Dieser Request fordert den Client auf, die Daten von einem anderen Server zu beziehen. Erhält ein Client diese Aufforderung, muss die aktuelle Verbindung mit Teardown beendet werden, anschließend wird mit dem neuen Server ein Setup durchgeführt. S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 732 Location: rtsp://bigserver.com:8001 Nach diesen theoretischen Betrachtungen werden im folgenden Kapitel mit Real-Audio und MP3-Streaming zwei konkrete Lösungen vorgestellt, die RTSP verwenden. Die Real-Audio Technologie ist zwar sehr gut verbreitet, bedarf aber hoher Anschaffungskosten. MP3 andererseits ist kostenlos und Open-Source, wird aber von vielen Benutzern noch nicht akzeptiert.
Seite 18
7 Real-Audio contra MP3-Streaming Die Firma RealNetworks bietet kommerzielle Streaming-Server verschiedenster Größenordnungen für die Plattformen Microsoft Windows, Linux und Sun Solaris an. Der markanteste Unterschied neben den Kosten ist die maximale Anzahl der gleichzeitigen Zuhörer bzw. Zuseher. Die kleinste Variante ist der „RealServer Basic“, er bedient höchstens 25 Clients und ist kostenlos auf der Homepage verfügbar, für 60 User zahlt man bereits USD 1.995,- (Stand: Juni 2000). Ein Internetradio zu betreiben, das nur von 60 Hörern gleichzeitig empfangen werden kann, erscheint nicht unbedingt sinnvoll. Professionelle Server-Lösungen von RealNetworks sind aber verhältnismäßig teuer, so kostet beispielsweise der „RealServer Pro“ mit 400 möglichen Streams USD 54.420,- (Stand: Mai 2000). Diese Software ermöglicht Payper-View und Werbeeinblendungen in laufende Sendungen. Die empfohlenen 512 MB an Hauptspeicher fallen bei derartigen Preisen kaum mehr ins Gewicht. In weiterer wichtiger Kostenfaktor bei jeder Streaming-Anwendung ist die benötigte Bandbreite. Überträgt man Musik mit einer Bitrate von 56 kBps und verwendet dafür den kostenlosen RealServer Basic, ergeben sich 1.400 kBps als geforderte Bandbreite bei 25 Benutzern. Der Server benötigt also zumindest eine T1-Anbindung (=1,544 MBps) an das Internet. Für Betreiber von kleinen, möglicherweise rein privaten Internetradios sind die Lösungen von RealNetworks zu teuer, außerdem benötigt man die Video-Streaming Funktionalität nicht, mit der alle Real-Server ausgestattet sind. Als Alternative bietet sich MP3-Streaming an. Die übertragenen MP3-Daten können mit den meisten herkömmlichen Playern, zB. WinAmp oder FreeAmp empfangen werden. Das Open-Source Projekt IceCast13 beschäftigt sich beispielsweise mit der Entwicklung eines MP3 Streaming-Servers. Auf der Webseite werden der vollständige Source-Code und bereits vorkompilierte Versionen für Windows und Linux zum kostenlosen Download angeboten [ICECAST].
Abbildung 5: Verwendung von Relay-Servern für MP3-Streaming
13
http://www.icecast.org
Seite 19
Ein großer Vorteil neben der freien Verfügbarkeit aller benötigten Komponenten ist die Möglichkeit sogenannte Relay-Server einzusetzen. Das Prinzip ist in Abbildung 5 skizziert und gestattet es auch Servern, die keine gute Anbindung an das Internet haben, Live-Radios für Hunderte von Zuhörern anzubieten. Der Streaming-Server mit der langsamen Internetverbindung überträgt seine Live-Daten an die nachfolgenden Relay-Server, diese besitzen eine entsprechend große Bandbreite und bedienen die einzelnen Clients. Das bereits in Kapitel 3 erwähnte Grazer Jugendradio MPV konnte durch Verwendung dieses Systems und durch Einsatz von zwei Relay-Servern einige Hundert Hörer gleichzeitig erreichen, obwohl man im Studio nur einen Telekabelanschluss mit einer Uploadbandbreite von 64kBps zur Verfügung hatte. Das Prinzip ist vergleichbar mit Proxies, nur dass bei dieser Technologie der Upload des Streaming-Servers konstant gleich bleibt. Beim Beispiel in Abbildung 5 werden immer genau zwei Streams an die Relay-Server übertragen und diese werden dann je nach Anzahl der Zuhörer unterschiedlich stark belastet. Ein weiterer Nachteil der Proxy-Server, beispielsweise des „RealProxy“, ist die Art der Lizenzvergabe. Der Proxy fragt bei jeder neuen Anfrage eines Clients den Streaming-Server, ob noch genügend Lizenzen vorhanden sind und gibt erst dann die Daten weiter.
Seite 20
8 Zukunftsperspektiven In dieser Arbeit wurden Projekte vorgestellt, die bereits Streaming-Medien verwenden. Die relativ geringe Bandbreite vieler Endbenutzer und die hohen Kosten für Standleitungen à la Telekabel und ADSL verhindern heute noch den kommerziellen Erfolg derartiger Unternehmungen. Das Streamen von Audiodaten, meist in Form von Internetradios oder Playlists, wird erst in letzter Zeit vermehrt eingesetzt. Dieses neue Medium erlangt langsam auch in Österreich an Bedeutung, obwohl aufgrund der rechtlichen Lage auch dafür Tantiemen und Lizenzgebühren gezahlt werden müssen. Am 27. April 2000 wurden in Köln erstmals die Online Music Awards verliehen. MTV Deutschland und Yahoo vergaben den Preis beispielsweise in der Kategorie „Bester Internetsong“ für einen Titel, der exklusiv im Internet verfügbar ist. Der Event wurde live über Realtime Streaming auf verschiedenen Webseiten übertragen [AWARDS]. Video-Streaming wird weitaus spärlicher eingesetzt, und dort wo es verwendet wird, etwa bei „Big Brother“, sind die Server laufend überlastet. Die mit den heutigen Bandbreiten mögliche Qualität ist auch nicht zufriedenstellend und reicht noch lange nicht für eine unterbrechungsfreie Übertragung von Filmen. Einige Firmen setzen dennoch auf die neue Technologie. Die österreichische Seite WebFreeTV.com ist europaweiter Markleader und bietet Amateurvideos on Demand an [VKINO]. Der deutsche Internetsender TV1.de stellt täglich aktualisierte Nachrichten in Form kurzer Videos zur Verfügung und auf der Homepage Bitfilm.de kann man bereits in ein „BitKino“ gehen. Die gezeigten Filme haben eine durchschnittliche Länge von zehn Minuten und werden teilweise mit „bekannteren“ Schauspielern gedreht, Heike Makatsch gehörte beispielsweise einmal mit zur Besetzung. Forschern der Universitäten Stanford und Washington ist es 1999 erstmals gelungen, Signale des High Definition TV (HDTV) über das Internet-2 zu übertragen. Dieses High-Speed Internet soll irgendwann zum neuen Standard werden und elektronischen Handel und Unterhaltung miteinander verbinden [INTERNET2]. Diese Technik ist zwar Zukunftsmusik aber bereits in den nächsten Jahren wird die geringe Bandbreite auf der „letzten Meile“ durch alternative Anbieter der Vergangenheit angehören und das Empfangen von Radio und Fernsehen am PC wird jedermann vertraut sein.
Seite 21
9 Glossar 1kBps – Übertragungseinheit Entspricht 1024 Bit an übertragenen Daten pro Sekunde.1024kBps entsprechen 1MBps. ADSL – Asymmetric Digital Subscriber Line Bezeichnet die Technolgie zur Übertragung von digitalen Daten großer Bandbreite über herkömmliche (analogen) Telefonleitungen. Die angebotene Downloadbandbreite reicht von 512kBps bis zu 6Mbps. AKM Vereinigung der österreichischen Autoren, Komponisten und Musikverleger. ASF – Active Streaming Format Microsofts Dateiformat für das Übertragen von Audio- und Videostreams. Codec – Compression, Decompression Ein Codec ist ein Algorithmus bzw. Computerprogramm zur Reduktion von Speicherplatz. Zur Kompression von Audio- und Videodaten wird beispielsweise ein Codec verwendet. Firewall Eine Firewall ist typischerweise ein Computer mit einer entsprechenden Software, der zwei Gruppen von Clients trennt. Ein Beispiel ist die Trennung des firmeninternen Intranets von Rechnern im Internet. Verwendung finden Firewalls um Clients in der Firewall vor unberechtigten Zugriffen von außerhalb zu schützen. HTTP-Tunneling Unter Tunneling versteht man prinzipiell die Übertragung von Daten eines Netzwerks A über eine Netzwerkverbindung B. Zu diesem Zweck wird das Protokoll von A in Pakete von B verpackt und übertragen. HTTP-Tunneling bezeichnet den Transport beliebiger Daten über das HTTP-Protokoll. IETF – Internet Engineering Taskforce Die IETF ist eine offene, internationale Vereinigung, die sich mit der Entwicklung des Internets und seiner Architektur beschäftigt. Die Aufgabenbereiche umfassen Routing, Sicherheit, Netzwerkprotokolle, etc. LSG Gesellschaft zur Wahrnehmung von Leistungsschutzrechten. Proxy-Server Proxy-Server sind Rechner, die zwischen den Clients und den Servern im Internet installiert sind und deren Hauptaufgabe das Cachen von Daten ist. Die Daten können unterschiedlichster Art sein, bekanntestes Beispiel ist ein HTTP-Proxy für das Zwischenspeichern von Webseiten. RTP – Realtime Transport Protocol. Dieses Protokoll sorgt für den Transport der Audio- und Videodaten und besteht aus einem Datenteil und einem Kontrollteil (RTCP). Seite 22
RTCP – Realtime Control Protocol Das Protokoll zur Kontrolle der Daten bei Realtime Streaming. RTSP – Realtime Streaming Protokoll Das RTSP steuert den Datenstrom bei der Übertragung von Multimedia Streams. SMPTE - Society of Motion Picture and Television Engineers Eine Vereinigung, die sich mit der Entwicklung von Standards für Fernsehen und Video beschäftigt. XML – Extensible Markup Language XML ist ein standardisiertes Datenformat zum Austausch von Dokumenten. Das Format ähnelt HTML.
Seite 23
10 Bibliographie [AWARDS] Musik im Internet wird ausgezeichnet. Sound & Media 6/2000, Seite 13. Online Music Awards verliehen. Sound & Media 8/2000, Seite 14. http://www.onlinemusicawards.de [DARWIN] http://www.publicsource.apple.com/projects/streaming/ [HTTP] Fielding, et. al. Hypertext Transfer Protocol - HTTP/1.1. RFC 2068, Januar 1997. ftp://ftp.univie.ac.at/netinfo/rfc/rfc2068.txt [ICECAST] IceCast.ORG – Open Source Streaming Audio. http://www.icecast.org Gegründet im Jänner 1999 von Jack Moffitt und Barath Raghavan. [INTERNET2] HDTV über Internet-2. Media Biz 11/99. Producer Zeitschriftenverlag. [MSAUDIO] Matthias Carstens, Alexander Oberdörster. Frontalangriff. Internet-Audio und Video: Microsoft contra Apple und MP3. c’t Nummer 10 (1999), Seite 52 – 57. Heise Verlag. [RADIOS] Lukas Wieselberg. Weltempfänger im Internet. TV-Media Nummer 12 (2000), Seite 162 – 165. Verlagsgruppe NEWS Gesellschaft mbH. [RDP] Craig Partridge, Robert Hinden. Version 2 of the Reliable Data Protocol (RDP). RFC 1151, April 1990. ftp://ftp.univie.ac.at/netinfo/rfc/rfc1151.txt [REALRTSP] http://www.realnetworks.com/devzone/library/rtsp/index.html [REALPROXY] http://www.realnetworks.com/products/proxy/datasheet.html?src=proxy [RSVP] Bob Braden, Lixia Zhang, Steve Berson, Shai Herzog, Sugih Jamin. Resource ReSerVation Protocol (RSVP). RFC 2205, September 1997. ftp://ftp.univie.ac.at/netinfo/rfc/rfc2205.txt [RTP] Henning Schulzrinne, Stephen L. Casner, Ron Frederick, Van Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, Januar 1996. ftp://ftp.univie.ac.at/netinfo/rfc/rfc1889.txt [RTSP] Henning Schulzrinne, Anup Rao, Robert Lanphier. Real Time Streaming Protocol (RTSP). RFC 2326, April 1998. ftp://ftp.univie.ac.at/netinfo/rfc/rfc2326.txt [SMIL] Synchronized Multimedia Working Group (WG) of the World Wide Web Consortium, Synchronized Multimedia Integration Language (SMIL) 1.0 Specification: http://www.w3.org/TR/REC-smil [SVIDEO] Holger Reibold. Streaming Video. Internet Professional, Nummer 8/1999, Seiten 224ff. Ziff-Davis Verlag GmbH. [TCP] Transmission Control Protocol. RFC 793, September 1981. ftp://ftp.univie.ac.at/netinfo/rfc/rfc793.txt
Seite 24
[UDP] J. Postel. User Datagram Control Protocol. RFC 768, August 1980. ftp://ftp.univie.ac.at/netinfo/rfc/rfc768.txt [VKINO] Virtuelles Patschenkino. C.A.R.L – Das Magazin für angewandte Kommunikation. Nummer 1/2000. Herausgegeben von Ing.Michael Pletz. [WWWMUSIK] Thomas J. Schult. Das Netz ist Klang. Musik finden im WWW. c’t Nummer 14 (1999), Seite 96 – 102. Heise Verlag.
Seite 25
