Plattform für interaktives Live-Internet-TV

Inhaltsverzeichnis

Einleitung

Analyse
Kurze Geschichte des interaktiven Fernsehens
Einführung
Phase 1: Das Videotelefon der 50er und 60er Jahre
Phase 2: Analoges interaktives-TV in den frühen 80er Jahren
Phase 3: Die interaktive Revolution in den 80er Jahren
Phase 4: Umfassende Experimente mit iTV in den frühen 90er Jahren
Phase 5: Konvergenz von Fernsehen und Internet in den späten 90er Jahren
Phase 6: Erweitertes TV, personalisiertes TV, SMS-TV zur Jahrtausendwende
Zukünftige Entwicklungen
Fazit
Allgemeine Vorgaben
Qualitätsmerkmale
Plattformunabhängigkeit
Bedienungsfreundlichkeit
Geschwindigkeit
Zuverlässigkeit
Wartbarkeit
Gesuchte Teilkomponenten
TV-Studio-Mixer Anwendung
Webseite Programmverwaltung
Darstellen des Videos auf der Webseite
Infrastruktur und Kommunikation zwischen den Komponenten
Videodaten
Interaktive Elemente (optional)
Architektur der Webseite
Anwendungsfalldiagramme
Webseite
TV-Studio-Anwendung
Live-Internet-Fernsehen als Medium der Zukunft?
Das Modell „YouTube“
Spezielle Eigenschaften von Direktübertragungen
Fazit
State of the Art
Client-Technologien
Streaming-Protokolle
Distributionstechniken
Problembereiche beim P2P-Streaming
Rahmenbedingungen
Aktuelle Streamingserver-Software
Kommerzielle Live-Streamingdienste
Kommerzielle TV-Live-Studio Anwendungen
Möglichkeiten um vom Handy aus zu streamen
P2P-Streamingprojekte
Frameworks zur vereinfachten Videomanipulation
Vereinfachtes Fenstermanagement
Gestaltung der Programmplanungs-Webseite
Interaktive Videos
Formen der (Live-)Interaktion
Internet-TV auf dem Fernseher
Trends und Best-Practices aus der Forschung

Synthese
Technologisches Konzept
Client-Technik zur Live-Video-Betrachtung / Video-Player
Streaming-Codec
Distributionstechnik
Technologische Basis zur TV-Studio-Mixer-Anwendung
Technologische Basis der Webseite
Implementierung
Erstellung der .NET-Wrapper-Klassen für das Video-SDK
Entwicklung von unabhängigen Videocontrols
Klassenübersicht
Integration der Videocontrols in „PolyMonRT“
Realisierte Funktionalitäten in der TV-Studio-Anwendung
Lokalisierung im .NET-Framework
Entwicklung von Widgets für „Dropthings“
Weitere Anpassungen von „Dropthings“
Fazit

Zusammenfassung und Ausblick

Anhang
Benutzerhandbuch

Glossar

Literaturverzeichnis

Abbildungsverzeichnis

Einleitung

Das Ziel dieser Bachelorarbeit ist die konzeptionelle Planung sowie die technische Umsetzung einer Internet-Plattform zur Erstellung und Verbreitung von interaktivem Live-TV im Rahmen der Aktivitäten der französischen Internetseite eXultet.net [eXu09].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Startseite von eXultet.net [eXu09]

Bei diesem in Abbildung 1 dargestellten, französischen Internetdienst handelt es sich um eine „Non-Profit-Organisation“, die sich der Verbreitung christlicher Inhalte widmet. Dieses Ziel wird durch das Angebot einiger tausend christlicher Musiktitel sowie ebenfalls einiger tausend christlicher Konferenzen in Form von MP3-Dateien erreicht. Ein Teil der Produkte kann kostenlos abgegeben werden, die anderen können zu einem sehr günstigen Preis erworben werden. Vor kurzem hat auch der Verkauf von Musiknoten in Form von PDF-Dateien begonnen. Bei vielen aktuell stattfindenden Konferenzen bzw. Gottesdiensten ist bereits heute ein Mitarbeiter von eXultet.net „vor Ort“, um direkt den Ton in professioneller Qualität aufzunehmen. Bei wichtigen Veranstaltungen nimmt zusätzlich auch ein Kameramann zur Erstellung von Videomitschnitten teil. Letztere werden bisher allerdings nur per DVD-Kopie über eine christliche Versandbuchhandlung in Frankreich vertrieben. Schon seit langer Zeit ist nicht nur geplant, diese Videos auch über den oben gezeigten Online-Shop zu vertreiben, sondern auch „Live“ eine Teilnahme über Internet zu ermöglichen. Dazu muss das vor Ort aufgenommene Video auf einem geeigneten Weg als Direktübertragung den interessierten Zuschauer zu Hause erreichen können.

Dabei soll untersucht werden, wie die dabei entstehenden Kosten so niedrig wie möglich gehalten werden können. Es gibt heute selbstverständlich in diesem Bereich bereits Dienstleister, die mit einem entsprechenden Einsatz von professioneller Hard- und Software eine derartige Direktübertragung zu einer nahezu unbegrenzten Zahl von Zuschauern realisieren können. Allerdings erreichen die dabei entstehenden Kosten schnell fünfstellige Beträge. Dies ist im vorhandenen christlichen Kontext vollkommen unrentabel, denn schließlich ist es hier undenkbar z.B. einen „Eintrittspreis“ für die (noch dazu virtuelle) Teilnahme an einem Gottesdienst zu verlangen. Dazu kommt, dass die meisten Internetnutzer heute nicht wissen, dass jede Internetseite, die sie besuchen, quasi für ihren Besuch bezahlen muss. Viele sind der falschen Meinung, alle entstehenden Kosten wären durch ihr monatliches Abo bei dem Anbieter des Internet-Anschlusses abgedeckt. Weiterhin existiert im Internet derzeit eine gewisse „Kostenloskultur“. Insofern ist es nicht verwunderlich, dass es für neue, kostenpflichtige Angebote schon im Allgemeinen sehr schwer ist, Fuß zu fassen. Das gilt umso mehr für den christlichen Bereich, da hier in der Regel alle Angebote kostenlos sind.

Weiterhin ist selbst eine Finanzierung über Werbung im Internet besonders im Videobereich, bei dem hohe Kosten anfallen, oft schwierig (siehe beispielsweise „YouTube“ [int09]). Internetnutzer haben oft bereits einen Reflex entwickelt, um allerorts eingeblendete Werbung bewusst zu ignorieren. Dazu kommt, dass gerade im christlichen Bereich diese in der klassischen Form – als zeitweilige Überblendung des Videobildes – als sehr störend empfunden wird.

Der Zuschauer soll eine Möglichkeit erhalten, über eine zu erstellende Webseite die Programmplanung der verfügbaren Kanäle abzurufen. Programmanbieter müssen diese Informationen natürlich auch im Vorfeld entsprechend aufbereiten können. Weiterhin soll über diese Webseite auf eine geeignete Art und Weise auch auf die eigentlichen Live-Video-Daten zugegriffen werden können. Dabei sollen in Frage kommende Interaktionsformen und deren technische Realisierbarkeit genauer untersucht werden.

Überblick

Die vorliegende Arbeit ist in die Hauptteile „Analyse“ und „Synthese“ gegliedert.

Im Kapitel 2 „Analyse“ wird zuerst kurz im Rückblick die Geschichte des interaktiven Fernsehens mit all ihren Fehlstarts und Rückschlägen betrachtet. Anschließend erfolgt die Identifikation der gesuchten Teilkomponenten sowie der benötigten Infrastruktur zur Kommunikation unter den Komponenten. In Anwendungsfalldiagrammen werden diese daraufhin dargestellt. Auf eine Erörterung, ob angesichts der steigenden Popularität von „Video-on-Demand“ (VoD) (siehe Glossar) (z.B. bei „YouTube“ [you09]) ein Live-Fernsehen mit „festem“ Programmablauf noch zeitgemäß ist, erfolgt die Darstellung des „State of the Art“ in technologischer, rechtlicher und gestalterischer Hinsicht.

Hierbei werden aktuell verfügbare Client-Technologien, Streaming-Protokolle (siehe Glossar) und Distributionstechniken auf ihre Anwendbarkeit in diesem Projekt hin untersucht und bewertet. Ebenso werden Probleme beim P2P-Streaming (siehe Glossar) und allgemeine Rahmenbedingungen (wie zu berücksichtigende Gesetze usw.) betrachtet. Anschließend wird ein Überblick über existierende Softwarelösungen, Open-Source-Projekte (siehe Glossar) und Online-Dienste gegeben und deren Tauglichkeit zur Verwendung im Rahmen der vorliegenden Problemstellung untersucht. Dieses Kapitel beschäftigt sich weiterhin mit Überlegungen zur Gestaltung der im Projekt geforderten Internetseite sowie dem aktuellen Stand der Technik bei interaktiven (Live-)Videos und den dabei möglichen Interaktionsformen seitens der Zuschauer. Abgeschlossen wird die Analyse durch eine Betrachtung wie das Internet-Fernsehen auf den „normalen“ Fernseher gebracht werden kann sowie die Vorstellung aktueller und relevanter Forschungsprojekte.

Im Kapitel 3 „Synthese“ wird erörtert welcher Ansatz und welche Technologien zur Lösung der vorliegenden Aufgabenstellung als geeignet erscheinen (Technologisches Konzept) und wie deren Implementierung realisiert wurde.

Eine Zusammenfassung und ein Ausblick im Kapitel 4 runden diese Arbeit ab. Im Anhang findet sich ein kurzes Benutzerhandbuch zur erstellten Software.

Analyse

Im Rückblick wird die Geschichte des interaktiven Fernsehens mit all ihren Fehlstarts betrachtet. Anschließend erfolgt die Identifikation der gesuchten Teilkomponenten sowie der benötigten Infrastruktur zur Kommunikation unter den Komponenten. Diese werden in Anwendungsfalldiagrammen daraufhin dargestellt. Auf eine Erörterung, ob angesichts der steigenden Popularität von Video-on-Demand (VoD) (z.B. bei „YouTube“ [you09]) ein Live-Fernsehen mit „festem“ Programmablauf noch zeitgemäß ist, erfolgt die Darstellung des „State of the Art“ in technologischer, rechtlicher und gestalterischer Hinsicht.

Hierbei werden aktuell verfügbare Client-Technologien, Streaming-Protokolle und Distributionstechniken auf ihre Anwendbarkeit in diesem Projekt hin untersucht und bewertet. Ebenso werden Probleme beim P2P-Streaming und allgemeine Rahmenbedingungen (wie zu berücksichtigende Gesetze usw.) betrachtet. Anschließend wird ein Überblick über existierende Softwarelösungen, Open-Source-Projekte und Online-Dienste gegeben und deren Tauglichkeit zur Verwendung im Rahmen der vorliegenden Problemstellung untersucht. Dieses Kapitel beschäftigt sich weiterhin mit Überlegungen zur Gestaltung der im Projekt geforderten Internetseite sowie dem aktuellen Stand der Technik bei interaktiven (Live-)Videos und den dabei möglichen Interaktionsformen seitens der Zuschauer. Abgeschlossen wird dieses Kapitel durch eine Betrachtung wie das Internet-Fernsehen auf ein handelsübliches Fernsehgerät gebracht werden kann sowie die Vorstellung aktueller und relevanter Forschungsprojekte.

Kurze Geschichte des interaktiven Fernsehens

Zu Beginn soll zunächst ein kurzer Rückblick auf die Geschichte des interaktiven Fernsehens erfolgen, bevor dann im nächsten Unterkapitel auf die Vorgaben dieses Projektes eingegangen wird. Ziel ist es aus den Fehlern und Entwicklungen der Vergangenheit zu lernen und so besser die heutige Situation beurteilen zu können. Im Wesentlichen stammen die folgenden Gedanken aus [Jen08].

Einführung

Oft entsteht der Eindruck, dass „interaktives Fernsehen“ etwas ganz Neues wäre. Tatsache ist allerdings, dass es genauso alt ist wie das Fernsehen selbst. Bereits in den 20er Jahren des 19. Jahrhunderts hatte man mit einem Audio-Rückkanal (siehe Glossar) experimentiert. Im Laufe der Jahre hat sich dies allerdings mehr und mehr zu einer Einbahnstraße entwickelt, auch wenn immer wieder die interaktive Idee zum Vorschein kam. Leider sind alle Erfahrungen die seitdem in dieser Hinsicht gesammelt wurden mehr oder weniger in Vergessenheit geraten. Dies ist schade, kann man doch aus diesen Erfahrungen (z.B. welches Geschäftsmodell funktioniert und welches nicht) viel für heutige Weiterentwicklungen lernen. Oft wurden Konzepte entwickelt und auch schon real ausprobiert, deren Durchbruch aus verschiedensten Gründen, wie unreifer Technik, fehlender Inhalte bzw. Nachfrage scheiterten. In gewissem Sinn wird das interaktive Fernsehen bereits seit 50 Jahren entwickelt.

Kein Thema war so oft „der letzte Schrei“, der aber ein um das andere Mal im Nichts verhallte. Wenig andere Technologien haben in den letzten 50 Jahren so viele Fehlstarts zu verbuchen.

Viele Versuche sind unternommen worden um die „Killeranwendung“ (siehe Glossar) zu finden, die endgültig den Durchbruch bringen würde. So oft wurde die Entdeckung des „Heiligen Grals“ ausgerufen, der die Medienindustrie endlich in eine neue und vor allem gewinnbringende Zeit katapultieren würde. Genauso oft wurde auch bereits in genauso übertriebener Weise der endgültige Tod des „interaktiven Fernsehens“ verkündet. Der Gedanke, dem Medium Fernsehen interaktive Elemente hinzuzufügen, sorgt weiterhin für Aufsehen.

Im Rahmen dieser historischen Untersuchung soll „interaktives Fernsehen“ in einem weiteren Sinn als Mischung von traditionellem Fernsehen und neuen interaktiven Informations- und Kommunikationstechnologien verstanden werden. Genauer findet beim „interaktiven Fernsehen“ eine reale Interaktion mit dem Medium in Form von Auswahl, Entscheidung und (kommunikativer) Rückmeldung. Auf diese Weise kann der Zuschauer erneut die Kontrolle darüber zurückgewinnen, was er sich anschaut, wann er es sich anschaut und wie er es sich anschaut. Oder es wird ihm die reale Möglichkeit einer aktiven Teilnahme an den Sendungen eröffnet oder er kann sogar selbst erstellte Inhalte beitragen.

Phase 1: Das Videotelefon der 50er und 60er Jahre

Bereits in den 20er Jahren des 19. Jahrhunderts begannen in den Laboren der Firma Bell die ersten Tests, sich gegenseitig Bilder zuzuschicken. 1964 wurde das erste Serienmodell vorgestellt als „Kreuzung eines Telefons mit einem Fernsehapparat“ [Por09]. 1970 schließlich startete der erste „PicturePhone“-Dienst, gedacht in erster Linie für Geschäftsleute, der laut Prognosen bereits bis 1980 über eine Million Apparate umfassen hätte sollen. Die Abbildung 2 zeigt ein Modell dieses Gerätes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Abbildung eines Bell „PicturePhone“ [Por09]

Der Dienst hat aber nie richtig Fuß fassen können und wurde 1973 nach enormen Fehlinvestitionen wieder eingestellt.

Phase 2: Analoges interaktives-TV in den frühen 80er Jahren

1977 brachte Time Warner das QUBE-System heraus [Qub09], das oft als erster gescheiterter Versuch interaktiven Fernsehens (in der Folge kurz „iTV“) aufgeführt wird. Dabei handelte es sich um ein Kabelfernsehen mit 30 Kanälen. Darunter waren 10 normale Fernsehkanäle, 10 „Pay-per-View“ Kanäle (siehe Glossar) und 10 Kanäle mit einzigartigen, interaktiven Diensten. Dazu gab es einen schmalbandigen Rückkanal, der es dem Benutzer mit Hilfe von 5 Bedienknöpfen (siehe Abbildung 3) ermöglichte an Spiel-Shows, bei Umfragen und Abstimmungen usw. teilzunehmen sowie Sportereignisse auszuwählen, Filme zu kaufen und vieles mehr. Es wurde viel darüber in den Medien berichtet und viele Haushalte erwarben das System.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: QUBE-System Bedienkonsole [Qub09]

Aber abgesehen von einigen Spielshows und Abstimmungen bei wichtigen Ereignissen wurden die interaktiven Funktionen selten genutzt. Auf lange Sicht wurde das System sowohl dem Kabelnetzbetreiber als auch den Teilnehmern zu teuer. Denn das Aufrechterhalten des Rückkanals (siehe Abbildung 4 für ein Bild des Kontrollzentrums) sowie die Produktion der interaktiven Fernsehformate waren zu aufwändig und letztere verfügten im Vergleich mit normalen Fernsehformaten über zu wenig Geldmittel.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: QUBE Kontrollzentrum [Qub09]

Vor allem weil die Produzenten hier absolutes Neuland betreten mussten. Der Dienst schaffte es nie in die Gewinnzone und wurde wieder eingestellt [Tim84]. Allerdings führte dieser „Testbetrieb“ der interaktiven Fernsehformate später dann zu Fernsehsendern wie „MTV“ [MTV09], die heute viele Sendungen mittels SMS-Rückkanal zu interaktiven Sendungen ausbauen. In der folgenden Abbildung 5 ist eine typische Anwendung einer Sendung gezeigt, in der mittels SMS über Musikvideos und dergleichen abgestimmt werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Interaktion bei Abstimmungen/Live-Chat usw. via SMS [digi09]

Phase 3: Die interaktive Revolution in den 80er Jahren

Grundsätzlich waren die 80er Jahre geprägt vom Einzug neuer interaktiver Technologien in die Haushalte die eine größere Kontrolle über die Mediennutzung gestatten: Video-Rekorder, Spielkonsolen, Videospiele, Personal-Computer (PC), Finanztransaktionen von zu Hause aus, Informations-Displays an öffentlichen Plätzen und so weiter. Man kann hier von einer generellen Wende hin zur interaktiven Bedienung sprechen, da die Menschen so darin trainiert wurden mit den Verbrauchsgeräten mehr und auf neue Weisen zu interagieren.

Im Bereich des interaktiven Fernsehens wichen die ambitionierten Projekte einfacheren Systemen wie Meinungsumfragen mit Hilfe von speziellen Telefonapparaten. Im Kabelnetz brachte „Cox Cable“ in den frühen 80er Jahren den Videotext-Dienst heraus [Car96]. Dieser Dienst lief über ein Kabel mit Rückkanal und bot Homebanking, Einkäufe, Informationsdienste und Bildungsangebote, jedoch alles im Vergleich zu heute nur mit Text und einfachen Grafiken.

Die Firma „Time“ brachte Teletext heraus (siehe Abbildung 6 für eine Beispielseite), der sogar die Teilnahme an Spielen erlaubte. Beide Dienste wurden am Ende des Testzeitraums eingestellt, da auch sie für alle Beteiligten zu teuer waren um ein tragbares Geschäftsmodell entwickeln zu können [Car96]. Ebenso wurden erste Videotext-Dienste über Telefon (Anzeige der Informationen am Fernseher) entwickelt, die aber ebenfalls zu teuer für den Endverbraucher waren und wieder eingestellt wurden. Trotz allem zeigten Umfragen, dass die Verbraucher gegenüber manchen Diensten positiv eingestellt waren, wie z.B. Spielen [Car96].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Typische Teletext-Seite der BBC (dort Ceefax genannt) [Wik08]

Telefongesellschaften wie AT&T führten damals erfolgreich die Möglichkeit ein, über spezielle Telefonnummern an Abstimmungen in Fernsehprogrammen teilzunehmen. Dies wird seit den späten 80er Jahren bis heute genutzt.

Phase 4: Umfassende Experimente mit iTV in den frühen 90er Jahren

Es war ebenfalls AT&T, die unter einer Gruppe von 140 Angestellten Anfang der 90er Jahre einen umfassenden, zwei Jahre dauernden Test durchführte, dessen Ergebnisse in vielerlei Hinsicht die Ergebnisse ähnlicher Tests zusammenfasste. Unter anderem zeigte die Studie überwiegend positive Reaktionen und eine Interessenfokussierung auf Bildungsprogramme für Kinder, Sportübertragungen und Spiele, in denen Haushalte gegeneinander antreten konnten [Car94]. Man kam auch zu dem Schluss, dass ein Programm vier Eigenschaften benötigte, um Erfolg zu haben: „Unterhaltung, es musste etwas „Rüberkommen“ (transaction), Information und Kommunikation. Die Leute wollten Spaß haben, etwas Lernen, „have something“ und jemandem davon erzählen“ [Tas96]. Interessanterweise war die eigentliche Natur des Dienstes zweitrangig (ob es ein Spiel, das Erzählen einer Geschichte oder Informationsvermittlung war). Man schloss die Studien mit den gleichen Erkenntnissen ab, wie sie auch anderenorts gemacht worden waren: Der Dienst musste vor allem einfach zu bedienen sein. Gefragt war „Fernsehen“ und nicht eine „Computerbenutzung“ und die Testpersonen wollten keine Funktion benutzen, die auch nur im Entferntesten an die komplexen Befehle eines Computers erinnerte [Tas96]. Weiter wurde der Schluss gezogen, dass „attraktive Dienste sehr stark von wechselnden Inhalten abhingen“ [Tas96].

Die am meisten fortgeschrittene Testumgebung für interaktives Fernsehen war in der Mitte der 90er Jahre das „Full Service Network“ (FSN) von Time Warner in Orlando [NYT94]. Dabei war das Wort „Full“ wörtlich zu nehmen, denn alle erdenkbaren Dienste wurden davon abgedeckt: Programmführer, Video auf Abruf, Musik auf Abruf, Nachrichten, Shopping, personalisierte Werbung, Spiele, Bildung, Banking, Gesundheitsdienste, Kartenverkauf, Austausch mit öffentlichen Einrichtungen, städtischen Einrichtungen und Bibliotheken, Telefondienste, schnelle 2-Wege-Kommunikation zum Austausch von hochauflösenden Videodaten zwischen Firmen, Krankenhäusern, Schulen usw. Als der Dienst 1995 den Probebetrieb aufnahm hatten 4000 Haushalte Zugang über Glasfaserkabel [Swe00]. Aber auch dieser Dienst wurde nach zwei Jahren mit einem immensen Verlust wieder eingestellt. Auch hier war alles viel zu teuer (laut [Dri08] beliefen sich die Kosten für die Set-Top-Box (siehe Glossar) sogar auf ca. 10.000 US-Dollar, wenn auch andere Quellen [Net95] „nur“ von 3.000 US-Dollar sprachen), aber das war den Projektleitern angeblich von Anfang an bewusst. Es konnten (laut [Jen08]) die folgenden lehrreichen Erfahrungen gemacht werden:

1. der Dienst selbst muss den Verbrauchern kostenlos zur Verfügung stehen
2. verschiedene, abgestufte Preismodelle wurden nicht angenommen
3. Video-auf-Abruf war sehr populär
4. die Teilnehmer wollen wirklich einfache Interaktionsmöglichkeiten

Es stellte sich heraus, dass es sehr schwierig war, fortgeschrittene iTV-Systeme aufzubauen, genauso schwierig wie es war, die Dienste und Inhalte zu entwickeln, die im Alltagsleben der Verbraucher wirklich Sinn machten.

Phase 5: Konvergenz von Fernsehen und Internet in den späten 90er Jahren

Ende der 90er Jahre standen drei Datenautobahnen um iTV zu realisieren zur Verfügung: ISDN (siehe Glossar), digitales Fernsehen und Internet. Interessant dabei ist, dass das Internet „einfach so“ gewachsen ist. Keine Firma hat es als „ihr Produkt“ mit massiven Marketingmitteln vorangetrieben und niemand glaubte daran, dass es etwas wäre, mit dem man eines Tages Gewinne machen könnte. Besonders rasant verbreitete sich das Internet ab der Einführung des ersten Web-Browsers (siehe Glossar) im Jahre 1993. Seitdem übertreffen seine Wachstumsraten die aller je dagewesenen Medien-Technologien.

Wenn man das iTV als den größten technologischen Fehlschlag der letzten 50 Jahre betrachtet, dann ist demgegenüber das Internet der größte Erfolg der 90er Jahre, wenn nicht des gesamten 20. Jahrhunderts. Es lag nahe in einer Mischung aus Computern, Fernsehen und Internet endlich den erfolgverheissenden Weg für iTV zu sehen [Kra97].

Internet auf dem Fernseher sollte uns ermöglichen viele Dinge über den Fernseher zu erledigen, für die wir sonst einen PC benötigen: E-Mail Kommunikation, Chats, Informationssuche usw.

Viele Fernsehdienstbetreiber sahen in dieser Mischung die ultimative Killer-Anwendung: Die weite Verbreitung von Fernsehern verbunden mit den anarchischen Multimediadaten des Internets. Anders ausgedrückt: das Internet selbst ist die Killer-Anwendung. Man musste es nur zu den „noch nicht Verbundenen“ bringen, denen, die schon auf der Fernsehcouch saßen, und nur darauf warteten.

Phase 6: Erweitertes TV, personalisiertes TV, SMS-TV zur Jahrtausendwende

Seit der Jahrtausendwende leben einige der bereits angesprochenen Trends wieder auf, besonders in Verbindung mit DVB (siehe Glossar). Andere scheinen in Vergessenheit zu geraten. Dies trifft im Besonderen auch für den Zugang zum Internet über den Fernseher zu.

In Bezug auf die neuen Trends -, dem erweiterten TV, personalisiertem TV und dem SMS-TV - ist zu bemerken, dass es sich jeweils um technologisch einfache Konzepte handelt, die sich mit Teilbereichen begnügen, und nicht wie die früheren Ansätze das Ziel verfolgen, einen Komplettservice bereit zu stellen.

Beim erweiterten TV handelt es sich um eine Art neuen, Internet-gespeisten „Videotext“, d.h. in der Regel Texte und Grafiken, die dem aktuellen Videosignal überlagert sind und meistens in der Austastlücke übertragen werden. Die Interaktivität besteht in der Auswahl der Informationsseite. So können zusätzliche Informationen übertragen werden. Es handelt sich also nur um eine einfache Art und Weise Zusatzinformationen in begrenztem Umfang anzubieten [Wea02].

Beim personalisierten TV handelt es sich letztendlich um einen erweiterten Video-Rekorder. Dieser ermöglicht es dem Nutzer zu einer selbst bestimmten Zeit die Inhalte zu sehen die ihn interessieren.

Beim dritten Bereich weicht man auf ein anderes Medium aus, da die meisten Haushalte immer noch nicht weder mit irgendeiner Form eines Fernseh-Rückkanals ausgestattet sind, noch über eine fortgeschrittene Set-Top-Box verfügen. Bei dieser medienübergreifenden Interaktion ersetzen Telefon, E-Mail, Internet-Chat, Fax oder SMS den fehlenden Rückkanal. Weder beim Zuschauer, noch beim Programmanbieter sind dafür gesonderte Investitionen notwendig. Besonders die Nutzung von SMS über das Handy erfreute sich in diesem Zeitraum (und bis heute) großer Beliebtheit [Dus02]. Die beliebtesten Fernsehformate waren dabei Umfragen, Spiele und Chat in Form von per SMS von Zuschauern eingesandten Texten.

Diese, im Vergleich zu früheren ambitionierten Ansätzen, eher als „Low-End“ zu betrachtende Ansätze, zeigen einen eher „evolutionären“ Ansatz im Gegensatz zum „revolutionären“ Ansatz Mitte der 90er Jahre. Eine moderate Strategie, die einfache Dienste mit Hilfe von vorhandenen, bewährten und so relativ billigen Technologien realisiert.

Zukünftige Entwicklungen

Die Mehrzahl der Ansätze von iTV der letzten 50 Jahre ist gescheitert. In diesem Sinne ist das iTV seit den 50 Jahren dabei eingeführt zu werden. Die Gründe für die Fehlstarts waren unter anderem:

1. Die Technologie war nicht reif.

2. Es stand kein lebensfähiges Geschäftsmodell dahinter.

3. Im Vergleich zu konkurrierenden Technologien waren die Umstände ungünstig.

4. Die Dienste und Inhalte brachten nicht genug Zusatznutzen im Vergleich zu konkurrierenden Diensten.

Selbst nach fünf Jahrzehnten gibt es weder ein bodenständiges Modell für Interaktivität in Verbindung mit dem Fernsehen, noch ein gesichertes Wissen darüber, was der Nutzer eigentlich möchte.

Trotz dieser wenig ruhmreichen Vergangenheit gibt es einige Hinweise darauf, dass das interaktive Fernsehen genauso wie das digitale Fernsehen jetzt eine Wachstumsphase erleben könnte. Daten von Forrester Research [For09] zufolge soll die Verbreitung des digitalen Fernsehens im Jahr 2009 um 50% zunehmen. Es ist unwahrscheinlich, dass in naher Zukunft die „Killer-Anwendung“ des iTV gefunden werden kann. Andererseits geht es kontinuierlich in kleinen Schritten voran, schließlich existiert es bereits in frühen Formen wie SMS-TV oder Fernsehprogrammen mit zugehörigen Web-Communities.

Fazit

Aufbauend auf dem bisher Diskutierten lassen sich in Bezug auf das konkrete Projekt die folgenden Schlüsse ziehen:

1. Die Bedienung muss wirklich einfach sein, sollte also z.B. auch mit einer TV-Fernbedienung möglich sein.
2. Der Dienst muss kostenlos zur Verfügung gestellt werden und trotzdem ein lebbares Geschäftsmodell besitzen, d.h. er darf nur wenig Kosten verursachen!
3. Es wird wichtig sein, mit Hilfe von konstantem Feedback wirklich nur die Funktionen zu implementieren, die wirklich vom Zuschauer gewünscht werden.
4. Interaktionsmöglichkeiten mit bestehenden Medien wie Telefon, Handy (SMS) usw. sollten untersucht und wenn möglich integriert werden, insbesondere auch im Hinblick auf Plattformen, auf denen die interaktiven Funktionen nicht zur Verfügung stehen werden.

Allgemeine Vorgaben

Da das Team, dass sich auch um die Pflege und Weiterentwicklung der Angebote rund um „eXultet.net“ kümmert, das in dieser Arbeit entstehende Projekt im Anschluss weiterpflegen und weiterentwickeln soll, und in diesem bereits entsprechende Kompetenzen und Geräte vorhanden sind, soll die gesuchte Webseite zur Programmverwaltung sowohl auf einem Windows-Server-Betriebssystem [Mic09l] als auch in den von Microsoft dafür angebotenen Technologien realisiert werden. Wo es möglich und sinnvoll ist, soll dabei die Programmiersprache Visual C# von Microsoft zum Einsatz kommen.

Hierfür wird sowohl ein dedizierter Windows-Server als auch eine Version von Visual Studio 2008-Professional [Mic09m] zur Verfügung gestellt.

Dies schließt allerdings nicht aus, dass für Teilkomponenten – insofern es sich als vorteilhaft oder notwendig erweisen sollte – nicht auch andere Techniken verwendet werden können.

Als Budget stehen dem Projekt zur Realisierung der Plattform ca. 600 EUR zur Verfügung. Im laufenden Betrieb sollten die Kosten so niedrig wie möglich gehalten werden können.

Für eine breite Akzeptanz des Angebotes sollte aus Zuschauersicht eine möglichst geringe technische Einstiegshürde angestrebt werden, d.h. im Idealfall sollte keine Softwareinstallation notwendig sein um das Angebot nutzen zu können.

Qualitätsmerkmale

Folgende Qualitätsmerkmale werden für dieses Projekt vorgegeben (beginnend mit dem Wichtigsten):

Plattformunabhängigkeit

Das Live-Video soll möglichst viele Zuschauer erreichen können. Es sollte daher auf so vielen Plattformen wie möglich konsumiert werden können. Die Software zur Produktion desselben wird nur von einem kleineren Nutzerkreis verwendet, diese kann also durchaus auf eine gängige Plattform beschränkt sein.

Bedienungsfreundlichkeit

Das mit dieser Plattform verbreitete Live-Video soll nicht nur eine technisch versierte, sondern eine breite Nutzerschicht ansprechen. Deshalb soll die Bedienung des für die Videobetrachtung zuständigen Programmteils so einfach wie möglich gestaltet werden. Die Software zur Live-Video-Produktion richtet sich an Expertennutzer und kann von daher komplexer gestaltet sein.

Geschwindigkeit

Sollte das Live-Video beim Betrachten regelmäßig einfrieren bzw. Aussetzer produzieren, verlieren Zuschauer schnell die Geduld und wenden sich anderen Angeboten zu. Das Video sollte demnach möglichst flüssig, auch auf langsameren Systemen (wie beispielsweise Mobiltelefonen), dargestellt werden können. Das „Abmischen“ von Videoströmen stellt grundsätzlich hohe Anforderungen an die verwendete Hardware. Weiterhin ist es zumutbar, dass ein Video-Produzent extra für diese Aufgabe ein Computersystem anschaffen muss. Dieser Teil der Plattform kann also auch ein „überdurchschnittliches“ Computersystem im Hinblick auf die Prozessorleistung und eventuell erforderliche Erweiterungskarten zur Digitalisierung des Videobildes erfordern.

Zuverlässigkeit

Analog zu den Bemerkungen über die Geschwindigkeit sollte das Live-Video zuverlässig und ohne Unterbrechungen konsumiert werden können. Da sich das Projekt allerdings im semi-professionellen Rahmen ansiedelt und damit auch kein „normales“ 24-Stunden-Fernsehprogramm, sondern nur punktuelle Übertragungen realisiert werden sollen, hat dieser Punkt einen nachgeordneten Stellenwert.

Wartbarkeit

Eine Erweiterung der Plattform ist bereits geplant. Es werden also längerfristig auch andere Programmierer an der Weiterentwicklung beteiligt sein. Deshalb sollte die Wartungsfreundlichkeit zwar grundsätzlich gegeben sein, ist aber durch die geplante punktuelle Nutzungsart trotzdem ein nachgeordnetes Merkmal.

Gesuchte Teilkomponenten

An dieser Stelle erfolgt die Identifizierung der Teilkomponenten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Schematische Darstellung der gesuchten Teilkomponenten

In der Abbildung 7 ist das Zusammenspiel der gesuchten Teilkomponenten schematisch dargestellt. Im Zentrum wird eine sogenannte „TV-Studio-Mixer-Anwendung“ benötigt, die die Videodaten aus den verschiedenen, auf der linken Seite schematisch dargestellten, Quellen entgegennimmt. Dazu gehören mit dem Computer direkt verbundene Videoquellen (wie z.B. Videokameras), andere Video-Streaming-Server oder Mediendateien, die von der lokalen Festplatte geladen werden. Diese Anwendung muss in der Lage sein, aus den Video-Eingabedatenströmen mit einer möglichst geringen Verzögerung einen oder mehrere Video-Ausgabedatenströme zu erzeugen. Über einen Webserver wird eine Internetseite zur Programmplanung bereitgestellt. Darüber hinaus ist in diese Internetseite auch eine Möglichkeit zum Abspielen eines Programms integriert.

Im Folgenden werden die Anforderungen an die genannten Teilkomponenten genauer untersucht.

TV-Studio-Mixer Anwendung

Auch wenn diese Komponente auf verschiedene Weisen realisiert werden kann, so stellt sie doch ein in sich geschlossenes System dar, dass bei Bedarf mit Einschränkungen auch unabhängig von den anderen Komponenten verwendet werden kann. Diese Anwendung teilt sich wie im Folgenden gezeigt weiter auf.

Audio/Video-Mixer

Beim „Audio/Video-Mixer“ (im Folgenden kurz „AVMixer“ genannt) handelt es sich um einen klassischen Audio/Videomixer, bei dem aus verschiedenen Eingangssignalen (aus verschiedenen Quellen) ein Ausgangssignal (zur gleichzeitigen Ausgabe auf verschiedene Ziele) zusammengemischt werden soll. Es soll möglich sein, möglichst viele Signalquellen zu unterstützen. Sind Kompromisse nötig, sollen folgende Reihenfolge bei den Eingangssignalen beachtet werden (1 entspricht dabei der höchsten Priorität):

1. Videokameras (möglichst viele Modelle auf möglichst vielen Systemen)
2. Lokal vorliegende Mediendateien (mindestens ein gängiges Videoformat soll gelesen werden können)
3. Das Videosignal von Zuschauern, die sich „live“ zuschalten möchten
4. Von Streaming-Servern ausgehende Videostreams (würde eine Kaskadierung des Videomixers erlauben)

Entsprechend ist folgende Reihenfolge bei den Ausgangssignalen zu beachten

1. „Virtuelle“ Videokamera. Virtuell, damit das Signal von jeglicher Software erneut als Eingangssignal verarbeitet werden kann.
2. Zu einem Streaming-Server der Flash-Videoformate weiterverteilen kann (auch „Flash-Streaming-Server“ genannt), siehe Kapitel 2.8.6. „Aktuelle Streamingserver-Software“
3. Speichern (zu Archivierungszwecken) als lokale Mediendatei (in mindestens einem gängigen Format)
4. Zu einem Streaming-Server der Windows-Videoformate weiterverteilen kann (auch „Windows-Media-Services“ genannt) [Mic09n]

Dabei soll der AVMixer möglichst die lokalen Hardware-Ressourcen (Prozessor, Arbeitsspeicher, Festplattenplatz) nutzen, um hohe Investitionen in Serverhardware sparen zu können. Sollen mehrere Eingangsquellen gleichzeitig verarbeitet werden, kann der AVMixer durchaus „fortgeschrittene“ Anforderungen an die Hardware stellen - wie sie z.B. zum Spielen von aktuellen Videospielen Voraussetzung ist.

Diese Anwendung sollte in mehreren Sprachen bedienbar sein (mindestens aber in Französisch und Deutsch).

Editor für interaktive Zusatzfunktionen (optional)

Der Editor für interaktive Zusatzfunktionen ermöglicht es, das reine Video um Interaktions-möglichkeiten zu bereichern. Hier soll überprüft werden inwieweit es technisch möglich ist, z.B. klickbare Buttons und dergleichen zu realisieren. Die konkrete Funktionalität kann dann auch noch später der Anwendung hinzugefügt werden.

Webseite Programmverwaltung

Bei der „Webseite zur Programmverwaltung“ (im Folgenden kurz „Webseite“ genannt) handelt es sich um eine klassische Programmverwaltung verschiedener Live-Kanäle, wie sie heute bereits an vielerlei Orten, z.B. vom sogenannten „Elektronischen Programmführer“ („EPG“ – siehe Glossar), gebräuchlich ist. Dabei soll nichts Neues erfunden werden, sondern der Benutzer soll sich durch Verwendung bewährter und gebräuchlicher Interaktionsmuster schnell zurechtfinden können. Im Einzelnen sollen nach dem Anlegen eines Kontos Kanäle angelegt, gelöscht und bearbeitet werden. Innerhalb eines Kanals gibt es Sendungen, die sich zeitlich aneinanderreihen. Diese sollen auch angelegt, bearbeitet und gelöscht werden können.

Darstellen des Videos auf der Webseite

Gesucht wird hier eine technische Möglichkeit um ausgehend von der Webseite das von der TV-Studio-Anwendung ausgehende und bei Bedarf mit dem Interaktions-Editor um interaktive Elemente angereicherte Videosignal anzeigen zu lassen (im Folgenden kurz „Video-Player“ genannt). Dabei soll der Benutzer möglichst auf dem Video selbst die interaktiven Elemente bedienen können.

Infrastruktur und Kommunikation zwischen den Komponenten

Die folgenden Daten müssen zwischen den genannten Infrastrukturelementen mit Hilfe geeigneter Protokolle und Verfahren ausgetauscht werden können um die gewünschten Ziele zu erreichen.

Videodaten

Das in der TV-Studio-Anwendung (genauer gesagt im AVMixer) gemischte Ausgangsvideosignal muss zum Empfänger (dem Benutzer des in die Webseite eingebetteten Players) möglichst ohne zeitliche Verzögerung geleitet werden können. Dabei sollen die Kosten minimiert werden.

Interaktive Elemente (optional)

Die Informationen über die gewünschten interaktiven Zusatzelemente müssen ebenfalls zum Player geleitet werden können. Eine hundertprozentige, präzise Synchronisation erscheint hier nicht notwendig (eine Abweichung von bis zu 30 Sekunden erscheint für das gewünschte, primäre Anwendungsfeld - dem Anzeigen von Hyperlinks auf grafischen Buttons – tolerierbar). Auch diese Übertragung soll zu möglichst geringen Kosten erfolgen.

Architektur der Webseite

Hier soll eine geeignete Architektur gewählt werden, um die gesuchten Funktionalitäten effizient auf dem dafür vorhandenen Windows-Server Version 2008 (nach der Vorgabe des Projektes – siehe Kapitel 2.2 „Allgemeine Vorgaben“) betreiben zu können. Diese Webseite soll auch mit möglichst vielen Internetbrowsern (möglichst ohne Installation von Zusatzkomponenten) benutzt werden können. Die Webseite muss in mehreren Sprachen abrufbar sein (mindestens in Französisch und Deutsch).

Anwendungsfalldiagramme

Anwendungsfalldiagramme stellen ein effektives Mittel der Abstraktion dar. Deshalb werden im Folgenden die entsprechenden Diagramme aus der Analyse aufgezeigt.

Webseite

In der Abbildung 8 erkennt man das Anwendungsfalldiagramm, dass die Interaktionen mit der Programmplanungs-Webseite und deren Abhängigkeiten beschreibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Anwendungsfalldiagramm der Webseite

Ein Programmplaner legt Programmeinträge an, ändert oder löscht diese. Der Besucher kann diese dann später konsultieren. Ebenfalls legt der Programmplaner fest welche zusätzlichen Elemente der Besucher später nach seinem Geschmack personalisieren kann. Unabhängig von den anderen Elementen der Webseite kann der Besucher über den integrierten Video-Player sich ein Live-Video-Programm ansehen.

TV-Studio-Anwendung

In der Abbildung 9 wird das Anwendungsfalldiagramm der TV-Studio-Anwendung dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Anwendungsfalldiagramm der TV-Studio-Anwendung

Der mit dem Zusammenschnitt beauftragte Live-Regisseur interagiert mit dem Programm um eine bestimmte Konfiguration anzulegen, diese zu bearbeiten, zu löschen oder diese für die Produktion einer Live-Sendung zu nutzen.

Live-Internet-Fernsehen als Medium der Zukunft?

In diesem Projekt geht es um die Live-Übertragung von Ereignissen bzw. grundsätzlicher gesprochen um den klassischen fernsehtypischen Programmablauf, indem eine Sendung einer anderen folgt. Es stellt sich hier die Frage, ob diese Art von Angebot überhaupt noch zeitgemäß ist, oder ob die Zukunft nicht eher in Richtung des Modells von YouTube [you09] geht. Dort gibt es keine Programmabfolge, sondern die vorhandenen Beiträge stehen uneingeschränkt jedermann jederzeit zum Abruf bereit. Der Zuschauer muss sich, um einen bestimmten Beitrag ansehen zu können nicht „organisieren“, also entweder zum richtigen Zeitpunkt am Gerät sitzen oder durch geeignete Hilfsmittel den Beitrag aufzeichnen um ihn dann zu einem für ihn passenderen Zeitpunkt konsumieren zu können.

Das Modell „YouTube“

Grundsätzlich ist dies sicher für die meisten der „vorproduzierten“ Sendungen (die im Fernsehen immer noch die meiste Sendezeit belegen), die Zukunft. Der Zuschauer ist heute immer weniger bereit sich von den Programmredakteuren seinen Fernsehabend vorherbestimmen zu lassen. Immer mehr Fernsehsender kommen dem Zuschauer in diesem Anliegen entgegen und bieten die wichtigsten Sendungen der Woche „auf Abruf“ in einer sogenannten Mediathek, wie dies z.B bei der „ZDF Mediathek“ [ZDF09] der Fall ist. Entsprechend gibt es derartige Angebote auch bereits bei christlichen Sendern wie z.B. „BibelTV“ [Bib09]. Selbst das Modell „YouTube“ gibt es bereits speziell für diese Sparte, z.B. in Form der Webseite „tangle“ [tan09], die folgende Abbildung 10 zeigt das Beispiel einer Suche auf dieser Webseite.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Beispiel einer christlichen "YouTube"-Seite [tan09]

Spezielle Eigenschaften von Direktübertragungen

Allerdings gibt es durchaus einige Sendeformate, die bevorzugt „live“ gesehen werden: Dazu gehören beispielsweise manche Unterhaltungsshows, aber vor allem tagesaktuelle Ereignisse und Veranstaltungen zum „Mitfiebern“ wie Sport-Wettkämpfe (Fußball, Weltmeisterschaften usw.). Dieses „jetzt“ bekommt auch bei dem derzeit sehr beliebten Twitter-Dienst [Twi09] eine neue Dimension. Man möchte seinen Bekannten mitteilen, was man „jetzt gerade“ macht. Es hat auch sicher etwas mit dem zutiefst menschlichen „Gemeinschaftsbedürfnis“ zu tun, nämlich zu wissen, dass man jetzt nicht gerade alleine vor dem Fernseher sitzt und sich einen aufgezeichneten Film (oder eine DVD) ansieht sondern „zusammen“ mit vielen anderen an einem Ereignis teilnimmt. Zumal – und hier bieten sich besonders durch den „Rückkanal Internet“ viele neue Möglichkeiten die im Folgenden noch genauer untersucht werden – man nicht mehr auf das passive Konsumieren beschränkt ist, sondern direkt „live“ in Kontakt mit anderen treten kann bzw. sogar direkt an einer Sendung/einem Ereignis aktiv teilnehmen kann.

Gerade im christlichen Kontext dieses Projektes bekommt das „Live“ noch einen zusätzlichen und besonderen Stellenwert. Denn wenn Christen sich gemeinsam zum Gottesdienst versammeln wird in ihrem Glauben Jesus Christus leibhaftig unter ihnen gegenwärtig. Die Gemeinschaft bekommt so noch eine zusätzliche Dimension.

Fazit

Es bleibt festzuhalten, dass „Live“-Fernsehen aus den genannten Gründen sicher auch in Zukunft noch seine Berechtigung haben wird. Zumal wenn – wie es in diesem Projekt angestrebt wird – der Zuschauer nicht passiv bleiben muss, sondern selbst in eine Sendung eingreifen kann. Sollte es eines Tages, z.B. basierend auf dem sehr kostengünstigen P2P-Prinzip (dieses wird im Kapitel 2.8.3.5 „Peercasting, das Peer to Peer - Grundprinzip“ näher erläutert) einmal eine entsprechende Plattform geben, kann sogar jeder „Zuschauer“ der möchte, selbst zum „Live-Produzenten“ werden und von unbegrenzt vielen anderen gesehen werden (das „p2p-next“-Projekt [p2p09b], das noch näher im Kapitel 2.8.10.6 und Kapitel 2.8.17.2 vorgestellt wird, möchte dies möglich machen). Und bereits heute kann es (die Finanzierung erfolgt hierbei durch eingestreute Werbung) durch einige der im Kapitel 2.8.7 „Kommerzielle Live-Streamingdienste“ vorgestellten Angebote realisiert werden.

Viele der heutigen Lösungen sind allerdings noch durch die Grenzen der Technik stark in ihrer Alltagstauglichkeit eingeschränkt. Denn denkt man dieses Konzept der virtuellen Gemeinschaft konsequent weiter, dann braucht es nicht auf gemeinsame Stunden vor einem Bildschirm (Fernseher/Computer) beschränkt zu bleiben. Es ist durchaus denkbar so einen regelmäßigen, sozialen Austausch zu führen. Inwieweit hier zukünftige Technik sogar ein soziales Leben innerhalb einer – geographisch zerstreuten – Familie ermöglichen und fördern kann, wird derzeit unter anderem vom europäischen Projekt „Together anytime anywhere“ (TA2) [TA209] erforscht.

State of the Art

Nachdem in den bisherigen Abschnitten im weitesten Sinn die Vorgaben diskutiert worden sind, sollen in diesem zentralen Kapitel nun existierende Lösungsansätze vorgestellt und bewertet werden, sowie die zu beachtenden, vorhandenen Rahmenbedingungen aufgezeigt werden.

Client-Technologien

Innerhalb eines Webbrowsers soll ein Live-Video abgespielt werden können. Deshalb sollen an dieser Stelle die Möglichkeiten untersucht werden, um dies zu realisieren. Dabei werden zuerst die in Frage kommenden Client-seitigen Erweiterungen betrachtet werden. Denn leider wird derzeit noch ein „Plugin“ (siehe Glossar) für den Webbrowser zur Videodarstellung benötigt. Mit „HTML5“ [W3C09a] entsteht derzeit eine Alternative, die deshalb auch in diese Überlegungen einbezogen wird.

In der folgenden Abbildung 11 erkennt man die derzeitige Verbreitung gängiger Browser-Plugins auf den Computern mit Internetzugang. Benutzt eine Internetseite eine Technik, für die auf dem Rechner des Besuchers der Webseite noch kein Plugin installiert ist, so muss dieses erst umständlich heruntergeladen und installiert werden. Dies stellt eine deutliche Barriere dar, die einen Besucher leicht davon abhält die Dienste einer gewissen Internetseite zu nutzen. Deshalb sollte eine von einer Webseite verwendete Technik auf so vielen Computern wie möglich bereits installiert sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Vorhandene Rich-Client-Plugins in Internetbrowsern [Ado09e]

Aus der Abbildung 11 ist deutlich abzulesen, dass Flash der Firma Adobe mit einer Basis von 99% eine deutlich bessere Verbreitung aufweist als dies bei Java der Firma Sun mit nur 81% der Fall ist.

Adobe Flash / AIR

Das Flash-Browser-Plugin der Firma Adobe bettet sich ein in ein größeres Konzept mit vielfältigen Möglichkeiten mit der Hilfe von Tools derselben Firma „RIA“s („Rich Internet Applications“, siehe Glossar) zu erstellen. In der folgenden Abbildung 12 ist die detaillierte Verbreitung des Plugins nach Versionsnummern wiedergegeben. Dies ist wichtig, da erst ab einer gewissen Unterversion des Flash Players 9 (9.0.115) die neueren H.264-Codecs [Ado07] (siehe Glossar) unterstützt werden. Die Zahlen zeigen, dass einem Einsatz dieser neueren Codecs (siehe Glossar) aufgrund der fast 99%igen Verbreitung von dieser Seite her nichts im Wege steht. Allerdings ist damit eine Patent- und Lizenzkostenfrage verbunden (siehe Kapitel 2.8.5.4 „Codec-Lizenzierungsbedarf“).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Installierte Basis des Flash-Browser-Plugins nach Versionsnummern [Ado09f]

Für Plattformen mit begrenzten Ressourcen steht eine spezielle Version namens Flash Lite zur Verfügung. Immer mehr Handys usw. unterstützen diese Plattform.

Es existieren derzeit drei verschiedene Versionen, Flash Lite 2.1, Flash 7 SDK und Flash Lite 3.1. Für einen genaueren Vergleich der Unterschiede sei auf [Ado09h] verwiesen. Interessant wäre in diesem Zusammenhang die Möglichkeit, wenn man einen Live-Stream direkt auf dem Handy empfangen könnte. Laut der eben zitierten Vergleichstabelle sollte dies auf Symbian, Windows CE und Pocket PC-basierten Telefonen der Fall sein. Der Player lässt sich allerdings auch manuell nachinstallieren (siehe dazu [Ado09o]), allerdings erscheint dieser nach der Installation nicht sichtbar im System. Über die zitierte Webseite kann ebenfalls der „Adobe Mobile Packager“ geladen werden. Damit kann eine beliebige Flash-Anwendung im swf-Format (es ist auch durchaus möglich Filme bis zu einer gewissen Größe in dieses Format zu konvertieren) in einen Windows Mobile-kompatiblen „CAB-Container“ [Mic09o] gepackt werden. Dabei handelt es sich um ein Dateiformat, das alle Elemente einer Windows Mobile-Anwendung in einer einzigen Datei integriert. Diese „CAB-Datei“ lässt sich dann problemlos auf dem Mobiltelefon installieren. Die Flash-Anwendung taucht anschließend mit einem eigenen Icon im Programm-Menü auf und wird direkt abgespielt. Mit dieser Vorgehensweise konnte im Test problemlos eine beliebige „swf-Datei“ auf einem Mobiltelefon mit dem Windows Mobile-Betriebssystem ausgeführt werden.

Das Flash-Lite 3.1-Plugin für den Internet-Explorer auf Mobiltelefonen ist auch seit März 2009 verfügbar, leider aber nur für Handyhersteller [Cal09].

Allerdings gibt es neue Bestrebungen, sogar die normale Flash-Plattform in Mobiltelefone der neuesten Generation zu integrieren. Das erste Android-basierte Telefon mit Flash gibt es bereits [Ado09n] und anderen Informationen zufolge ist der Hersteller der Blackberry-Serie auch dabei für Sommer 2010 Flash und Silverlight in diese Geräte zu integrieren [Stu09]. Durch die große Popularität von „YouTube“ [you09] enthalten nahezu allen neuen Fernsehgeräte und Set-Top-Boxen mit Internetanschluss von Haus aus einen Flash-Player. Allerdings wird dessen Einsatz derzeit noch stark eingeschränkt. Es gibt laut einem aktuellen Artikel in der Zeitschrift c’t [hei09g] noch keinen Internet-fähigen Fernseher, dessen Internetbrowser bereits ein Flash-Plugin enthält. Aber nur durch diese Kombination ließen sich wirklich alle aktuellen Flash-basierten Dienste nutzen. Aber der Anfang ist gemacht und es ist absehbar, dass bald auch das Flash-Video von (Live)-Streaming-Diensten abrufbar sein wird.

Flash bietet zur dynamischen Bandbreitenanpassung folgenden Ansatz an, um eine erstklassige Darstellungsqualität beim Streaming zu erreichen. Dabei wird mit der neuen Funktion für dynamisches Streaming die Qualität während der Übertragung überwacht. Änderungen an der Bandbreite werden automatisch erkannt, sodass auch während der Wiedergabe nahtlos zwischen Streams mit unterschiedlicher Bandbreite gewechselt werden kann. Dieses „dynamische Streaming“ unterstützt die Standards „H.264“ und „On2-VP6“ (siehe Kapitel 2.8.5.4. „Codec-Lizensierungsbedarf“) und kann im Videoplayer mit entsprechenden „Actionscript“-Befehlen (siehe Glossar) gesteuert werden. Allerdings ist diese Funktion nur für Video-on-Demand verfügbar, d.h. für bereits aufgezeichnete Daten, die vom Server abgerufen werden und die dort bereits in den verschiedenen Auflösungen vorliegen müssen. Für eine Live-Übertragung ist diese Art der Bandbreitenanpassung nicht möglich.

Schlussendlich bietet Adobe mit „AIR“ [Ado09p] noch eine andere Alternative an. Zwar ist die dafür nötige AIR-Runtime noch lange nicht auf so vielen Rechnern installiert wie dies beim Flash-Player der Fall ist. Allerdings konnte bereits im Januar 2009 die Hürde von 100 Millionen Installationen genommen werden [Ado09m]. AIR erlaubt im Gegensatz zu Flash den direkteren Zugriff auf die Ressourcen des Computers. So können Dateien direkt vom Dateisystem gelesen und geschrieben werden. Längerfristig könnte sich AIR also zu einer Flash-Alternative entwickeln.

Sun Java Runtime

Die allgemeine Plattformübersicht sieht bei SUN’s Java-Projekt so aus wie in der folgenden Abbildung 13 gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Java Plattform [Sun09c]

Wie man in der Abbildung 13 erkennen kann existiert für nahezu jede Hardware-Plattform eine spezifische Version der Java-Plattform. Ebenso existieren für nahezu alle Betriebssysteme entsprechende Erweiterungen. Solange keine Plattform-spezifischen Funktionalitäten verwendet werden, ist eine Anwendung mit nur geringfügigen Anpassungen damit auf sehr vielen Plattformen und Endgeräten ablauffähig. Dies stellt einen sehr großen Vorteil von Java dar. Innerhalb der vielen vorhandenen Basisklassen existiert auch ein sogenanntes „Java Media Framework“, das entsprechende Multimedia-Funktionalitäten einheitlich zur Verfügung stellt. Die Abbildung 14 zeigt die grundlegende Architektur dieses Teils der Java-Umgebung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Grundlegende Architektur des Java Media Frameworks (JMF) [Sun99]

Das Hauptproblem dieses Frameworks liegt in seinem Alter. Seit einigen Jahren wurde nichts mehr daran weiterentwickelt. Das hat dazu geführt, dass die unterstützten Codecs und Videoformate nicht mehr zeitgemäß sind. Das ist schade, denn Java ist weiterhin auf recht vielen PCs vorhanden und so könnte das JMF die Möglichkeit bieten beliebig komplexe Player in Webseiten zu realisieren, die ohne eine Installation auskommen würden. Sun scheint „JavaFX“ [Sun09a] (eine neuere Entwicklung) als Nachfolger zu sehen, denn dort ist die Codec-Unterstützung wesentlich umfangreicher. Außerdem positioniert Sun JavaFX als direkte Konkurrenz zu Silverlight und Flash. In der folgenden Abbildung 15 wird der grundlegende Aufbau von JavaFX dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Architektur von JavaFX [Sun09a]

Allerdings konnte JavaFX bisher noch in keinster Weise am Markt Fuß fassen. Laut einem Blogeintrag [Too09] vom März 2009 fehlen JavaFX mehrere wichtige Elemente:

1. Fehlende Basis-Elemente zur schnellen RIA-Entwicklung, vor allem fehlen fortgeschrittene Dialogelemente.
2. Fehlende fortgeschrittene Unterstützung durch geeignete Softwarewerkzeuge, wie man es von Flash/Silverlight her kennt.
3. Definition einer neuen Scriptsprache, die erst aufwändig erlernt werden muss. Hätte man z.B. Java übernommen, hätten sich wenigstens die Java-Programmierer nicht umstellen müssen (und PHP/C# wäre auch ähnlich gewesen).
4. Vernachlässigung vieler Plattformen (Schwerpunkt war erst einmal Windows, erst in einem zweiten Schritt werden Linux, Macintosh u.a. nachgezogen). Hier wäre gerade wegen der breiten Verfügbarkeit von Java auf vielerlei Plattformen mehr möglich gewesen.

Kürzlich ist Anfang Juni 2009 die Version 1.2 erschienen, die einige der bisherigen Kinderkrankheiten ausräumt [hei09d]. Laut der eben zitierten Einschätzung von Lars Röwekamp [hei09d] positioniert sich die aktuelle Version als der „Java Presentation Layer“ für alle Plattformen, evtl. bald auch für das Fernsehen. Es wurden auch die bisher fehlenden Basiscontrols bereitgestellt und sinnvollerweise nicht nur auf PCs sondern gleich auf wirklich allen Plattformen, also einschließlich Mobiltelefonen. Allerdings ist die Unterstützung weiterhin unvollständig (vor allem im Vergleich zur Konkurrenz Flash oder Silverlight), da es z.B. immer noch keine Tabellenkomponente gibt. Laut diesem Bericht von der JavaONE-Konferenz, die Anfang Juni 2009 stattfand, wurde dort auch eine Demo von JavaFX auf einem Fernseher gezeigt (mit Hilfe des neuen „TV-Profils“). Damit war es möglich Zusatzinformationen zu einem Film abzurufen oder andere Zusatzdaten wie das aktuelle Wetter. Allerdings wurden zur Verfügbarkeit dieses „JavaFX TV“-Profils keine Angaben gemacht. Weiterhin wurde eine erste Alpha-Version eines JavaFX-Autorentools gezeigt, die bis Ende des Jahres verfügbar sein soll. Ebenso gibt es einen JavaFX-Store im Internet zum Anbieten eigener JavaFX-Anwendungen.

Es hat durchaus den Anschein als ob Sun direkt auf die Klagen der JavaFX-Entwicklergemeinde eingegangen wäre. Allerdings ist es aus heutiger Sicht zweifelhaft, ob es Sun gelingen kann den Vorsprung von Flash und selbst den von Silverlight wieder einzuholen. Denn selbst der Sprung auf den Fernseher ist nicht neu: Es werden – wie bereits erwähnt - derzeit bereits die ersten Flash-kompatiblen Fernseher ausgeliefert.

Für spezifische Anforderungen auf spezifischen Plattformen mag Java bzw. JavaFX noch zeitgemäß sein (z.B. um in einem Internet-Browser gewisse Aktionen durchführen zu können die mit Flash aus diversen Gründen nicht möglich sind), als grundsätzliche Entwicklungs-Plattform liegt es derzeit allerdings noch weit hinter der Konkurrenz zurück.

Microsoft Silverlight

In der folgenden Abbildung 16 wird eine Architekturübersicht der Version 2 dieses Browser-Plugins dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Architektur von Microsoft Silverlight V2 [Mic09e]

Ein klarer Vorteil liegt in der ab Version 2 hinzugekommenen Möglichkeit, Silverlight-Anwendungen direkt in einer der durch das .NET-Framework unterstützten Sprachen zu programmieren. Gleichzeitig werden aktuelle Techniken wie Ajax und JavaScript im Allgemeinen auch direkt unterstützt.

Allerdings hat Microsoft eine vielleicht bahnbrechende Streaming-Technik mit dem Namen „Smooth-Streaming“ [Mic09a] spezifiziert, die dank der Öffnung des Protokolls bereits von anderen Servern unterstützt wird. Da diese wesentliche Mängel des bisherigen Streamings behebt und sogar im gewissen Rahmen eine Lösung für die Multicast-Problematik (siehe Kapitel 2.8.3 „Distributionstechniken“) bietet, wird dieser neue Ansatz im Kapitel 2.8.2.5 „Adaptives Streaming“ genauer beschrieben. Es ist durchaus möglich, dass dieser Ansatz die anderen Streaming-Protokolle längerfristig ablösen wird. Einem Bericht [Gut08] zufolge hat das holländische „Web Designer Magazine“ in der Ausgabe von August 2008 einen Leiter des Nationalen Olympischen Komitees mit der Aussage zitiert, dass bereits mit 40 Windows-Servern und „Smooth-Streaming“ 100.000 gleichzeitige Zuschauer bedient werden konnten, während es für diese Zahl etwa 270 Flash-basierte Server gebraucht hätte.

Derzeit ist allerdings clientseitig nur ein auf Silverlight basierender Player in der Lage einen solchen „Stream“ zu empfangen. Hierbei wird eine wichtige Besonderheit am Architekturkonzept des Silverlight-Plugins deutlich: Anstatt die Streaming-Protokollunterstützung direkt in das Basis-Framework zu integrieren, hat Microsoft diese in eine extra .NET-Klasse ausgelagert [Zam09]. Dazu ein offizielles Zitat:

„Extensible media format support. With the new Raw AV pipeline, Silverlight can easily support a wide variety of third-party codecs. Audio and video can be decoded outside the runtime and rendered in Silverlight, extending format support beyond the native codecs.“ [Mic09c]

Dadurch wird es für Entwickler möglich, neue Protokolle in Silverlight zu unterstützen ohne auf das nächste offizielle Update warten zu müssen. Da das „Smooth-Streaming-Protokoll“ ein offener Standard ist, kann man durchaus annehmen, dass bald Flash-basierte Player auch in der Lage sein werden, derartige Streams zu empfangen.

Die folgende Abbildung 17 enthält bereits die Neuerungen von Silverlight Version 3. Diese Version wurde erst im Juli 2009 offiziell freigegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Architektur von Silverlight Version 3 [Mic09e]

Man erkennt im Vergleich zur vorhergehenden Grafik die neu hinzugekommene Unterstützung für die Videoformate „H.264“ und „AAC“ (siehe Glossar) sowie eine Funktionalität namens „Deep Zoom“ [Mic09p], die das dynamische Nachladen zum effizienten Betrachten von Bildern in hoher Qualität ermöglicht.

Aus unverständlichen Gründen hat auch diese neueste Version noch keine Webcam-Unterstützung (siehe Glossar). Flash bleibt von daher immer noch (abgesehen von Java mit dem veralteten JMF) die einzige Technologie mit der man aus dem Webbrowser heraus ein Audio- und ein Video-Signal zu einem Internet-Server streamen kann.

Microsoft hat bisher Mühe mit seiner Client-Technologie am Markt Fuß zu fassen. Bislang gibt es nur wenige Webseiten, die auf der Basis von „Silverlight“ realisiert sind. Selbst mit Marketingmacht, z. B. wurden die Olympischen Spiele in Peking „exklusiv“ über Silverlight ins Internet gestreamt, so dass jeder den Player in seinem Webbrowser dafür installieren musste, konnte noch keine weite Verbreitung erreicht werden (siehe dazu die folgende Abbildung 18, die graue Fläche bedeutet dabei „nicht installiert“).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Installierte Plugins im Vergleich (Links: Flash, Mitte: Silverlight, Rechts: Java) [ria09]

Auch wenn diese Zahlen etwas von der Übersicht im einleitenden Abschnitt dieses Kapitels in Abbildung 11 abweichen, so ist doch Flash eindeutig überlegen. Auch im Vergleich zu Java liegt Silverlight noch weit zurück. Theoretisch wäre Microsoft über den in allen Windows-Versionen enthaltenen automatischen Update-Mechanismus in der Lage „über Nacht“ die Anzahl der PCs mit installiertem Silverlight-Plugin zu verdoppeln, wenn nicht gar zu verdreifachen. Diese Möglichkeit wurde vor kurzem genutzt um nahezu alle installierten Internet Explorer auf die aktuelle Version 8 upzugraden. Da gerade noch ein Verfahren der EU gegen Microsoft im Bezug auf die exklusive Integration des Internet Explorers im Windows-Betriebssystem läuft und von daher in der europäischen Variante von „Windows 7“ [Mic09q] wahrscheinlich unter mehreren Browsern ausgewählt werden kann, wird Microsoft derzeit eher vorsichtig sein und nicht kurzfristig Silverlight „automatisch“ auf allen Windows-Rechnern installieren. Laut einem aktuellen Artikel auf „heise Developer“ [hei09i] sieht selbst Microsoft deshalb derzeit den primären Einsatz von Silverlight im Rahmen von Intranets (siehe Glossar). Dort ist es für den Administrator einfach, das Vorhandensein des Silverlight-Players sicherzustellen.

Trotzdem muss der Konkurrenzkampf zwischen Flash und Silverlight längerfristig weiter beobachtet werden.

HTML5 mit neuer <video>-Auszeichnung

An dieser Stelle sollen nur die aktuellen Neuerungen erörtert werden, die im Bezug auf das Projekt interessant sind. Für eine vollständige Übersicht sei auf die offizielle Spezifikation verwiesen [W3C09a].

Zur Darstellung von Videos in einem Internetbrowser ist bisher zwingend der Einsatz eines Plugins bzw. einer nativen im System vorhandenen Abspielsoftware erforderlich. Auf Windows-Rechnern greift z.B. der Internet Explorer in der Regel auf den in jeder Windows-Installation vorhandenen „Windows Media Player“ zurück, wenn im Browser ein Video angezeigt werden soll. Entsprechende Verknüpfungen (z.B. anhand der Dateiendungen) in der Konfiguration des Internetbrowsers bewirken, dass dieser die eine oder andere Software zum Abspielen einer entsprechenden, eben über das Internet empfangenen (Video-)Datei verwendet wird. Leider gibt es hier bisher keinen Standard, nahezu jede Abspielsoftware unterstützt nur einen Teil der verwendeten Formate und Codecs.

Hier soll die mit HTML Version 5 eingeführte <video>-Auszeichnung Abhilfe schaffen [W3C09b]. Es genügt dazu die abzuspielende Videodatei im HTML-Code einzubetten:

<video src="http://www.meinserver.com/mein_video.wmv">

Ihr Internetbrowser unterstützt leider kein direktes Video.

</video>

Ein mit HTML5 kompatibler Internetbrowser würde in diesem Fall das Video direkt anzeigen (es stehen weitere Parameter z.B. für Größe usw. zur Verfügung), ein nicht kompatibler Browser würde stattdessen den angegebenen Text „Ihr Internetbrowser unterstützt leider kein direktes Video.“ anzeigen. Derzeit arbeiten praktisch alle heute marktrelevanten Browser-Hersteller (außer Microsoft) an einer Unterstützung in ihrer kommenden Version [bui09]. Dies lässt auf eine breite Unterstützung hoffen. Allerdings ist damit immer noch nicht das rechtliche Problem der unterstützten Codecs gelöst. Firefox [Moz09] wird in der Version 3.5 nur Theora (siehe Glossar) unterstützen, während Chrome [Goo09c] in Version 3.0 auch zusätzlich das derzeit wesentlich weiter verbreitete Format H.264 unterstützen will. Allerdings muss dafür der Hersteller des Internetbrowsers - in diesem Fall also Google – erhebliche Lizenzzahlungen an das MPEG-LA-Konsortium [MPE09] leisten, da das H.264 Format patentiert ist (näheres zu Codecs und Lizenzen siehe Kapitel 2.8.5.4 „Codec-Lizenzierungsbedarf“).

Inzwischen haben schon verschiedene Anbieter großer Video-Austausch-Webseiten angekündigt in den nächsten Monaten eine Vielzahl der bei ihnen gehosteten Videos auf diese Weise anbieten zu wollen, so z.B. „Dailymotion“ [dai09].

Ein nicht zu vernachlässigender Vorteil dieses Ansatzes ist eine direkte Integration des Videos mit den anderen Elementen wie JavaScript, HTML und Bildern in derselben Webseite. Die weitreichenden Möglichkeiten werden von Paul Rouget in einer erstaunlichen Demonstration auf Basis von Firefox 3.5 gezeigt [Nit09]. Da die hier gezeigten Möglichkeiten für das Projekt sehr relevant sind, sollen hier einige der Erläuterungen gezeigt werden. Dazu wurde die neueste Version des Firefox-Browsers installiert und die entsprechende Demo-Seite [Rou09] besucht. In der folgenden Abbildung 19 ist ein Screenshot dieser Demonstration zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: Dynamische Videomanipulation direkt im Internetbrowser mit JavaScript [Rou09]

Das Video auf der linken Bildseite wird ohne Plugin abgespielt. Allerdings geschieht dies im Hintergrund während JavaScript es Bild für Bild in den hier gezeigten Rahmen kopiert. Dabei wird der Bildinhalt analysiert und die beiden weißen Quadrate lokalisiert. Rechts kann der Anwender ein beliebiges einzufügendes anderes Webseiten-Element auswählen: ein anderes Video, ein Bild, eine kleine Animation, einen Text oder ein selbstgemaltes Bild. Dieses wird dann entsprechend den Bewegungen zwischen die beiden Quadrate hineinskaliert. Und dies alles nur unter Verwendung von JavaScript und HTML5.

Bei einer Einschätzung muss man auch bedenken, dass der HTML5-Standard noch nicht einmal endgültig verabschiedet worden ist. Nicht zuletzt deshalb wird HTML5 noch etwas Zeit brauchen um Techniken wie Flash und Silverlight abzulösen. Vergleiche hierzu beispielsweise [inf09], vieles hängt auch davon ab, ob Microsoft bald ebenfalls eine Unterstützung in den Internet Explorer integrieren wird. Aber es erscheint aus heutiger Sicht als realistisch, dass eines Tages jede beliebige (Video-)Webseite ohne diese Zusätze realisiert werden kann.

AJAX/DHTML

JavaScript – im Zusammenhang mit der Unterstützung des Befehls „XHTMLRequest“ wird oft von „AJAX“ gesprochen (siehe Glossar) – ist zusammen mit HTML4 derzeit immer noch der kleinste gemeinsame Nenner, wenn eine Webseite auf möglichst vielen Geräten korrekt dargestellt werden soll, da dabei keinerlei Plugins installiert werden müssen. Allerdings gibt es hier keine Videounterstützung, weshalb für den im Projektrahmen benötigten Player selbst diese Technik nicht in Frage kommt. Allerdings bietet es sich an, die Webseite zur Programmverwaltung auf dieser Basis zu implementieren. Manche Internetnutzer haben allerdings selbst zu JavaScript kein Vertrauen. Allerdings ist es nahezu unmöglich ohne Einsatz von JavaScript eine interaktive Webanwendung zu realisieren. Deshalb wird JavaScript an dieser Stelle vorausgesetzt.

Der Nachteil ist aber, dass im Normalfall Anpassungen an die verwendeten Webbrowser nötig sein werden, da die meisten gängigen Webbrowser nicht ganz standardkonform zu den offiziellen Empfehlungen zur korrekten Interpretation von HTML, CSS (siehe Glossar) und Javascript sind. Daher sollte ein geeignetes Framework verwendet werden, das einem diese zeitaufwändige Anpassungsarbeit abnimmt.

Streaming-Protokolle

Bevor die gängigen (Video-)Distributionstechniken betrachtet werden, also auf die Architektur und dem Zusammenspiel der an der Verteilung des Signals beteiligten Server eingegangen wird, soll an dieser Stelle ein kurzer Einblick über gebräuchliche Protokolle, also dem Aufbau des Signals selbst gegeben werden d.h. nach welchem Verfahren die „Bits und Bytes“ weitergeleitet werden.

RTP/RTSP

In der folgenden Abbildung 20 kann man die im Allgemeinen beteiligten Protokolle für die Mediendaten selbst (IP/UDP/RTP) sowie den Kontrollkanal (IP/TCP/RTSP) erkennen (für eine Erklärung der genannten Protokolle siehe Glossar):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: Streaming Protokoll-Stack [Aus05]

RTSP agiert dabei als traditionelles Streaming-Protokoll. Es ist definiert als ein verbindungsbehaftetes Protokoll (über TCP). Vom ersten Verbindungsaufbau eines Clients beim Server bis zum definitiven Beenden der Verbindung überwacht der Server den Zustand des Clients. Der Client schickt Zustandsänderungen zum Server, wie z.B. „Abspielen“, „Pause“ usw. Wie in der vorherigen Abbildung 20 gezeigt werden die Videodaten meist über ein verbindungsloses Protokoll (RTP/UDP) in der Form einer Serie von vielen kleinen Datenpaketen geschickt.

RTMP

Grundsätzlich ist festzustellen, dass die Spezifikationen dieses Protokolls derzeit nicht offiziell vorliegen, allerdings hat die Firma Adobe bereits im Januar 2009 angekündigt, die Spezifikationen des Basisprotokolls RTMP (siehe folgende Liste) in der ersten Hälfte von 2009 zu veröffentlichen [Ado09a]. Dies ist am 16. Juni 2009 geschehen. Man kann deshalb davon ausgehen, dass in der nächsten Zeit viele Frameworks dieses Protokoll aufnehmen werden und die derzeitigen Kompatibilitätsprobleme der Frameworks, die bisher dieses Protokoll unterstützt haben, bald korrigiert sein werden. Die Kompatibilitätsprobleme sind dadurch entstanden, dass die Spezifikationen durch Reverse-Engineering aufwändig „ausgetüftelt“ werden mussten.

Das Protokoll funktioniert allerdings nach dem gleichen Prinzip wie RTSP. Interessant sind die vielen Möglichkeiten das Protokoll zu verwenden:

1. RTMP direkt auf Basis TCP/IP (verwendete Ports: 1943, 443, 80)

2. RTMPT auf Basis HTTP (siehe Glossar), um Firewalls (siehe Glossar) zu überwinden

(Port: 80)

3. RTMPS auf Basis HTTPS/SSL für sichere Verbindungen (Port: 443)

4. RTMPE Verschlüsseltes RTMP (Ports: 1935, 443, 80)

5. RTMPTE Verschlüsseltes RTMP, getunnelt über HTTP (Port: 80)

Durch die Möglichkeit einer Tunnelung über HTTP trägt das Protokoll den gestiegenen Anforderungen Rechnung. Denn es macht z.B. für eine Firma die nur Geschäftskunden bedient keinen Sinn ein mit einem Flash-Player anzeigbares Business-TV zu produzieren, dass dann von nahezu allen Firmen-Firewalls geblockt werden wird.

Prinzipiell verbietet Adobe jedes Mitschneiden eines über RTMP empfangen Videostreams auf der Client-Seite. Kürzlich ist Adobe deshalb auch gegen ein entsprechendes Open-Source-Tool gerichtlich vorgegangen [hei09c]. Die Entwickler hatten dabei sogar die verschlüsselte Variante erfolgreich analysieren können (RTMPE). Das Ergebnis dieser Analyse ist eine Blamage für Adobe. Sie zeigt laut [hei09c], dass es sich nur um eine End-to-End-Verschlüsselung handelt (wie bei SSL), aber keinerlei Sicherheit oder Authentifizierung bietet. Es wird dabei gar kein richtiger Schlüssel zum Entschlüsseln benötigt, es fließen nur ein Hash-Wert der Daten und öffentlich zugängliche Parameter ein.

Zitat aus [hei09c]: „Dieser Argumentation folgend könnte man zu dem Schluss kommen, dass es sich bei RTMPE nur um ein proprietäres Streaming-Protokoll mit verschlüsselter Übertragung handelt. Es erscheint zumindest fragwürdig, ob sich Adobe damit noch auf Kopierschutzumgehung und somit auf den DMCA berufen könnte, um die Verbreitung der Software zu unterbinden. Gegenüber seinen Kunden – darunter TV-Sender und Filmstudios –, die zur DRM-geschützten Verteilung ihrer Inhalte zunehmend auf RTMPE setzen, dürfte Adobe allemal in Erklärungsnot geraten.“

Eine weitere interessante Erweiterung ist die Möglichkeit allgemeine Daten unabhängig von dem Stream mit Audio- und Video-Daten (kurz: „AV-Daten“) zum (Flash)-Client (und zurück) zu übertragen. Dafür wird eine dauerhaft bestehende Verbindung zwischen Client und Server aufgebaut über die nach dem „Publish-Subscribe“-Prinzip (genauer gesagt über Events) (siehe Glossar) Daten in beiden Richtungen ausgetauscht werden können. Dies wird in der folgenden Abbildung 21 illustriert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Typische Kommunikation zwischen Flash-Client und Flash Interactive Server [Ado09g]

1. Die Flash-Anwendung (im kompilierten Format SWF) wird vom Webserver zum Client über einen normalen HTTP-Download übertragen.
2. Im Client wird sie vom Flash-Client-Plugin innerhalb des Webbrowsers gestartet.
3. Die Flash-Anwendung nimmt Kontakt zum Flash Media Server auf und es findet ein Session-orientierter Datenaustausch statt (z.B. Flash-Anwendung empfängt AV-Daten, sendet Kommandos und oder AV-Daten an den Server zurück, letzteres z. B. im Fall einer Chatanwendung)

Die Adobe Flash Plattform verfügt mit den vorgestellten Protokollen über effiziente Mechanismen zur Verteilung von Medienstreams und wird deshalb aktuell häufig für Streamingzwecke eingesetzt. Besonders die Möglichkeit Daten mit in den Medienstream einzubetten ist sehr interessant.

RTMFP (Real Time Media Flow Protocol) mit Adobe Stratus

Hierbei handelt es sich um ein relativ neues Protokoll, dass derzeit nur in Adobe’s Flash-Player-Clients ab Version 10 (die derzeit neueste Version, diese ist bereits auf über 70% aller PCs installiert, siehe Abbildung 12) verfügbar ist. Zusammen mit dem neuen Peering-Service namens Stratus (dessen Funktionsweise im Folgenden kurz erklärt wird) können auf diese Weise zwei Flash-Clients direkt miteinander kommunizieren, ohne über einen Flash-kompatiblen Server zu gehen. In der folgenden Abbildung 22 ist dies schematisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22: Flash Stratus-Server [Ado09k]

Zwei Flash-Clients können auf folgende Weise eine Direktverbindung zum Austausch von Audio/Video-Streams sowie von Daten aufbauen:

1. Flash-Client A verbindet sich mit dem Adobe Stratus-Dienst. Dabei wird Flash-Client A eine eindeutige ID-Kennung zugeteilt.
2. Damit sich jetzt Flash-Client B mit Flash-Client A direkt verbinden kann, braucht dieser die Kenntnis dieser eindeutigen ID-Kennung von A. Diese kann z.B. über einen Flash-kompatiblen Server ausgetauscht werden.
3. Flash-Client B kann nun mit dem Wissen der ID-Kennung von Flash-Client A eine direkte Verbindung mit diesem aufbauen und direkt die besagten Daten austauschen.
Auf diese Weise kann serverseitig viel Bandbreite gespart werden. Um ein größeres P2P-Verteilnetz (wie z.B. beim P2P-Video-Streaming) aufzubauen sind allerdings noch weitaus umfangreichere Komponenten nötig. Dies wird in den folgenden Kapiteln noch genauer erörtert. Da aus Effizienzgründen die Direktverbindung mit dem nicht verbindungsbehafteten UDP-Protokoll erfolgt, kann sie teilweise von Firewalls geblockt werden. Sollte dies der Fall sein, dann ist als Fallback-Variante der „reguläre“ Weg über einen Flash-kompatiblen Server über RTMP/TCP (wie im vorherigen Kapitel 2.8.2.2 „RTMP“ besprochen, am besten über eine Variante die nur den Standardport 80 benutzt) zu wählen. In der folgenden Abbildung 23 wird dies veranschaulicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: Vergleich RTMP und RTMFP (P2P-Protokoll) [Ado09k]

Zu beachten ist, dass im linken Bild der Abbildung 23 die Verbindung über den als „FMS“ (Flash Media Server – siehe Kapitel 2.8.6.1 „Flash Media Interactive Server“), also einen „Flash-kompatiblen“ Server geschieht, während dieser Server im rechten Bild der Abbildung 23 in Form des Stratus-Server-Dienstes von Adobe nur für die Verbindungs-Vermittlung zuständig ist. Der eigentliche Datenaustausch geschieht dann direkt von Flash-Client zu Flash-Client.

Laut einer Erläuterung von Adobe zu diesem Thema [Ado09l] kann dieses Protokoll nicht für Multicast (siehe Kapitel 2.8.3.3 „Aufsplitten des Streams auf Routerebene - Multicast“) und auch nicht zur Übertragung von Video in hoher Qualität genutzt werden. Angeblich sollen nur die mit einem PC direkt verbundenen Video/Audio-Geräte unterstützt werden. Um auf Basis dieser relativ einfachen Technologie ein P2P-Video-Streaming-Netz aufzubauen wäre deshalb noch eine zusätzliche, auf den Clients zu installierende Software notwendig. Diese müsste in der Lage sein, einen über RTMFP empfangenen AV-Stream wieder auf eine virtuelle Webcam weiterzuleiten, um diesen dann wieder weiterschicken zu können. Damit ließe sich ein „hybrider“ Ansatz (siehe Kapitel 2.8.3.6 „Hybride Technologien“) direkt im Flash-Client realisieren. Ein auf jeden Fall interessanter Aspekt dieser Funktionalität ist, dass es so z.B. möglich wird, dass sich Zuschauer desselben Fernsehkanals direkt miteinander unterhalten können ohne dabei (teure) Serverbandbreite zu beanspruchen.

Progressiver Download

Dies ist heute die am meisten verwendete Form des „Streamings“. Streng genommen ist dies überhaupt kein „Streaming-Protokoll“, sondern ein ganz normaler Download einer Datei von einem beliebigen Webserver wie Apache [Apa09] oder Internet Information Server (IIS) [Mic09r]. Diese Art des Empfangs der (Video-)Daten wird von allen existierenden Video-Playern unterstützt, sei es der Windows-Media-Player, der Flash-Player, Silverlight und viele andere. Der Ausdruck „progressiv“ rührt daher, dass die meisten Player bereits das Abspielen der Videodatei erlauben, bevor die gesamte Videodatei zum Client heruntergeladen und lokal gespeichert wurde. Ab der Spezifikation HTTP 1.1 ist es auch möglich eine Position in der Videodatei anzuspringen, die noch nicht heruntergeladen worden ist (sofern der Webserver dies unterstützt). Dafür kann in „Byte“ ein Bereich der herunterzuladenden Datei spezifiziert werden (dieselbe Funktion kann auch genutzt werden um einen abgebrochenen Download fortzusetzen).

Im Gegensatz zu Streaming-Servern, die max. 10 Sekunden des Videos im Voraus verschicken (es wird dabei immer nur soviel verschickt, wie der Client braucht, damit das Video ohne Unterbrechung weiter angezeigt werden kann), hört ein HTTP-Server nicht auf zu Senden bis die gesamte Datei beim Client angekommen ist. Wenn der Nutzer also bei einem Video mit der Länge von 10 Minuten bereits nach 60 Sekunden auf die „Pause“-Taste drückt, wird das Video in der Folge trotzdem komplett heruntergeladen. Daraus folgt, dass wenn der Nutzer dann das Video gar nicht zu Ende schauen möchte, 9 Minuten des Videos umsonst heruntergeladen worden sind. Eine Verschwendung der Bandbreite für die in der Regel der Anbieter des Videos unnötig bezahlen muss.

Um dies zu verhindern werden seit einigen Jahren Techniken wie die Drosselung der Bandbreite im Webserver realisiert, was den Client das Video nur so schnell herunterladen lässt wie es nötig ist um es flüssig anschauen zu können. Aber das löst nicht das Prinzip-Problem. Bei dieser Technik ist es auch unmöglich die Videoqualität an die aktuelle Qualität (Bandbreite) der Internetverbindung anzupassen. Es existiert in der Regel nur eine Videodatei mit einer bestimmten Bitrate (siehe Glossar).

Adaptives Streaming

In den letzten Jahren ist laut [Zam08] verstärkt der Trend weg von den „klassischen“ Streaming-Protokollen (siehe Kapitel 2.8.2.1 „RTP/RTSP“ und Kapitel 2.8.2.2 „RTMP“) hin zu normalem HTTP-Download („Progressive Download“, wie im letzten Abschnitt erläutert). Ein typisches Beispiel dafür ist die Webseite „youtube.com“ [you09]. In seinem eben zitierten Blogeintrag führt Zambelli die Gründe für diesen Trend auf:

1. Download-Dienste sind in der Regel preislich günstiger als Streaming-Dienste.
2. Die klassischen Streaming-Protokolle bereiten oft Probleme mit Firewalls, da sie spezielle Ports benötigen, während HTTP auf Port 80 überall funktioniert.
3. Für die Auslieferung über HTTP werden keine speziellen Proxys (siehe Glossar) und keine speziellen Zwischenspeicher benötigt. Es wird jeder normale Zwischenspeicher, der auch für gewöhnliche Webseiten ausgelegt ist, funktionieren.
4. Über HTTP können die Daten wesentlich günstiger über das Netzwerk zum Endverbraucher geleitet werden, dies gilt generell und im Besonderen wenn ein CDN (siehe Glossar) verwendet wird.

Obwohl die Streaming-Protokolle natürlich für den Transport von Videodaten geschaffen worden sind basiert das Internet im Allgemeinen auf HTTP. Von daher liegt der Gedanke nahe, dass es besser ist den Streaming-Vorgang an HTTP anzupassen, anstatt das gesamte Internet umzustellen um die Streaming-Protokolle gut unterstützen zu können.

Microsoft hat seine konkrete Implementierung dieses Ansatzes als „Smooth-Streaming“ bezeichnet, weshalb dieser Begriff in der Folge alternativ zum grundlegenden Begriff des „adaptiven Streaming“ benutzt wird.

Streng genommen handelt es sich beim adaptiven Streaming gar nicht um Streaming aber auch nicht um „normalen Download“. Es ist eine Mischform beider Techniken, denn es verhält sich wie Streaming, basiert aber in Wirklichkeit auf dem progressiven Download. Es handelt sich um eine Serie von progressiven Downloads von Videofragmenten variabler Größe. Es existiert heute kein Standard dafür, denn es handelt sich um eine Art „fortgeschrittener Download“. Die prinzipielle Idee existiert schon seit Längerem, auch in verschiedensten Implementierungen. Microsoft hat hier jetzt wahrscheinlich die Möglichkeit einen Standard zu etablieren, da noch zusätzlich das Problem der variablen Bandbreite einer Verbindung und damit die Notwendigkeit verschiedene Qualitäten ein- und desselben Videos vorrätig zu halten, vernünftig gelöst worden ist.

Auf der Seite des Webservers wird das Quellvideo in meist zwei bis vier Sekunden lange Abschnitte aufgeteilt, sog. „Chunks“, und anschließend mit dem gewünschten Codec kodiert und auf dem Webserver in einer oder mehreren Dateien vorgehalten. Ein Client lädt diese Chunks jetzt linear einen nach dem anderen über normalen progressiven Download herunter, indem ein Chunk nach dem anderen über einen normalen Download-Befehl angefordert wird. Anschließend setzt er diese wieder zusammen und kann so das Video flüssig abspielen. In der folgenden Abbildung 24 werden die drei gängigsten Varianten im Bild gegenübergestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 24: Der neue Smooth-Streaming-Ansatz von Microsoft mit Silverlight 3 [Mic09a]

Falls vom Ausgangsvideo für jeden Abschnitt mehrere Chunks unterschiedlicher Qualität (Bitrate) kodiert worden sind, kann die adaptive Eigenschaft zum Tragen kommen. Der Client kann relativ leicht messen wie lange der Download eines Chunks gerade benötigt und kann so (wenn die Bandbreite es zulässt) den nächsten Chunk in einer höheren Auflösung anfordern. Nimmt die Bandbreite wieder (temporär) ab, wird der Client wieder Chunks in niedrigerer Auflösung anfordern (downloaden). So kann sich die Qualität ständig an die effektiv vorhandene Bandbreite anpassen. Im Client wird so jegliches Stocken und Aussetzen/Pausieren des Bildes vermieden, nur die Bildqualität kann zwischenzeitlich schlechter werden. Für den Benutzer ist dies aber eindeutig das geringere Übel, vor allem bei Live-Übertragungen, da hier ein einmal „verpasstes“ Stück der Übertragung nicht wieder nachgeholt werden kann. Dieser Vorgang wird in der folgenden Abbildung 25 beispielhaft dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 25: Automatische Bitratenanpassung in Real-Time [Mic09a]

Entsprechend dem bisher Ausgeführten kann nicht nur die Bandbreite variieren, sondern auch die Fähigkeit des Prozessors im Client die empfangenen Videodaten wieder zu dekodieren. Gerade bei den neuesten Codecs (wie z.B. H.264) ergeben sich hohe Anforderungen an die Prozessorleistung im Client, da die Videodaten sehr effektiv komprimiert worden sind. Es macht hier keinen Sinn, ein Video in sehr guter Qualität auf ein Handy zu streamen, nur weil dieses über eine sehr schnelle Internetanbindung verfügt, wenn dieses nicht in der Lage ist, es im zur Verfügung stehenden Zeitfenster wieder zu dekodieren. Bei Überlastung muss auch hier die Qualität automatisch gedrosselt werden um dem Nutzer ein flüssiges Betrachten zu erlauben. Dieser Sachverhalt wird in der nächsten Abbildung 26 veranschaulicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 26: Warum auf der letzten Meile eine dynamische Bandbreitenanpassung wichtig ist [Mic09a]

Zusammenfassend kann man sagen, dass das adaptive Streaming (wie andere Formen der Auslieferung von Daten über HTTP) für den Anbieter der Inhalte die folgenden Vorteile bietet:

1. Es ist mit vergleichsweise geringeren Kosten umzusetzen, da jeder allgemeine HTTP-Cache oder Proxy-Server verwendet werden kann und keine spezialisierte Streaming-Hardware an jedem Knoten benötigt wird.
2. Die Skalierbarkeit und die Reichweite sind besser, weil es sich so optimaler an schlechtere Übertragungsbedingungen (Bandbreiten) anpassen kann.
3. Die Qualität der Inhalte passt sich dynamischer an die Erfordernisse der Zuschauer an. Der Anbieter muss nicht im Vorfeld mit einer groben Schätzung die voraussichtlich benötigte durchschnittliche Qualität festlegen. Die Ergonomie wird wesentlich verbessert, da der Benutzer nicht mehr zwischen einer „schlechten“, „mittleren“ und „hohen Qualität“ auswählen muss, zumal er sich dabei auch irren kann und dadurch dann wieder erst Recht unter den Bildaussetzern und ähnlichem leidet.
4. Das Verhalten der Zuschauer kann leichter protokolliert werden, z.B. wer hat welches Video wie lange angeschaut mit welchen Sprüngen usw.

Gleichzeitig bietet dieses Konzept für den Benutzer die folgenden Vorteile:

1. Das Video beginnt unmittelbar abzuspielen, da es mit der niedrigsten Qualität beginnen kann bevor es (wenn die Verbindung gut ist) die Qualität nach und nach steigern kann.
2. Keine Pausen durch Pufferungen, keine Verbindungsabbrüche, keine ruckelnde Wiedergabe solange der Benutzer eine ausreichende schnelle Verbindung besitzt um die niedrigste Bitrate stabil empfangen zu können.
3. Reibungsloses Wechseln der Bitrate je nach den Netzwerkbedingungen und der Geschwindigkeit des verwendeten Gerätes.

Die bisher angesprochenen Elemente gelten für alle Verfahren, die adaptives Streaming verwenden. Im Folgenden soll noch kurz auf die konkrete Implementierung durch Microsoft im sogenannten „Smooth-Streaming“-Verfahren eingegangen werden.

Microsoft verwendet dafür erstmals nicht mehr ASF [Mic09s] als Containerformat sondern das allgemein standardisierte Containerformat MP4, weniger bekannt unter ISO/IEC 14496-12 ISO (siehe Glossar), und als Codec den ebenso weit verbreiteten Codec H.264. Das Containerformat MP4 konnte standardkonform so erweitert werden, dass in jeweils einer Datei die Video-Fragmente („Chunks“) einer Video-Bitrate (entspricht verschiedenen Qualitäten) untergebracht werden können. So wird der serverseitige Aufwand für das Videodateimanagement minimiert. Für Details wird auf das offizielle technische Dokument verwiesen [Mic09b].

Microsoft stellt die dafür nötige serverseitige Implementierung offiziell nur als eine Erweiterung für den neuesten Windows Server 2008 [Mic09l] und den Internet Information Server (IIS) 7.0 [Mic09r] zur Verfügung. Inzwischen hat allerdings dank der offenen Spezifikation bereits ein Dritthersteller die Unterstützung für ältere IIS-Versionen nachgeschoben [Cod09]. Außerdem gibt es mit dem „Wowza Media Server“ [Wow09] (neueste Version derzeit noch Beta) schon mindestens eine Alternative die auf den gängigen Plattformen (Windows, Mac, Linux) zur Verfügung steht und auch das Smooth-Streaming-Verfahren beherrscht. Dieser Server wird in Kapitel 2.8.6.2 „Wowza Media Server“ noch genauer vorgestellt und bewertet. Selbst für den gängigsten Webserver weltweit, Apache [Apa09], ist bereits ein entsprechendes Modul verfügbar [Cod09].

Ein Problem stellt derzeit allerdings noch die Verfügbarkeit geeigneter Encoder. Grundsätzlich ist ein Encoder ein Programmteil, der ein Ausgangsvideo mit einem Codec komprimieren kann. In diesem Fall muss dieser in der Lage sein, ein gegebenenfalls hochaufgelöstes Live-Videosignal in die verschiedenen Bitraten zu konvertieren und dann zum sogenannten „Publishing-Point“ (engl. für Veröffentlichungsort) auf dem IIS (oder einem anderen kompatiblen Server) zu schicken, damit es dort von den Clients wieder abgerufen werden kann. Derzeit ist hier erst eine Hardwarelösung verfügbar, in Form einer Streaming-Komplettlösung (einer sog. „Appliance“ – siehe Glossar) namens „Spinnaker“ [inl09]. Dabei können mehrere dieser Appliances parallel laufen um möglichst viele verschiedene Bitraten anbieten zu können und so dem Zuschauer eine möglichst optimale Qualität angepasst an seine Bedürfnisse liefern zu können. Natürlich kann ein derartiger für eine Aufgabe optimierter „Server-in-the-box“ den Stream auch noch in anderen Formaten auf andere Geräte schicken, wie z.B. auch in der folgenden Abbildung 27 zu sehen auf Handys.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 27: Live-Smooth-Streaming mit der Video-Streaming-Appliance "Spinnaker" der Firma inlet [inl09]

Dabei handelt es sich allerdings um eine äußerst professionelle Lösung was auch im Preis von ca. 8.000 EUR für die Einstiegsversion sichtbar wird. Es ist aber zu erwarten, dass bald andere Hersteller reine Software-Lösungen auf den Markt bringen werden. Die aktuelle Version der Software „Microsoft Expression Encoder“ [Mic09t] kann derzeit die nötige Umwandlung in verschiedene Bitraten nur für Video-on-Demand durchführen, nicht für Live-Streams. Diesen Sommer ist eine neue Version (3.0) erschienen, die allerdings diese Funktionalität (noch) nicht beinhaltet. Natürlich stellt eine reine Software-Lösung sehr hohe Ansprüche an die Leistung der Hardware. Die baldige Verfügbarkeit günstiger Software-Lösungen wird hier aber auch entscheidend davon abhängen, ob Microsoft die entsprechenden Spezifikationen schnell veröffentlichen wird oder nicht.

Insgesamt bietet dieser Ansatz jedoch deutliche Vorteile gegenüber den üblichen Streaming-Verfahren. Allerdings kann auf diesem Weg kein (interaktives) Feedback vom Anwender zurück zum Server übertragen werden. Zumindest dafür wird noch ein zustandsbehaftetes Protokoll benötigt.

Distributionstechniken

Nachdem die Protokolle kurz vorgestellt worden sind sollen hier die Distributionstechniken oder Arten und Weisen vorgestellt werden, einen solchen Datenstrom (engl. „Stream“) vom Quellrechner (in der Regel ist hier die Videokamera direkt oder indirekt angeschlossen) zum Zielrechner (Zuschauer) zu leiten.

Zum besseren Verständnis der folgenden Ausführungen wird in der nachstehenden Abbildung 28 das OSI-Schichtenmodell abgebildet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 28: OSI-Schichtenmodell nach [Neh85] bearbeitet von [FS08]

Daten die in der Abbildung 28 am „Arbeitsrechner A“ in der Anwendung („Anwendungsebene“) erzeugt werden, durchlaufen alle darunterliegenden Schichten. Über ein Übertragungsmedium und eine bestimmte Anzahl „Vermittlungsrechner“ (in der Regel sind dies „Router“), in der Abbildung 28 beispielhaft als „Vermittlungsrechner A“ und „Vermittlungsrechner B“ darstellt, gelangen diese zu „Arbeitsrechner B“, wo sie wieder alle Schichten durchlaufen, bis sie wieder in der Anwendungsebene (Ebene 7), also der entsprechenden Anwendung auf dem Zielrechner ankommen. Je nach Art und Weise der Weiterverteilung sind jeweils nur die unteren Ebenen oder aber alle Ebenen miteinbezogen. Auf dieses Schichtenmodell wird im Folgenden an mehreren Stellen Bezug genommen.

Direktverbindung Quelle (Server) – Ziel (Zuschauer)

Jedem Zuschauer steht hierbei ein individueller Datenkanal (engl. „Unicast“) direkt ab der Signalquelle zur Verfügung.

1. Weitverbreitet und einfach zu installieren (z.B. für Internetradio, kleine Videos auf Webseiten)
2. Standard-Browser können genutzt werden, keine spezielle Client-Software notwendig
3. aber: stark begrenzte Bandbreite und dadurch auch stark begrenzte Streamqualität, eine Skalierung ist sehr teuer, weil je nach Bedarf viele neue Server hinzugefügt werden müssen

Die folgende Abbildung 29 veranschaulicht das Prinzip.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 29: Unicast-Prinzip [FHH09a]

Verbindung über ein Server Grid/Cluster

Die Unicast Streams (siehe vorheriger Absatz) werden hierbei durch CDNs ausgeliefert (engl. „Content Delivery Networks“). Es gibt derzeit zwei „Global Player“ am Markt: „Akamai“ [Aka09] (20.000+ Server, 900 Stützpunkte, 71 Länder) sowie „Limelight Networks“ [Lim09] (25 Stützpunkte, hunderte Server pro Stützpunkt), allerdings können diese gemeinsam gerade einmal ca. 2,6 Millionen Zuschauer mit Internet-Fernsehen versorgen, gegenüber 2,5 Milliarden Zuschauern z.B. bei olympischen Spielen (Daten von Ji Li [Li07]). Auch wenn sich diese Zahlen seit der Erhebung im Jahre 2007 sicher etwas verbessert haben, so sind die Grenzen des Systems doch deutlich ersichtlich. Zudem lassen sich diese Anbieter die Nutzung Ihrer Dienste teuer bezahlen. In der letzten Zeit sind allerdings am Markt „Billiganbieter“ aufgetaucht, die im kleineren Rahmen Videostreams (und andere Daten) wesentlich günstiger verteilen können (vgl. „SimpleCDN“ [Sim09]). Dadurch wird für Videostream-Anbieter mit sehr begrenztem Budgetrahmen dieser Weg erst bezahlbar. Dies kann man sehr gut aus der folgenden Abbildung 30 entnehmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 30: Anbietervergleich der Kosten für Live-Streaming über ein CDN [Sim09]

Wie man erkennen kann variiert das Einsparpotential zwischen Faktor 7 bis 50. Für begrenzte Budgetrahmen und nur sporadisch zu übertragende Ereignisse, wie es auch im Fall dieses Projektes geplant ist, erweisen sich die monatlichen Mindestabnahmemengen, die hier nicht aufgeführt sind, oft als das eigentliche Problem. Auch diesem Bedarf kann „SimpleCDN“ durch den vollständigen Wegfall dieser Mindestabnahmemenge entsprechen.

Aufsplitten des Streams auf Routerebene (Multicast)

Hierbei wird auf Router-Ebene (siehe Glossar, im Bezug auf Abbildung 28) der Stream jeweils aufgesplittet, man könnte auch sagen „dupliziert“. Dadurch hat nicht jeder Teilnehmer eine eigene Verbindung zur Streamingquelle. Je mehr Teilnehmer am gleichen, entsprechend ausgerüsteten - dies wird im Folgenden noch näher besprochen - Router den gleichen Stream empfangen, umso effizienter wird das Verfahren. Bei einem weltweit verteilten, kleinen Teilnehmerkreis kann man nur wenig an Effizienz gewinnen. Dieses Prinzip wird in der folgenden Abbildung 31 illustriert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 31: Multicast-Prinzip [FHH09a]

Dieses Prinzip wird seit langer Zeit als der „ideale“ Verteilmechanismus angesehen, ursprünglich wurde es von Deering in [Dee91] laut Setton/Girod [SG07] vorgeschlagen. Allerdings sind im globalen Internet die Router immer noch nicht entsprechend ausgestattet. Laut Lui/Zhang [LZ08] gibt es dafür folgende Gründe:

1. Technische Gründe: IP Multicast setzt voraus, dass die Router einen Status innerhalb „ihrer“ Gruppe speichern, was nicht nur das statuslose Architekturprinzip verletzt, sondern auch eine hohe Komplexität und ernsthafte Skalierungsprobleme auf IP-Ebene mit sich bringt.
2. Wirtschaftliche Gründe: Es fehlt der Anreiz, in multicast-fähige Router zu investieren und dann auch die zugehörige Multicast-Bandbreite zu transportieren.
3. „Politische“ Gründe: Traditionell sind „Routing“ und „Transport“ zwei getrennte Bereiche, was im Unicast-Bereich bisher gut funktioniert hat. Allerdings hat sich herausgestellt, dass Funktionen auf einem höheren Niveau (wie Fehler-, Fluss- und Überlastungskontrolle) wesentlich aufwendiger sind als im Unicast-Bereich.

Es ist in lokalen Netzwerken realisierbar, wobei „lokal“ auch innerhalb des Netzes eines Internetproviders bedeuten kann. In diesem Rahmen wurde es heute schon implementiert. Ein weiteres Problem besteht in verschiedenen Algorithmen und dass selbst bei Routern, die für Multicast geeignet sind, dieses erst eingeschaltet und konfiguriert werden muss. In der Regel wird es nur soweit funktionieren können, wie ein direkter „Zugriff“ auf die Router besteht (z. B. in einem Firmennetzwerk). Eine weitere Einschränkung besteht darin, dass IPSec (siehe Glossar) Multicast nicht direkt unterstützt [Aus05]. Auch gibt es bei Multicast keinen klassischen „Header“, der dem Player alle wichtigen Informationen gibt. Stattdessen gibt es in unterschiedlichen Formaten wie z.B. beim SDP – engl. für „Session Description Protocol“ - eine kleine Datei, die dem Player die nötigen Informationen (wie z. B. die zu verwendende Portnummer) mitteilt.

Der neueste Trend geht in die Richtung, dass sich seit der Jahrhundertwende einige Forscher dafür ausgesprochen haben, die Multicast-Funktionalität weg von der IP-Ebene hin zu den Endgeräten zu verschieben. Im Allgemeinen wird dies heute als der Ansatz angesehen, um die vielfältigen Probleme mit der Multicast-Implementierung auf IP-Ebene zu lösen [LZ08]. Dies wird im folgenden Absatz besprochen.

Aufsplitten des Streams auf Applikationsebene (Application-Layer-Multicast)

Hierbei handelt es sich um eine Implementierung des Multicast-Protokoll-Ansatzes auf dem Application Layer, d. h. die fehlende Funktionalität in den Routern wird auf der Applikationsebene nachgebildet und ebenso wie dies sonst durch die Router geschehen würde, wird so eine Multicast-Architektur aufgebaut um einen Stream effizient verteilen zu können. Sollte in lokalen Netzwerken die Multicast-Funktionalität der Router vorhanden sein, so kann diese auch genutzt werden. In [BB02] findet sich ein Vergleich verschiedener Protokoll-Ansätze, an dieser Stelle sei nur eine Übersicht gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 32: Verschiedene Multicast-Verfahren [BB02]

In der Abbildung 32 stellen die quadratischen Knoten die Router dar während die runden Knoten die Endpunkte (Teilnehmer) darstellen. Natürlich stellt hier die Art und Weise wie die Hierarchie effizient aufgebaut werden kann eine zentrale Herausforderung dar. Weiterhin ist es bei diesem Ansatz schwierig auf scheidende/neu hinzukommende Knoten zu reagieren, dafür gibt es verschiedene passive oder auch „pro-aktive“ Reparaturalgorithmen.

Peercasting, das Peer to Peer (kurz: „P2P“) - Grundprinzip

Beim Peercasting gilt das Grundprinzip, dass jeder Stream-Empfänger den Stream zu „anderen“ Empfängern weiterleitet. Dies hat folgende Vorteile:

1. Kein Server notwendig.
2. „Unbegrenzte“ Skalierbarkeit.

Allerdings ergeben sich dadurch auch sehr viele Nachteile:

1. Sogenannte „Churn“-Problematik, da ständig Peers dazukommen und gehen.
2. Begrenzte Kapazitäten der Peers durch asymmetrische Internetanschlüsse (die zum Weiterverteilen wichtige Upload-Geschwindigkeit ist oft viel geringer als die Download-Geschwindigkeit).
3. Begrenzte Erreichbarkeit der Peers, oft kein Durchkommen durch NATs (siehe Glossar), Firewalls.
4. Schwierig die Netzwerkkapazitäten optimal zu nutzen, da keine Koordination stattfindet.

[...]