Diplomarbeit

Von Christian Meixner Matrikel-Nr: 22676

Untersuchen von internetbasierten Videostreamingverfahren und -techniken auf Verwendbarkeit für regionale Fernsehkanäle

Betreuung: Prof. Dr. Maximilian Eibl, Technische Universität Chemnitz Dipl.-Inf. Karsten Hilbert, Technische Universität Chemnitz

Chemnitz, den 02.07.2007

Fakultät für Informatik Professur Medieninformatik Technische Universität Chemnitz, www.tu-chemnitz.de/informatik

Meixner, Christian [email protected]

Untersuchen von internetbasierten Videostreamingverfahren und -techniken auf Ver- wendbarkeit für regionale Fernsehkanäle

Diplomarbeit, Fakultät für Informatik Technische Universität Chemnitz, Juli 2007

Kurzfassung

Im Rahmen der vorliegenden Diplomarbeit werden browserbasierte Videoüber- tragungslösungen bezüglich ihrer Verwendbarkeit zur Übertragung des Fernseh- programms regionaler Fernsehsender auf das Medium Internet untersucht, mit dem Ziel eine Prototypanwendung auf Basis der gemäß den Anforderungen der Regionalsender am besten geeigneten Technik zu implementieren.

Grundlage der Untersuchung bildet eine Gegenüberstellung der am Markt be- findlichen Videosysteme mit Webbrowserunterstützung QuickTime, RealVideo, Windows Media, Adobe Flash und Java. Die Systeme werden bezüglich ihres Leistungsumfangs, der Flexibilität ihrer Einsatzmöglichkeiten, der Qualität der zugrundeliegenden Videocodecs und ihrer Verbreitung im Internet verglichen.

Anhand der gemeinsam mit den Regionalsendern KabelJournal und Sachsenfern- sehen ermittelten Anforderungen an ein Videosystem zur Übertragung ihres Pro- gramms im Internet, erweist sich Adobe Flash Video durch seine hohe Verbrei- tung, seine flexiblen Einsatzmöglichkeiten und seiner Unterstützung von Be- wegtbild-, Standbild- und interaktiven Animationsmedien als am besten geeig- net.

Die im Rahmen dieser Arbeit erstellte Implementierung einer Web-TV Anwen- dung auf Basis von Adobe Flash zeigt bei der Ermittlung von konkreten Einsatz- szenarien bei den Sendern KabelJournal und Sachsenfernsehen, dass durch die multimediale Auslegung, die flexiblen Medienkombinationsmöglichkeiten und die offene XML-Schnittstelle mehr als eine bloße Portierung des TV-Programms ins Internet mit gleichzeitig geringem Aufwand möglich ist. Die Web-TV An- wendung ist eine einfach einsetzbare aber höchst vielseitige Möglichkeit für Re- gionalsender neue Märkte zu erschließen.

-II-

Abstract

Within the present diploma thesis, established web browser based video solu- tions are examined for their use as internet broadcasting system for local TV sta- tions, with the intention of implementing a broadcasting solution based on the technique matching the requirements of local TV stations best.

Basis of this examination is the comparison of the web video solutions Quick- Time, RealVideo, Windows Media, Adobe Flash and Java. These systems are compared by their multimedia support, flexibility of use, quality of the video co- decs they use and their market penetration.

On the basis of the requirements of local TV stations, determined together with KabelJournal and Sachsenfernsehen, adobe flash is the most satisfying solution to build a Web TV application upon. Its market penetration, flexibility of use and its support for still images, videos and interactive animations match those require- ments best.

The implementation of the Web TV application based on adobe flash proofs its great flexibility, ease of use and its diverse variations in combining different me- dia, at the determination of concrete use cases together with KabelJournal and Sachsenfernsehen. It shows that this is an easy but high potential way to enter new markets for local TV stations.

-III-

Inhaltsverzeichnis

Kurzfassung...... II Abstract...... III Inhaltsverzeichnis ...... IV Abbildungsverzeichnis ...... VI Tabellenverzeichnis ...... VII Listingverzeichnis ...... VII Abkürzungsverzeichnis ...... VIII 1 Einleitung, Motivation, Ziele, Aufbau und Grundlagen...... 1 1.1 Einleitung ...... 1 1.2 Ziele...... 2 1.3 Aufbau ...... 2 1.4 Begriffe: Codec, Encoding, single pass, multi pass...... 3 1.5 Grundlegende Videoübertragungsmöglichkeiten...... 5 1.5.1 Live Streaming ...... 5 1.5.2 On-demand Streaming ...... 9 1.5.3 Progressive Download...... 11 1.5.4 Download ...... 13 2 Webbrowserbasierte Lösungen zur Videoübertragung...... 15 2.1 Übertragungslösungen für Videos im Webbrowser...... 16 2.1.1 QuickTime ...... 16 2.1.2 RealVideo...... 20 2.1.3 Windows Media...... 24 2.1.4 Adobe Flash...... 27 2.1.5 Java ...... 33 2.2 Qualitätsvergleich der Videokompression...... 35 2.2.1 Testvoraussetzungen und Vergleichsmetriken...... 35 2.2.2 Testergebnisse und Auswertung...... 37 2.3 Verbreitung der Videoformate...... 54 3 Anforderungen regionaler Fernsehsender...... 58 3.1 Umfang des Videomaterials und Übertragungsanforderungen...... 59 3.2 Werbeeinblendungen ...... 60 3.3 Anzeigen von zusätzlichen Informationen...... 62

-IV-

3.4 Programmzusammenstellung, –steuerung, Nutzerinteraktion...... 62 3.5 Anforderungen an die Infrastruktur und Schnittstellen ...... 64 4 Prototypische Umsetzung einer Web-TV Anwendung...... 66 4.1 Vorüberlegungen und Auswahl einer Technik...... 66 4.2 Umsetzung des Players...... 69 4.2.1 Modularität der Programmierung ...... 70 4.2.2 Die Oberfläche des Web-TV Players...... 71 4.2.3 Das Playlistsystem...... 73 4.3 Einsatz der Web-TV Anwendung in eine Webseite ...... 75 4.3.1 Konfigurationsmöglichkeiten ...... 75 4.3.2 Integration des Players in eine Webseite...... 80 4.3.3 Bereitstellen von Inhalten...... 82 4.4 Unterstütze Wiedergabeelemente und ihre Funktionen...... 83 4.4.1 Die Playliste...... 83 4.4.2 Playlisteneinträge ...... 84 4.4.3 Videos, Bilder und Animationen als Filme...... 84 4.4.4 Zusätzliche Audiospuren ...... 86 4.4.5 Overlays ...... 86 4.4.6 Zusätzliche Informationen ...... 89 4.4.7 Zusätzliche Informationen: Überschrift ...... 90 4.4.8 Zusätzliche Informationen: HTML-Text ...... 90 4.4.9 Zusätzliche Informationen: Formatierung des HTML-Texts ...... 91 4.4.10 Zusätzliche Informationen: Links ...... 91 5 Bewertung der Umsetzung...... 93 5.1 KabelJournal...... 93 5.2 Sachsenfernsehen ...... 96 6 Zusammenfassung und Ausblick...... 99 Quellen und Literaturverzeichnis ...... X Anhang A – Inhalt der Begleit-DVD ...... XVII Anhang B – Klassenübersicht ...... XIX Anhang C – DTD des Playlistenformats...... XX Eigenständigkeitserklärung ...... XXI

-V-

Abbildungsverzeichnis

Abbildung 1: Kompressionsartefakte durch zu starke Kompression des Videos im Vergleich zum Original...... 4 Abbildung 2: Verarbeitungskette bei der Videoübertragung mittels Live Streaming..... 7 Abbildung 3: Streamübertragung per Multicast und Unicast ...... 8 Abbildung 4: Übertragung von Videodaten mittels On-demand Streaming...... 9 Abbildung 5: Übertragung von Videodaten mittels Progressive Download ...... 12 Abbildung 6: Übertragung von Videodaten mittels normalem Download...... 14 Abbildung 7: QuickTime Player mit Standardoberfläche und Browserplugin...... 19 Abbildung 8: QuickTime Player mit im Film eingebettetem Media Skin...... 19 Abbildung 9: RealPlayer 10 mit Standardskin und Standardansicht des Browserplugins ...... 23 Abbildung 10: Windows Media Player 11 und Standardansicht des Browserplugin.... 26 Abbildung 11: FLV Player von Martijn de Visser...... 29 Abbildung 12: Ausgewählte Vergleichsszenen aus dem Testvideo ...... 37 Abbildung 13: Verlauf des SSIM über das Testvideo für die Codecs bei 500 kbps ...... 38 Abbildung 14: Verlauf des SSIM für MPEG2 bei 500 kbps verglichen mit Quicktime .. 39 Abbildung 15: Vergleich von Bild 2150 aus dem Testvideo bei 500 kbps CBR...... 40 Abbildung 16: Vergleich von Bild 3253 aus dem Testvideo bei 500 kbps CBR...... 41 Abbildung 17: Vergleich von Bild 4200 aus dem Testvideo bei 500 kbps CBR...... 42 Abbildung 18: Verlauf des SSIM über das Testvideo für die Codecs bei 200 kbps ...... 43 Abbildung 19: Vergleich von Bild 2150 aus dem Testvideo bei 200 kbps CBR...... 44 Abbildung 20: Vergleich von Bild 3253 aus dem Testvideo bei 200 kbps CBR...... 45 Abbildung 21: Vergleich von Bild 4200 aus dem Testvideo bei 200 kbps CBR...... 46 Abbildung 22: Verlauf des SSIM über das Testvideo für die Codecs bei 50 kbps ...... 47 Abbildung 23: Vergleich von Bild 2150 aus dem Testvideo bei 50 kbps CBR...... 48 Abbildung 24: Vergleich von Bild 3253 aus dem Testvideo bei 50 kbps CBR...... 49 Abbildung 25: Vergleich von Bild 4200 aus dem Testvideo bei 50 kbps CBR...... 50 Abbildung 26: Durchschnittliches SSIM und PSNR der Testvideos...... 52 Abbildung 27: Verbesserung der Qualität in kritischen Szenen durch VBR-Encoding.52 Abbildung 28: Adobe-Studie zur Verbreitung der Browserplugins...... 55 Abbildung 29: Verbreitung der Browserplugins unter den Besuchern der Webseiten der Lokalfernsehsender...... 56 Abbildung 30: Die Oberfläche des Web-TV Players mit geschlossenen Zusatzfenstern und vollständig geöffnet...... 72 Abbildung 31: Verschiedene Overlays über einem Video ...... 88 Abbildung 32: Elemente der Zusatzinformationsanzeige...... 89

-VI-

Tabellenverzeichnis

Tabelle 1: Über- bzw. Unterschreitung der Zielbitrate der Codecs beim Testvideo ...... 53 Tabelle 2: Klassenübersicht der Web-TV Anwendung...... XIX

Listingverzeichnis Listing 1: HTML und JS-Code zur Integration des Web-TV Players in eine Webseite .. 80 Listing 2: crossdomain.xml mit Freigabe für example.com ...... 82 Listing 3: DTD des XML-Playlistenformats des Web-TV Players...... XX

-VII-

Abkürzungsverzeichnis

AAC Advanced Audio Coding, Audiokompressionsformat

API Application Programming Interface

AS ActionScript

AVI Audio Video Interleaved, Videocontainerformat von Microsoft

CBR Constant Bit Rate

CSS Cascading Style Sheets dB Dezibel

DSL Digital Subscriber Line

FLV Flashvideo – Dateiformat

GUI Graphical User Interface

HD High Definition (Videos ab einer vertikalen Auflösung von 720 Pixeln )

HTML Hypertext Markup Language, textbasierte Auszeichnungssprache zur Darstellung von Inhalten im World Wide Web

HTTP Hypertext Transfer Protocol

JMF Java Media Framework

JPEG Joint Photographic Experts Group, ein Bildkompressionsformat

JS JavaScript

JVM Java Virtual Machine, Laufzeitumgebung für Java kbps Kilobit pro Sekunde (Datenrate eines Video- oder Audiostroms)

LAN Local Area Network, ein lokal begrenztes Computernetzwerk

MP3 MPEG-1 Audio Layer 3, Audiokompressionsformat

MPEG Moving Picture Experts Group

MVC Model-View-Controller, ein Softwarearchitekturprinzip

PAL Phase Alternating Line, standardisiertes Format zur Fernsehbildüber- tragung in Europa (außer Frankreich) und vielen anderen Ländern

-VIII-

PHP PHP Hypertext Preprocessor, Serverseitige Programmiersprache dyna- mische Webseiten

PSNR Peak signal-to-noise ratio (Signal-Rauschabstand)

RTP Real-Time Transport Protocol, Protokoll zur kontinuierlichen Übertra- gung von audiovisuellen Daten (Streams) über Netzwerke

RTSP Real Time Streaming Protocol, Protokoll zur Steuerung der kontinuier- lichen Übertragung von audiovisuellen Daten über Netzwerke

SQL Structured Query Language, Sprache für Datenbankabfragen

SMIL Synchronized Multimedia Integration Language

SSIM Structural similarity index (Maß für die Ähnlichkeit von Bildern)

SVG Scaleable Vector Graphic, eine Markupsprache für Vektorgrafiken

SWF „Small Web Format“oder „ShockWave Flash“, Vektorbasiertes Anima- tionsformat von Adobe Flash

URL Uniform Resource Locator

VBR Variable Bit Rate

W3C World Wide Web Consortium

WAV Waveform audio format, Audiospeicherformat, meist unkomprimiert

WWW World Wide Web, weltweites Netzwerk aus verlinkten Hypertextdo- kumenten

XML Extensible Markup Language

-IX- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

Kapitel 1

1 Einleitung, Motivation, Ziele, Aufbau und Grundlagen

1.1 Einleitung

Kein Medium entwickelt sich derzeit schneller als das Internet. Von 1997 bis 2006 stieg der Anteil der Internetnutzer in Deutschland einer Studie der ARD zufolge von 6,5% auf fast 60% [Eimerer & Frees 2006]. Damit sind rund 38,6 Millionen Erwachsene hierzulande online. Multimediale Angebote wie Bild, Audio, Anima- tionen und Videos werden für die Nutzer dabei zunehmend interessant. Laut der ARD-Studie nutzt fast jeder vierte zumindest gelegentlich online Videoangebote. Und während die Zeit, die jeder Deutsche durchschnittlich im Internet verbringt von Jahr zu Jahr steigt, stagniert die Verweildauer vor dem Fernsehgerät und ist beim Hörfunk bereits rückläufig. Die klassischen Medien laufen langfristig Ge- fahr vom Internet als Informations- und Unterhaltungsmedium verdrängt zu werden. Für die klassischen Medien ist daher Eile geboten, rechtzeitig ihre Nische im weltweiten Netz zu besetzen. Dabei bedeutet eine Ausweitung der Aktivitäten auf das Internet nicht nur eine Erweiterung des Services für Stammzuschauer sondern auch, dass neue Zuschauer als Nutzer des Online Angebots gewonnen werden können. Dies gilt besonders auch für regional begrenzte Sender, denn das Internet kennt keine Reichweitenlimits oder Landesgrenzen.

Die Portierung der Programminhalte in das Internet bietet für Fernsehsender neue Möglichkeiten für neue Dienste. Die Zuschauer können ihre Lieblingssen- dungen abrufen, wann und von wo sie wollen, ohne zu Hause den Videorecorder programmieren zu müssen. Durch die Interaktionsmöglichkeiten im Netz kann der Sender zudem direktes Feedback von seinen Zuschauern erhalten und sie mit den Möglichkeiten des Web 2.0 sogar an der Programmgestaltung aktiv beteili- gen. Die für die Videoübertragung im Internet benötigten Techniken sind zudem nicht neu, sondern haben sich über die Jahre entwickelt und gelten als ausgereift. Dem Schritt ins Internet stehen somit lediglich die Auswahl der richtigen Technik und die Entscheidung zur Umsetzung im Weg.

-1- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

1.2 Ziele

Im dieser Arbeit werden die am Markt befindlichen webbrowserbasierten Video- übertragungssysteme für das Internet untersucht und gegenübergestellt. Das Hauptaugenmerk liegt dabei auf dem Funktionsumfang der einzelnen Systeme, der Flexibilität ihrer Einsatzmöglichkeiten und auf der Qualität der verwendeten Videokompressionsverfahren. Ziel ist es, herauszufinden, welches der Systeme sich am besten für den Einsatz zur Übertragung des Fernsehprogramms regiona- ler Fernsehsender auf das Medium Internet eignet. Neben den Eigenschaften der Videoübertragungslösungen werden daher auch die Anforderungen von Regio- nalsendern an derartige Systeme zur Internetbasierten Übertragung ihrer Pro- gramme ermittelt.

Basierend auf den ermittelten Anforderungen der Sender und den Ergebnissen des Videosystemvergleichs, wird eines der betrachteten Verfahren ausgewählt werden. Auf dessen Grundlage soll im Rahmen dieser Diplomarbeit ein Prototyp zur webbrowserbasierten Übertragung der Programme regionaler Fernsehsender im Internet entwickelt werden.

1.3 Aufbau

Im zweiten Kapitel der Arbeit werden die heute am Mark befindlichen webbrow- serbasierten Videoübertragungslösungen erläutert und miteinander verglichen. Dabei wird zunächst auf den Funktionsumfang der einzelnen Systeme eingegan- gen. Anschließend wird die Videokompressionsqualität der von den Systemen eingesetzten Kompressionsalgorithmen miteinander verglichen. Des Weiteren wird die Verbreitung der Übertragungslösungen im Internet allgemein und spe- ziell unter den Besuchern der Webseiten einiger Regionalsender untersucht. In Kapitel drei werden die Anforderungen von regionalen Fernsehsendern an eine Programmübertragung im Internet dargestellt. Dazu werden exemplarisch zwei sächsische Regionalsender herangezogen und deren Programm und aktuelle In- ternetpräsenz analysiert. Auf Basis dieser Informationen wird im Kapitel vier ei- ne der zuvor betrachteten Videoübertragungslösung ausgewählt und auf deren Grundlage eine Prototypanwendung zur Übertragung des Fernsehprogramms regionaler Fernsehsender implementiert. Dabei werden einzelne Komponenten

-2- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

zur Erfüllung der wichtigsten Anforderungen hervorgehoben. Im Abschließen- den Kapitel werden die wesentlichen Ergebnisse der Arbeit zusammengefasst und zukünftige Erweiterungsmöglichkeiten für die Anwendung aufgezeigt, die dem Anwender weiteren Nutzen und den Sendern weitere Nutzer bringen könn- ten.

1.4 Begriffe: Codec, Encoding, single pass, multi pass

Videodaten benötigen sehr viel Speicherplatz. Im Falle einer Übertragung des Vi- deomaterials, etwa über ein Netzwerk, gilt dies auch für die erforderliche Band- breite. Ein Video, in dem in Europa üblichen PAL-Format, mit einer Auflösung von 768 x 576 Pixeln und 25 Vollbildern pro Sekunde benötigt für jede Sekunde Bildmaterial rund 32 MiB Speicherplatz. Bei einer Netzwerkübertragung ent- spricht dies einer Bandbreite von rund 260 Mbit/s. Das ist sehr viel. Ein zwei- stündiger Film würde so die komplette Speicherkapazität einer modernen Fest- platte belegen und eine Live-Übertragung wäre selbst in den meisten LANs nicht möglich. Daher ist es notwendig den Speicher- und Bandbreitenbedarf von Vide- os mittels Kompression zu reduzieren.

Der Vorgang ein Video zu komprimieren wird als Encoding oder Enkodierung bezeichnet. Der Encoder ist eine Software oder Hardware, etwa in Form einer Erweiterungskarte für Computer, welche den Codiervorgang durchführt. Die Umkodierung von einem Kompressionsformat in ein anderes wird als Transko- dieren bezeichnet. Die Art der Kompression wird durch den zum Enkodieren verwendeten Codec bestimmt. Der Begriff Codec steht für Codierung / Decodie- rung und bezeichnet eine konkrete Implementierung eines Kompressionsalgo- rithmus. Bei den Codecs bzw. Kompressionsalgorithmen wird zwischen verlust- behafteten und verlustfreien Varianten unterschieden. Verlustfreie Codecs errei- chen eine Kompressionsrate von etwa 1:3 [Rudiak-Gould 2000]. Sie eignen sich besonders als Zwischenspeicherformat, zum Beispiel um die Videodatei später weiter zu bearbeiten. Verlustbehaftete Codecs erreichen sehr viel höhere Kom- pressionsraten von 1:1000 und mehr, je nachdem welcher Verlust an Bildqualität noch akzeptabel ist. Bei zu starker Kompression treten bei der Wiedergabe des Videos deutlich sichtbare Kompressionsartefakte meist in Form von Klötzchen

-3- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

oder aquarellartigen Farbflächen auf. Abbildung 1 zeigt solche Kompressionsar- tefakte und dem damit einhergehenden Qualitätsverlust im Vergleich zum Origi- nalvideo.

Abbildung 1: Kompressionsartefakte (rechts) durch zu starke Kompression des Videos im Ver- gleich zum Original (links)

Moderne, effiziente Codecs wie zum Beispiel VC-1 oder H.264 können Videos bei Datenraten von 2000 kbit/s mit annähernd voller PAL-Qualität ohne sichtbare Kompressionsstörungen speichern [Microsoft 2006b]. Das entspricht einer Kom- pression von etwa 1:150.

Normalerweise werden Videos mit einer konstanten Bitrate komprimiert, eng- lisch als Constant Bit Rate (CBR) bezeichnet. Dabei wird jedem Teilstück des Vi- deos unabhängig von der Komplexität der dargestellten Szene die gleiche Daten- rate bzw. Speichermenge zugeteilt. Dadurch kann es passieren, dass besonders komplexe oder bewegungsreiche Szenen zu stark komprimiert werden, während andere, einfachere Szenen mehr Speicher zugeteilt bekommen, also nötig wäre. Um dieses Missverhältnis auszugleichen bieten viele Codecs die Möglichkeit an, Videos mit variabler Datenrate zu enkodieren (Variable Bit Rate, VBR). Die Da- tenrate wird dabei automatisch an die Komplexität der Szene angepasst. Im Mit- tel über das gesamte Video ergibt sich so der gleiche Speicherbedarf wie bei der CBR-Enkodierung. Die Bildqualität eines VBR-enkodierten Videos ist aufgrund der optimalen Verteilung des zur Verfügung stehenden Gesamtspeicherplatzes meist deutlich höher. Um aber die Datenrate wirklich optimal über das gesamte Video zu verteilen, müsste der Encoder vorausschauende Fähigkeiten haben, da er nicht wissen kann, ob nach dem eben bearbeiteten Teil des Videos eine kom-

-4- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

plexe Szene folgt für die er Datenrate aufsparen müsste oder eine simple Szene die weniger Platz benötigt. Aus diesem Grund wird beim VBR-Verfahren vor der eigentlichen Enkodierung das Video in einem zusätzlichen Durchlauf zunächst auf die Verteilung von komplexen und simplen Szenen hin analysiert. Durch die- se zusätzlichen Analysedurchläufe bezeichnet man das Verfahren auch als two pass encoding oder multi pass encoding. Analog dazu wird die Enkodierung mit CBR auch single pass encoding genannt, da sie in einem Durchgang erfolgt. Da die zusätzlichen Analysedurchläufe des Videos weitere Rechenzeit benötigen, ist dieses qualitätssteigernde Verfahren deutlich zeitaufwendiger. Außerdem kann multi pass encoding nicht bei live Videos angewendet werden.

1.5 Grundlegende Videoübertragungsmöglichkeiten

Es gibt vier grundlegende Möglichkeiten Videos über das Internet zu übertragen. Die Einfachste ist dabei der schlichte Download einer Videodatei von einem Webserver. Die genau entgegengesetzt arbeitende Methode ist das Live Strea- ming, bei dem gar keine Datei zum Einsatz kommt und die Videodaten direkt vom Bilderzeuger zum Nutzer übertragen werden. Die beiden Varianten On- demand Streaming und Progressive Download stellen Kompromisse zwischen den beiden Extremen dar. Alle vier Methoden haben besondere Merkmale, An- forderungen sowie Vor- und Nachteile die im Folgenden dargestellt werden.

1.5.1 Live Streaming

Live Streaming ist die Videoübertragungsvariante für das Internet, die dem her- kömmlichen Rundfunk am ähnlichsten ist. Dabei werden die Bilddaten von ei- nem Aufnahmegerät, also einer an einen Computer angeschlossenen Kamera

oder Video-Capture-Steckkarte, zunächst an einen Encoder geleitet. Dieser komp- rimiert die Videodaten, so dass sie sich mit möglichst wenig Qualitätsverlust über die beschränkte Übertragungsbandbreite eine Internetverbindung übertragen las- sen. Diesen komprimierten Videodatenstrom leitet der Encoder direkt zum Streaming Server weiter, welcher entweder auf demselben Rechner läuft oder ü- ber ein Netzwerk erreichbar ist. Der Streaming Server hat die Aufgaben die Vi- deodaten in Pakete einzuteilen, die er an alle angemeldeten Client-Computer ü-

-5- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

ber das Internet sendet. Dabei wird ein auf Streaming optimiertes Übertragungs- protokoll benutzt, wie das standardisierte RTP/RTSP oder die proprietären Vari- anten der Hersteller. Auf dem Client-Computer nimmt ein streamingfähiger Vi- deoplayer den Datenstrom entgegen, decodiert das enthaltene Video und zeigt es an. Abbildung 2 stellt diesen Produktions- und Sendeablauf schematisch dar.

Durch diese Verarbeitungskette können theoretisch unendlich lange Videoströme wie beim herkömmlichen Fernsehen übertragen werden. Dadurch entstehen al- lerdings auch ähnliche Probleme wie beim Rundfunk. Wird der Empfang bzw. die Verbindung zum Streaming Server unterbrochen oder anderweitig gestört, gehen die während dieser Zeit übertragenen Videodaten unwiderruflich verloren und das Video wird unterbrochen. Zusätzlich kommen netzwerkspezifische Probleme hinzu. Reicht die Übertragungsbandbreite des Empfängers nicht aus, um den ausgesandten Videostrom zu empfangen, so kommt es immer wieder zu Aussetzern bei der Wiedergabe. Außerdem ist es bei der paketorientierten Über- tragung über das Internet möglich, dass einzelne Pakete auf Netzwerkebene ver- loren gehen. In kurzem Abstand müssen diese dann noch einmal ausgesendet werden oder die Videowiedergabe wird unterbrochen. Ein weiteres Problem, das auftreten kann, ist, dass Datenpakete in der falschen Reihenfolge beim Client an- kommen, da sie über verschiedene Wege durch das Internet geleitet wurden. Um diesen Problemen entgegenzuwirken, legt der Videoplayer einen kleinen Puffer als Vorratspeicher an, den er nutzen kann, bis die noch fehlenden Pakte eingetrof- fen und in die richtige Reihenfolge gebracht worden sind. Läuft der Puffer leer bevor die fehlenden Informationen empfangen wurden, unterbricht das Video ebenfalls und wird nach einem neuen Aufbau des Puffers an späterer Stelle fort- gesetzt. Durch den Wiedergabepuffer und die aufwendige Verarbeitungskette vom Encoder bis zum Client kann es zudem zu einer Latenz von bis zu mehreren Sekunden kommen. Dies fällt besonders dann negativ auf, wenn zum Beispiel Er- eignisse wie Fußballspiele live gleichzeitig über herkömmlichen Rundfunk und per Internetstream übertragen werden.

-6- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

Abbildung 2: Verarbeitungskette bei der Videoübertragung mittels Live Streaming

Durch den Echtzeit-Charakter ist beim Live Streaming, genauso wie beim Rund- funk, kein Vor- oder Zurückspulen des abgespielten Videos möglich, es sein denn, der Client verfügt über eine Timeshift Funktion. Diese schreibt das Live Video, während die Wiedergabe pausiert, im Hintergrund auf ein Speichermedi- um und spielt es beim Fortsetzen der Wiedergabe dann vom Speicher ab. Bezüg- lich der Qualität muss man beim Live Streaming technisch bedingt Einschrän- kungen hinnehmen. Das Videomaterial kann nur mit konstanter Bitrate in einem einzigen Durchgang codiert werden, da es direkt ausgesendet wird. Das quali- tätsverbessernde Multipassverfahren ist hier nicht anwendbar.

Auch an die eingesetzte Hardware stellt Live Streaming hohe Anforderungen. Der für das Encoding zuständige Rechner muss das Videomaterial mindestens in Echtzeit aufbereiten und komprimieren können. Andererseits wird für das Vi- deomaterial weder beim Client noch auf dem Server Speicherplatz benötigt, da der Videostrom sofort ausgesendet und im Normalfall auch nach der Wiedergabe nicht gespeichert wird.

Die kritischsten Punkte beim Live Streaming sind daher die Netzwerkbandbreite und die Stabilität der Verbindung. Bei einem Verbindungsabbruch oder einer zu geringen Bandbreite wird die Wiedergabe unterbrochen. Die in der Zwischenzeit ausgesandten Teile sind für den Nutzer verloren. Auch auf der Serverseite ist es

-7- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

daher wichtig, dass genügend Bandbreite zur Verfügung steht, um alle Nutzer zu bedienen. Durch die im Internet üblichen Punkt-zu-Punkt Verbindungen muss normalerweise für jeden einzelnen Nutzer ein eigener Strom mit der vollen Bandbreite ausgesendet werden. Da beim Live Streaming jedoch alle Nutzer die gleichen Inhalte sehen, ist es möglich den Datenverkehr direkt am Streaming Ser- ver durch die Multicast-Technik zu verringern. Dabei wird vom Server immer nur ein Datenpaket für alle Nutzer zusammen ausgesendet und erst am Router für jeden getrennten Weg zu einem Nutzer dupliziert. Bei Verwendung von Uni- cast-Verbindungen hingegen schickt der Server für jeden Nutzer einen separaten Datenstrom. Der Streaming Server kann so immer nur eine begrenzte Anzahl Nutzer bedienen. Die Abbildung 3 stellt die unterschiedliche Paketverteilung bei Multicast und Unicast schematisch dar. Um auch beim Unicastverfahren viele Clientrechner gleichzeitig mit einem Live-Stream zu bedienen, können wie in Abbildung 2 dargestellt, zusätzliche Relay Server zwischengeschaltet werden. Diese nehmen wie ein Client den Videostrom vom Hauptserver oder einem ande- ren Relay entgegen und verteilen ihn dann wieder an mehrere Clients oder ande- re Relays.

Abbildung 3: Streamübertragung per Multicast und Unicast

-8- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

1.5.2 On-demand Streaming

Das On-demand Streaming ist dem Live Streaming angelehnt. Es unterscheidet sich prinzipiell nur dadurch, dass statt einer Echtzeitvideoquelle bereits vorgefer- tigte Videodateien auf einem Server abgelegt werden. Der Nutzer kann von sei- ner Wiedergabesoftware aus eine dieser Dateien anfordern. Der Streaming Server liefert diese dann ähnlich wie beim Live Streaming an den Videoplayer des Clients aus.

Abbildung 4: Übertragung von Videodaten mittels On-demand Streaming

Abbildung 4 stellt diese Vorgehenswiese schematisch dar. Durch dieses Prinzip ergeben sich gegenüber dem Live-Streaming neue Vorteile aber auch neue Nachteile. So ist zum Beispiel kein spezieller Rechner für das Echtzeit-Encoding der Videos nötig, da diese offline zum Beispiel mit einer Schnittsoftware zusam- mengestellt werden können. Andererseits wird je nach Umfang des Videomateri- als viel Speicherplatz auf dem Server für die Videodateien benötigt. In Anbet- racht der ständig sinkenden Speicherpreise ist dies jedoch kein wirkliches Prob- lem. Durch das Entfallen des Echtzeit-Encoding ist es beim On-demand Strea- ming auch möglich die Videos mit variabler Bitrate und Multipass-Encoding zu erstellen. Wie bereits in Kapitel 1.4 erwähnt, kann bei diesem Verfahren die Vi- deoqualität durch einen oder mehrere vorangegangene Analysedurchläufe ge- steigert werden. Die zur Verfügung stehende Bitrate wird anhand der Analyse beim Kodierungsdurchlauf sinnvoll auf komplexe und simple Szenen gewichtet verteilt. Die Varianz der Bitrate darf beim On-demand Streaming jedoch nicht zu groß ausfallen um nicht die verfügbare Bandbreite der Internetverbindung des Clients zu überschreiten.

-9- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

Dass die Videos beim On-demand Streaming bereits als vorgefertigte Dateien be- reit liegen hat auch für den Nutzer Vorteile. Kommt es beim On-demand Strea- ming zu Verbindungsabbrüchen oder reicht die Bandbreite des Nutzers nicht aus, bricht zwar die Videowiedergabe wie beim Live Streaming ab, sie wird aber nach dem Wiederaufbau des Puffers exakt an der Stelle der Unterbrechung fortgesetzt. Es gehen also keine Informationen verloren. Streaming Server für On-demand Streaming bieten oft auch die Möglichkeit die Videobitrate zu reduzieren, wenn die Verbindung zum Nutzer schlechter wird und abbricht. Hierzu müssen die Videodateien aber speziell vorbereitet werden, in dem sie im Vorfeld in mehreren Bitraten erzeugt und bereitgestellt werden. Der Streaming Server kann dann dy- namisch während der Wiedergabe zwischen den verschiedenen Bitraten um- schalten.

Beim On-demand Streaming kann der Nutzer im Video vor- oder zurückzuspu- len. Er kann so bereits zu Beginn in die Mitte oder ans Ende des Videos springen und es sich von da aus anschauen. Dies macht On-demand Streaming besonders für Video mittlerer und großer Länge interessant, also etwa ab zehn Minuten bis mehrere Stunden Filmdauer. Der Nutzer muss sich beim wiederholten Betrachten oder späteren Fortsetzen eines bereits begonnenen Films nicht noch einmal das gesamte Video herunterladen. Leider muss bei jedem Sprung oder Spulvorgang der Wiedergabepuffer neu aufgebaut werden, was je nach Videobitrate und Ver- bindungsgeschwindigkeit mehrer Sekunden dauern kann. Dies stört den Komfort wenn man zum Beispiel nach einer bestimmten Stelle im Video sucht.

Die Möglichkeit spätere Teile im Video direkt anspringen zu können hat auch für den Videoanbieter Vorteile. Beim On-demand Streaming werden immer nur die Teile an den Client übertragen, die der Nutzer auch wirklich ansieht. Ein unnöti- ger Netzwerkverkehr wird somit vermieden. Dieser Effekt relativiert sich jedoch, wenn der Nutzer Videos häufig mehrfach ansieht, da einmal übertragene Teile nicht vom Client zwischengespeichert werden. Das Video wird dann jedes Mal neu übertragen. Das Multicast Verfahren, zur Verringerung des Netzwerkver- kehrs, kann beim On-demand Streaming nicht eingesetzt werden, da jeder Nutzer seinen Videostrom zu einem anderen Zeitpunkt anfordert und somit andere Teil der Datei benötigt.

-10- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

1.5.3 Progressive Download

Die Videoübertragung mittels Progressive Download ist eine Variante die tech- nisch einen Kompromiss zwischen dem Datei-Download und On-demand Strea- ming darstellt. Die Videos liegen wie beim On-demand Streaming als vorgefertig- te Dateien auf einem Server und können vom Nutzer angefordert werden. Zur Übertragung wird jedoch kein spezieller Streaming Server benötigt. Die Videoda- tei wird, wie in Abbildung 5 dargestellt, über HTTP von einem normalen Web- server an den Videoplayer des Clients übertragen. Der Unterschied zu einem herkömmlichen Dateidownload besteht darin, dass das Video bereits während der Übertragung wiedergegeben werden kann. Sobald der Player genügend Da- ten in seinem Puffer vorrätig hat, kann die Wiedergabe vom Anfang des Videos beginnen. Der Rest der Datei wird inzwischen im Hintergrund nachgeladen. Der Browser legt die bereits geladenen Teile der Datei im Cache auf der Festplatte ab. Somit belegt das Video während der Wiedergabe immer etwas Speicherplatz auf dem Computer der Nutzer. In Anbetracht der heute üblichen Festplattengrößen von mehreren hundert Gigabyte stellt dies jedoch kein Problem dar. Das Zwi- schenspeichern ist aber vorteilhaft, wenn der Nutzer während der Wiedergabe im Video vor- oder zurückspringen möchte. Abhängig von der Geschwindigkeit des Rechners ist das im Gegenteil zum On-demand Streaming nahezu verzögerungs- frei und in Echtzeit möglich, da nicht nach jedem Sprung der Puffer neu aufge- baut werden muss. Die ist besonders hilfreich, wenn eine bestimmte Stelle im Vi- deo gesucht wird, ab der dieses betrachtet werden soll. Andererseits kann der Nutzer beim Progressive Download immer nur in dem Bereich vor- und zurück- springen, der bereits vom Server zum Nutzer-PC übertragen wurde. Der wahl- freie Zugriff auf das gesamte Video ist erst möglich, wenn die gesamte Datei ge- laden wurde. Aus diesem Grund wird bei der Progressive Download Variante meist auch ein Ladebalken eingeblendet, der den Nutzer darüber informiert, wie viel vom Video schon geladen wurde.

-11- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

Abbildung 5: Übertragung von Videodaten mittels Progressive Download

Bezüglich der Netzwerkanbindung zeigt sich Progressive Download anspruchs- loser als die Streaming Varianten. Sinnvoller Weise sollte die zur Verfügung ste- hende Bandbreite sowohl beim Nutzer als auch beim Server mindestens der Bit- rate des Videos entsprechen, um eine unterbrechungsfrei Wiedergabe zu ermög- lichen. Da der Videoplayer beim Progressive Download versucht soviel Daten wie möglich im Voraus zu laden und einmal geladene Teile nicht wieder vergisst, stören vorübergehende Schwankungen der Bandbreite oder kurze Verbindungs- unterbrechungen nicht. Wenn zudem der Videopuffer groß genug ist, reichen so- gar niedrigere Bandbreiten beim Kunden, um das Video ohne Aussetzer betrach- ten zu können. Es werden dann so viele Daten im Voraus geladen, dass die Daten im Pufferspeicher ausreichen, um die Dauer bis zum kompletten Download der Datei zu überbrücken. Bei extremen Missverhältnissen aus Bandbreite und Vi- deobitrate kann es dadurch aber passieren, dass der Progressive Download zum normalen Download ausartet, da fast das gesamte Video vorab geladen werden muss.

Der entstehende Netzwerkverkehr beim Progressive Download hängt stark vom Verhalten der Nutzer ab. Werden Videos einmal von Beginn bis zum Ende ange- schaut, so entsteht nicht mehr oder weniger Netzverkehr als beim On-demand Streaming. Schauen sich die Nutzer hingegen nur den Anfang eines Videos an, so verursacht Progressive Download mehr Netzwerkverkehr, da der Player versucht so viel wie möglich vom restlichen Video vorab zuladen. Dieser Effekt kann re- duziert werden, indem jedem Nutzer durch Trafficshaping beim Download nur eine gewisse maximale Bandbreite gewährt wird. Diese sollte dann etwa knapp über der Videobitrate liegen. Dem Nutzer wird damit jedoch auch die Möglich-

-12- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

keit genommen, möglichst frühzeitig ans Ende des Videos zu springen, da es län- ger dauert, bis er diesen Teil der Datei erhalten hat. Werden die Videos besonders häufig oder mehrfach hintereinander angeschaut, so kann Progressive Download sogar Netzverkehr sparen, da der Browser einmal übertragene Videos im Cache zwischengespeichert hat.

Durch die Übertragung mit Hilfe eines Webservers ist Progressive Download auch bei der Infrastruktur eher anspruchslos. Der Contentanbieter muss zur Aus- lieferung der Webseite, in die das Video integriert werden soll, ohnehin einen o- der mehrere Webserver bereithalten. Eine Erweiterung der Speicherkapazität und der Netzwerkanbindung wird in den meisten Fällen zwar nötig sein, zusätzliche Lizenzkosten, zum Beispiel für spezielle Streaming Server fallen jedoch nicht an.

Progressive Download eignet sich vor allem für Filme kurzer und mittlerer Dau- er, also etwa unter 10 Minuten. Auch für Videos, die der Nutzer vorrausichtlich in kurzen Zeitabständen mehrmals anschaut oder in denen häufig vor oder zu- rück gesprungen wird, eignet sich diese Übertragungsvariante.

1.5.4 Download

Beim einfachen Dateidownload handelt es sich um die simpelste Variante Videos zu übertragen. Wie beim Download andere Dateien auch, wird dabei das gesamte Video auf die Festplatte des Nutzers übertragen. Hierfür können kostengünstig Webserver oder FTP-Server eingesetzt werden. Der Nutzer spielt das Video an- schließend in einer Abspielsoftware seiner Wahl lokal von der Festplatte ab. Fehler! Verweisquelle konnte nicht gefunden werden. stellt diesen Ablauf schematisch dar.

-13- Einleitung, Motivation, Ziele, Aufbau und Grundlagen

Abbildung 6: Übertragung von Videodaten mittels normalem Download

Trotz des eingeschränkten und simplen Prinzips hat auch der Dateidownload sinnvolle Einsatzmöglichkeiten. Da das Video erst nach dem Download wieder- gegeben werden kann, spielt für die Wiedergabe die Bitrate bzw. die Länge des Videos, sowie die Übertragungsbandbreite, praktisch keine Rolle. Lediglich die Downloadzeit verlängert oder verkürzt sich. Durch den Download können die Videos daher auch in höchster Qualität angeboten werden, etwa als Ergänzung zu einem Stream.

Sinnvoll ist ein Download ebenfalls, wenn dem Nutzer die Möglichkeit gegeben werden soll, Videos offline zu betrachten. So können diese auf DVD gebrannt und anschließend mit Hilfe eines DVD-Players am Fernseher abgespielt werden. Überdies erhält der Nutzer die Möglichkeit die Videos zu archivieren.

-14- Webbrowserbasierte Lösungen zur Videoübertragung

Kapitel 2

2 Webbrowserbasierte Lösungen zur Videoübertragung

Es existieren vier verbreitete Übertragungstechniken um Videos online direkt im Browser anschauen zu können. Zum einen ist das QuickTime, welches oft auf Portalseiten für Trailer zu Kinofilmen eingesetzt wird. Beispiele dafür sind die Trailerseite von Apple1 oder das deutsche Kinofilmeportal Moviemaze2. Ein wei- teres verbreitetes Format ist Windows Media Video. Dieses wird zum Beispiel auf der Webseite von Pro Sieben für online zur Verfügung gestellte Fernsehserien wie „Stromberg“3 eingesetzt. Auch die „tagesschau“4 der ARD wird als Windows Media Video im Internet zur Verfügung gestellt. Alternativ kann diese Sendung jedoch auch als RealVideo betrachtet werden. Dieses dritte Format stammt von RealNetworks und gehört zusammen mit QuickTime zu den Pionieren der Vi- deoübertragung über das Internet. Als vierter Vertreter hat sich das relative junge Flashvideo als Übertragungstechnik etabliert. Dieses Format war ursprünglich nur für Animationen entwickelt worden, fand durch die Integration echter Video- filmunterstützung in den letzten Jahren große Verbreitung durch Videoportale, wie Google Video5 oder YouTube6. Eine fünfte Möglichkeit Videos über das In- ternet im Browser wiederzugeben bietet die Programmiersprache Java. Die in Ja- va geschriebenen Programme können als Java-Applets direkt im Browser ausge- führt werden. Momentan ist jedoch kein Fall bekannt, bei dem ein Java Vide- oplayer in Form eines Applets im praktischen Einsatz ist.

Im Folgenden werden die oben genannten Videoformate näher vorgestellt und bezüglich ihres Funktionsumfangs, ihrer Flexibilität, ihrer Kompressionsqualität und ihrer Verfügbarkeit bei den Nutzern verglichen.

1 http://www.apple.com/trailers/ 2 http://www.moviemaze.de/ 3 http://www.prosieben.de/show_comedy/stromberg/videos/ 4 http://tagesschau.de/ 5 http://video.google.com/ 6 http://www.youtube.com/

-15- Webbrowserbasierte Lösungen zur Videoübertragung

2.1 Übertragungslösungen für Videos im Webbrowser

2.1.1 QuickTime

QuickTime ist ein Multimediaframework von Apple und wurde 1991 zum ersten Mal der Öffentlichkeit vorgestellt. Ziel war es Videos auf einem Heimcomputer, dem Apple Macintosh, ohne teure Spezialhardware abzuspielen. Die Größe der ersten Videos war aufgrund der begrenzten Rechenleistung der Computer und der mangelnden Speicherkapazität auf 156 x 116 Pixel beschränkt. Dies brachte ihnen den Spitznamen „Briefmarken-Filmche“ [KFVM03, S. 17] ein.

Mit der 1994 veröffentlichten Version 2 stand QuickTime auch für Windows und damit für die x86er PC-Architektur zur Verfügung. QuickTime Filme konnten mit dieser Version auch Bildschirm füllend wiedergegeben werden. Mit Version 3 wurde das Framework 1998 in eine Basis- und eine Pro-Version unterteilt. Wäh- rend die kostenfreie Basisversion lediglich zum Abspielen der QuickTime Filme geeignet ist, stehen dem Entwickler mit der kostenpflichtigen Pro-Version zahl- reiche Editorwerkzeuge zum Erstellen von Filmen zur Verfügung. In Version 3 wechselte Apple außerdem von dem bisher verwendeten Cinepack-Videocodec zum qualitativ besseren Sorenson-Codec. Mit der 1999 veröffentlichen Version 4 konnten QuickTime Filme auch erstmals über das Internet gestreamt werden. Apple stellt hierfür den Darwin Streaming-Server1 kostenlos zum Download zur Verfügung. Diese setzt jedoch das sehr exotische Serverbetriebssystem Mac OS X Server voraus.

In den nachfolgenden Versionen von QuickTime wurden sukzessiv zahlreiche weitere Neuerungen und Verbesserungen in das Framework integriert, darunter die Media Skins. Durch diese kann der Contentanbieter das Aussehen der Benut- zeroberfläche des Players verändern. Aktuell ist die Version 7 von QuickTime er- hältlich. Diese unterstützt zahlreiche moderne Video- und Audiocodes, wie H.264/MPEG-4 AVC, MP3 und AAC. Die Videodaten können dabei in allen be-

1 http://www.apple.com/de/quicktime/streamingserver/

-16- Webbrowserbasierte Lösungen zur Videoübertragung

liebigen Auflösungen bis hin zur vollen HDTV-Darstellung von 1920 x 1080 Pixel verarbeitet werden.

Da QuickTime nicht nur ein Videoformat ist, sondern ein komplettes Multimedia- framework, unterstützt der QuickTime Player auch die Anzeige von Texten, Standbildern, Vektorgrafiken und Animationen. Der QuickTime Moviecontainer kann dazu mehrere unabhängige Spuren enthalten, die jedes dieser Medien auf- nehmen können. So kann ein QuickTime Film zum Beispiel eine Videospur und mehrere Audiospuren enthalten. Eine Kombination aus Standbildern, Videos und Texten ist ebenso möglich. Auf diese Art und Weise können leicht mehrere ein- zelne Filme und andere Medien zu einem zusammenhängenden Objekt kombi- niert werden. Dies kann vom QuickTime Player dann als Einheit abgespielt wer- den. Da sich die einzelnen Spuren überlagern, sind auch Überblendeffekte zwi- schen einzelnen Filmen möglich. Überdies können Bitmaps als Logos oder Was- serzeichen über Videos gelegt werden. Die Kombinationsmöglichkeiten sind so- mit vielfältig.

Um einzelne Medien in den QuickTime Moviecontainer zu integrieren, gibt es zwei Möglichkeiten. Bei der Ersten werden die einzelnen Medien direkt in den QuickTime Moviecontainer eingebettet. Der Nutzer erhält so nur eine einzelne Datei, die alle benötigten Informationen und Daten enthält, um den gesamten Film anschauen zu können. Bei der zweiten Möglichkeit werden lediglich die Ab- spielinformationen und die Pfade zu den Bild- und Audiodaten im eigentlichen QuickTime Film gespeichert. Er fungiert hier nur als eine Art Playlist. Die Dateien mit den eigentlichen Bild- oder Audioinformationen werden extern gespeichert. Diese können auch auf verschiedenen Webservern abgelegt werden. Der Player greift dann während des Abspielens auf diese entfernten Dateien zu und stellt sie, entsprechend der im Film vorgegebenen Art und Weise zum eigentlichen Film zusammen. Dieses Verfahren wird Compositing genannt.

Neben den gewohnten Bedienelementen eines Videoplayers, wie das Abspielen, Stoppen und der schnelle Vor- oder Rücklauf, bietet QuickTime die Möglichkeit eigene Interaktionselemente zu erstellen. Diese können direkt in den Film integ- riert werden. So können beispielsweise klickbare Hotspots definiert werden, über

-17- Webbrowserbasierte Lösungen zur Videoübertragung

die an vorbestimmte Stellen im Film gesprungen oder Webseiten im Internet auf- gerufen werden können. Diese interaktiven Schaltflächen können auch mit einfa- chen Skripten zur Ablaufsteuerung des Players, wie „Stop“, „nächstes Kapitel“ oder Ähnlichem versehen werden. Auf diese Weise können zum Beispiel Menüs in QuickTime Filmen, ähnlich wie in DVDs, erstellt werden. Darüber hinaus kann mit der Markupsprache SMIL der Ablauf mehrer Medien gesteuert und synchro- nisiert werden. Besonders bei der Verwendung des QuickTime Browserplugins ergibt sich so eine einfache Möglichkeit multimediale Inhalte dynamisch mitein- ander zu kombinieren. Leider unterstützt QuickTime nur SMIL Version 1, welche nur einen eingeschränkten Funktionsumfang bietet. Animationen, Effekte und komplexe zeitliche Steuerungen sind der Version 2 vorbehalten. [W3C 1998].

Der QuickTime Player selbst ist ein vollwertiger Mediaplayer, der neben den QuickTime Filmen auch nahezu alle anderen verbreiteten Medienformate, darun- ter MPEG, AVI, MP3, WAV, BMP und JEPG, wiedergeben kann. Er unterstützt Userskins, über die sich der Benutzer das Aussehen seines QuickTime Players anpassen kann. Abbildung 7 zeigt den QuickTime Player mit Standardskin für die stand-alone Variante und als Browserplugin. Zusätzlich besteht auch für den Contentanbieter die Möglichkeit das Aussehen des QuickTime Players zu verän- dern. Dafür kann in den QuickTime Film ein so genannter Media Skin eingebettet werden, der das Erscheinungsbild für die Dauer des Films verändert. Der Player wird so selbst zu einem Teil des Films und bei Bedarf optisch völlig integriert. Ein Beispiel dafür ist in Abbildung 8 zu sehen. Die Oberfläche und Steuerelemente wurden mit thematisch zum Film passenden Grafiken versehen. Die Form der Oberfläche ist dabei nicht auf ein einfaches Rechteck festgelegt. Leider unterstützt nur die stand-alone Variante des QuickTime Players Media Skins. Beim Abspie- len des Films über das QuickTime Plugin im Webbrowser bleiben die Media Skins hingegen wirkungslos. Das Aussehen des Browserplugins lässt sich also nicht direkt beeinflussen. Mit JavaScript kann lediglich die Kontrollleiste mit den Steuerelementen, siehe in Abbildung 7 rechts, abgeschaltet werden. Die Steue- rung kann dann durch eigene HTML-Elemente und JavaScript übernommen werden [Apple 2005b]. Das Scripting des Plugins funktioniert jedoch nicht in al- len Browsern zuverlässig. Es kann auch bei einem nicht korrekt installierten Plu- gin oder bei Plugins von Drittherstellern zu unerwartetem Verhalten kommen.

-18- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 7: QuickTime Player mit Standardoberfläche (links) und Browserplugin

Abbildung 8: QuickTime Player mit im Film eingebettetem Media Skin (Quelle: Apple Inc.)

QuickTime ist auf allen aktuellen Apple Macintosh Systemen vorinstalliert, da es mit dem Betriebsystem MacOS ausgeliefert wird. Nutzer von Windows-PCs kön- nen QuickTime gratis von der Apple-Webseite beziehen1. Das Installationspaket umfasst in der aktuellen Version 7.1.3.100 ca. 18,7 MiB. Das Betriebssystem Linux wird von Apple nicht unterstützt. Sowohl für Windows als auch für Linux gibt es jedoch alternative Projekte um QuickTime Filme abspielen zu können. Für Win- dows steht zum Beispiel das kostenlose Paket „QuickTime Alternative“2 zur Ver- fügung. Dieses Paket wird gern von Nutzern eingesetzt, die eine einfache Mög- lichkeit suchen QuickTime Filme mit einem bereits installierten Mediaplayer ab- zuspielen und ansonsten auf die zusätzlichen Inhalte des QuickTime Installati-

1 http://www.apple.com/de/quicktime/download/ 2 http://www.free-codecs.com/download/QuickTime_Alternative.htm

-19- Webbrowserbasierte Lösungen zur Videoübertragung

onspakets verzichten. Für Linux kann der weit verbreitete und frei erhältliche MPlayer1 zum Abspielen von QuickTime Filmen eingesetzte werden. Beide ge- nannten Alternativen bringen auch ein Browserplugin für QuickTime Filme mit, bzw. lassen sich als solches einsetzen. Da sie jedoch nicht vom Hersteller Apple unterstützt werden, kann auch nicht garantiert werden, dass sie den vollen Funk- tionsumfang des QuickTime Formats unterstützen.

2.1.2 RealVideo

Die Firma RealNetworks, früher unter dem Namen Progressive Networks be- kannt, gehört zu den Pionieren im Bereich Videostreaming. 1994 veröffentlichte das Unternehmen die erste Version seines Streamingmedia Players RealPlayer. Der RealPlayer 1.0 unterstützte zunächst lediglich das von Progressive Networks entwickelte proprietäre RealAudio Format, welcher nur Audiodaten verarbeiten konnte. Dieser Umstand war vor allem der geringen Rechenleistung der damals üblichen PCs, sowie der geringen Übertragungsrate der analogen Modemverbin- dungen geschuldet.

1997 erschien die vierte Version des RealPlayers, die als Erste auch das Abspielen von Videos unterstützte. Zum Einsatz kam dabei, wie schon bei RealAudio, der von Progressive Networks selbst entwickelte Codec. Noch im selben Jahr folgte Version 5, welche zusammen mit einem überarbeiteten Codec bessere Qualität versprach. Außerdem unterstütze sie erstmals eine Bildschirm füllende Wieder- gabe von Videos. Zum Leidwesen der Nutzer wurde jedoch auch die Einblen- dung von Werbebannern eingeführt. In späteren Versionen wurde dies durch die Integration kommerzieller Musikshops, Kaufangebote und einem „Meldung- Center“ für regelmäßige Werbemeldungen erweitert.

1998 stellte RealNetworks den RealPlayer G2 vor. Dabei steht G2 für „zweite Ge- neration“. Das neue System unterstütze weitere Medienformate wie AVI, JPEG, MPEG und WAV. Außerdem sind neue Techniken, wie das RealTime Streaming Protocol (RTSP), sowie Unterstützung für die vom W3C standardisierte Multi- media Markupsprache SMIL integriert. Mit RealPix und RealText erweiterte Real-

1 http://www.mplayerhq.hu/

-20- Webbrowserbasierte Lösungen zur Videoübertragung

Networks den Player zudem um zwei proprietäre Verfahren zum Streaming von Bildern und Texten, die beide auf einer eigenen Markupsprache aufbauen. Mittels SureStream wurde zudem eine eigene Technik angeboten, die es ermöglicht die Videostreams abhängig von der zur Verfügung stehenden Bandbreite beim Nut- zer in verschiedener Qualität abzuspielen. Dies setzt jedoch voraus, dass der Re- alServer als Streaming Server eingesetzt wird und die Videos zuvor in den ver- schiedenen Bandbreiten, die angeboten werden sollen, in die Streamdatei integ- riert wurden. Bei der Übertragung von einem normalen Webserver darf jede Vi- deodatei nur in einer Bitrate codiert sein, andernfalls würden alle codierten Bitra- ten gleichzeitig ausgesendet.

Der aktuelle RealPlayer liegt in Version 10 vor. Neben einer kostenpflichtigen Pro-Variante ist er auch, wie alle seine Vorgänger, in einer kostenlosen Standard Ausführung erhältlich. Die wichtigsten Neuerungen vom RealPlayer G2 bis zur aktuellen Version sind neben einigen zusätzlichen Tools eine neue Oberfläche, sowie eine verbesserte Qualität bei der Video- und Audiokompression. So be- hauptet RealNetworks, dass RealVideo 10 gegenüber dem Vorgänger rund 30% und gegenüber H.264 15% weniger Speicherplatz benötige, um die gleiche Quali- tät zu erreichen [RealNetworks 2003]. Ein Vergleich der Kompressionsleistung mit den andern hier vorgestellten Videoübertragungslösungen wird in Kapitel 2.2 vorgenommen. Beim Einsatz des jeweils aktuellsten RealVideo Codecs ist zu be- achten, dass dieser nicht kompatibel mit älteren RealPlayer Versionen ist. Dies er- fordert daher immer ein Upgrade des RealPlayers beim Nutzer. Der aktuelle Re- alVideo 10 Codec stellt hier bisher die einzige Ausnahme dar, da er auch auf dem RealPlayer 9 wiedergegeben werden kann.

Mit jeder neuen Version des RealPlayers wurde neben der Videoqualität auch der Funktionsumfang erweitert. So wurde zum Beispiel bereits 1999 in der Version G2 der Instant Messaging Service von AOL integriert. Der aktuelle RealPlayer wird auf der Homepage von RealNetworks1 im Bundle mit zahlreichen kosten- pflichtigen Abo-Angeboten wie Musik und Klingeltondownloads beworben. Die

1 http://www.real.com/

-21- Webbrowserbasierte Lösungen zur Videoübertragung

Integration von CD-Ripper, CD-Brenner, Webbrowser, Instant Messaging, Shop- pingangeboten, Spielen, Werbe- und Downloadangeboten haben allein die kos- tenlose Standardausführung des RealPlayer 10 auf einen Umfang von über 53 MiB wachsen lassen. Die Fülle an zusätzlichen Funktionen haben die ursprüngli- che Aufgabe der Audio- und Videowiedergabe etwas in den Hintergrund rücken lassen. Dieser Umstand macht den RealPlayer für viele Nutzer uninteressant, da sie zum Beispiel lediglich das Browserplugin zur Wiedergabe von Videostreams im Internet haben möchten. Separat wird das Browserplugin jedoch nicht angebo- ten. Dies könnte auch einer der Gründe sein, warum die Verbreitung des RealPlayers von einst fast 80% (Firmenangaben, zitiert aus [Künkel 2001]) auf heute kaum mehr als 43% (eigene Erhebung, Weiteres in Kapitel 2.3) gesunken ist. Dabei bietet RealNetworks den RealPlayer für Windows, Linux sowie MacOS an. Er steht somit für alle verbreiteten Betriebsysteme zur Verfügung.

Die Oberfläche des RealPlayers kann der Nutzer durch Skins optisch dem eige- nen Geschmack anpassen. Abbildung 9 zeigt die aktuelle Version des RealPlayers mit Standardoberfläche, sowie das Browserplugin. Eine Änderung des Aussehens durch den Contentanbieter, etwa um Inhalte in einer thematisch angepassten O- berfläche wiederzugeben, ist nicht möglich. Die einzelnen Bedienelemente des RealPlayer Browserplugins können allerdings über JavaScript an- bzw. abge- schaltet werden. Auf diesem Weg können auch eigene Grafiken, HTML-Elemente oder Buttons in der Webseite die Funktion der Steuerelemente übernehmen. Der RealPlayer kann so durch JavaScript in ein eigenes, auf HTML basierendes Lay- out integriert werden [RealNetworks 2001]. In Kombination mit Geckoengine- basierten Browsern, wie dem Firefox, kann es jedoch vorkommen, dass das Scrip- ting des RealPlayers nicht zuverlässig funktioniert. Dies tritt vor allem dann auf, wenn zuvor der RealPlayer und erst anschließend Firefox installiert wurde. Wie schon für QuickTime gibt es auch für den RealVideo alternative Abspielmöglich- keiten, die ebenfalls ein Browserplugin mitliefern. Für Windows ist das zum Bei- spiel die „Real Alternative“1 und für Linux der MPlayer. Beide Pakete sind vor allem bei Nutzern beliebt, die gern auf die umfangreiche stand-alone Version des

1 http://www.free-codecs.com/download/Real_Alternative.htm

-22- Webbrowserbasierte Lösungen zur Videoübertragung

RealPlayers verzichten möchten und nur das Browserplugin benötigen. Da beide nicht offiziell von RealNetworks unterstützt werden, kann auch nicht garantiert werden, dass sie alle Funktionen des RealPlayers inklusive der Scriptingkompati- bilität beherrschen.

Abbildung 9: RealPlayer 10 mit Standardskin (links) und Standardansicht des Browserplugins

Mit dem separat erhältlichen RealProducer bietet RealNetworks ein umfangrei- ches Werkzeug zur Erstellung von RealVideo und RealAudio Streams an. Die kostenlose Variante „Basic“ ist jedoch in einigen Funktionen beschränkt und er- zeugt lediglich zur aktuellen RealPlayer-Version kompatible Streams. Die unein- geschränkte „Pro“-Version kostet 199 US-Dollar. Sie bietet vor allem eine Batch- Verarbeitung, Steuerung über die Kommandozeile, Job-Files, grundlegende Vi- deobearbeitungsfunktionen und Unterstützung für mehrere Streaming Server. Um Streams mit der aktuellsten Version des RealVideo Codecs zu erzeugen, ist der RealProducer zwingend erforderlich. Videolösungen von Fremdherstellern oder Freewareprodukte hängen hier in der Regel ein oder zwei Generationen hin- terher.

Um alle Funktion von RealVideo, wie etwa Live-Streaming, On-Demand- Streaming oder SureStream nutzen zu können, muss zudem der Helix Server1 von Realnetworks eingesetzt werden. Dieser schlägt jedoch mit hohen Lizenzkos-

1 http://www.realnetworks.com/products/media_delivery.html

-23- Webbrowserbasierte Lösungen zur Videoübertragung

ten zu Buche. So kostet die einfachste Variante für bis zu 25 simultane Streams momentan ab etwa 2200 Euro. Eine Lizenz für die unbeschränkte Version ist ab etwa 17.000 Euro erhältlich. Alternativ können auch kostengünstige Angebote von Streaminghostern eingesetzt werden, die komplette Serversysteme zur Miete zur Verfügung stellen. RealVideo kann jedoch auch als einfacher Progressive Download von einem normalen Webserver über HTTP angeboten werden. Die Real spezifischen Funktionen stehen dann allerdings nicht zur Verfügung.

2.1.3 Windows Media

Microsofts Engagement im Bereich Streaming Media setzte spät ein. Erst 1997 entschloss sich der Konzern mit einer eigenen Technologieplattform ernsthaft in den Markt einzusteigen, in dem sich bis dahin Apple und vor allem RealNet- works als Markführer etabliert hatten. Unter dem Namen Windows Media Tech- nologie 4 veröffentlichte Microsoft ein Paket aus verschiedenen Werkzeugen und Programmen bestehend, um Streaming Medien zu produzieren, auszuliefern und wiederzugeben. Zentrale Bestandteile waren damals wie heute der Windows Media Encoder, der Windows Media Player und Windows Media Services als Streaming Server. Microsoft trieb die Entwicklung von Windows Media Techno- logie mit Hochdruck voran. So folgte bereits im Jahr 2000 die Version 7. Diese fand vor allem durch ihre Integration bei den damals aktuellen Windowsversio- nen 2000 und ME große Verbreitung. Microsoft konnte so vor allem seine große Marktmacht einsetzen, um den Konkurrenten Marktanteile abzuringen. Die aktu- elle Version von Windows Media Technologie trägt die Nummer 9 und wurde 2003 veröffentlicht. Einzelne Komponenten wie der Windows Media Player lie- gen darüber hinaus bereits in Version 11 vor. Die wichtigsten Verbesserungen gegenüber den Vorgängerversionen sind eine verbesserte Videoqualität, Unter- stützung für Videos in HDTV-Auflösung und die Fast Streaming genannte Ver- besserungen bei der Übertragung.

Die Integration des Windows Media Player 9 in das Service Pack 2 für Windows XP hat mit dem Markterfolg dieses Betriebssystems auch dafür gesorgt, dass Windows Media Videos heute auf fast allen Windowsbasierten Computern wie-

-24- Webbrowserbasierte Lösungen zur Videoübertragung

dergegeben werden können. Microsoft bietet auf der Windows Media Homepa- ge1 jedoch auch separate Installationspakete an, um den Windows Media Player oder auch nur die Windows Media 9 Codecs nachträglich zu installieren oder zu aktualisieren. Offiziell unterstützt werden dabei die Betriebsysteme Windows 2000, Windows XP und Mac OS X. Für Linux gibt es derzeit keine direkte Unter- stützung von Microsoft. Der bereits für QuickTime als Ersatz dienende MPlayer schafft aber auch hier Abhilfe und spielt Windows Media Videos auch auf Linux- basierten Rechnern ab. Wiedergabeplugins für alle aktuellen Webrowser sind in den Installationspaketen der jeweiligen Player enthalten. Der Windows Media Player ist, wie auch seine Pendants von Apple und RealNetworks ein vollwerti- ger Media Player. Er kann daher neben dem hauseigenen Format auch DVDs so- wie viele andere Videoformate deren Codecs auf dem System installiert sind, wiedergeben. Die Oberfläche des Windows Media Player kann der Nutzer durch Skins frei gestalten. Auch der Videoanbieter kann dem Player ein an den Film angepasstes Aussehen geben. Dazu muss das Skin-Tag in der XML-ähnlich auf- gebauten Streambeschreibungsdatei auf eine bereitgestellte Skin-Datei verweisen. Diese „Borders“ genannten Oberflächen des Videoanbieters werden von Micro- soft aber als deprecated (abgelehnt) bezeichnet [Microsoft 2006c]. Sie werden da- her in zukünftigen Versionen des Windows Media Players nicht mehr unterstützt werden. Beide Varianten, das Aussehen des Windows Media Players zu verän- dern, funktionieren außerdem nur mit der stand-alone Version. Das Aussehen des Browserplugins lässt sich nicht verändern. Wie beim RealPlayer-plugin, kön- nen bei der Einbettung in den HTML-Code lediglich die Bedienelemente des Plu- gins ein- oder ausblendet werden. Eine Steuerung des Players ist dann über Ja- vaScript möglich. Abbildung 10 zeigt den Windows Media Player 11 für Win- dows XP mit Standardoberfläche und das Windows Media Browserplugin.

Als Videocodec für Windows Media Technologies setzte Microsoft anfänglich auf den MPEG 4 Standard. Dies erlaubte Windows Media von Beginn an eine hohe Qualität bei geringen Datenraten. Während der Weiterentwicklung zu Windows Media 7 und 9 entfernte sich Microsoft jedoch immer weiter vom ISO Standard

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

-25- Webbrowserbasierte Lösungen zur Videoübertragung

und vermarktet den Codec nun als Windows Media Video 9. Dieser ist inkompa- tibel mit anderen, standardkonformen Implementationen von MPEG 4, verspricht jedoch eine deutlich gesteigerte Bildqualität, besonders bei mittleren und niedri- gen Bitraten [Microsoft 2006b]. Eine nähere Betrachtung der Videoqualität erfolgt in Kapitel 2.2.

Abbildung 10: Windows Media Player 11 (links) und Standardansicht des Browserplugin

Zum Erzeugen von Windows Media Videos stellt Microsoft den Windows Media Encoder zur Verfügung. Dieses Programm lässt sich intuitiv bedienen und bietet alle nötigen Einstellungen zur Produktion von Windows Media Videos. Es unter- stützt neben CBR Enkodierung auch VBR Enkodierungen in mehreren Durch- gängen. Zur Batchverarbeitung mehrer Videos wird ein Kommandozeilenwerk- zeug mitgeliefert. Ähnlich wie auch RealVideo unterstützt Windows Media Vi- deo das Encoding in mehreren Streamingqualitäten. Diese, bei Windows Media Multibit genannte Technik sorgt dafür, dass beim Streaming des Videos automa- tisch die am Besten zur Bandbreite des Clients passende Bitrate zur Übertragung ausgewählt wird. Dazu muss das Video in mehreren Bitraten enkodiert und in der Videodatei hinterlegt werden. Der Einsatz dieser Technik setzt jedoch zwin- gend die Windows Media Services als Streaming Server voraus. Dieser wird von Microsoft zwar kostenlos zur Verfügung gestellt, setzt jedoch seinerseits mindes- tens Windows Server 2003 als Betriebssystem voraus. Durch die Kombination

-26- Webbrowserbasierte Lösungen zur Videoübertragung

von Windows Media Encoder und Windows Media Services ist es außerdem möglich Videos live zu übertragen.

Sowohl den Encoder, als auch die Windows Media Services stellt Microsoft kos- tenlos zur Verfügung. Es ist jedoch zu beachten, dass der Streaming Dienst Microsofts Serverbetriebsystem Microsoft Windows Server 2003 als Betriebs- grundlage voraussetzt.

Durch so genannte Advanced Stream Redirector können für Windows Media ein- fache Video Playlisten zusammengestellt werden. Ein Advanced Stream Redirec- tor ist eine an XML angelehnte Textdatei mit der Endung ASX. Die darin aufgelis- teten Clips werden im Player nacheinander abgespielt. Sie können mit einigen Metadaten, wie zum Beispiel einem Titel oder dem Namen des Autors versehen werden. Außerdem sind Einblendungen von Logos oder klickbaren Werbeban- nern im Player möglich. Eine freie Positionierung dieser Elemente ist jedoch nicht möglich. Sie erscheinen im Player immer an der dafür vorgesehenen Standardpo- sition. Generell sind die Möglichkeiten des Playlistformats wenig flexibel. Anima- tionen, die Anzeige von Begleitinformationen oder interaktive Elemente werden nicht unterstützt. Dafür kann in der Playlistenbeschreibung festgelegt werden für welches Video die Playerkontrollen für den Nutzer freigeschaltet oder blockiert werden sollen. [Microsoft 2006d] Dies ist etwa für Werbeeinblendungen nützlich, die nicht übersprungen werden können sollen.

Eine Besonderheit von Windows Media ist jedoch die Unterstützung von Mobilen Endgeräten. Windows Media Videos können auf vielen Mobilgeräten wie PDAs, Smartphones oder Handys mit Windows CE als Betriebsystem wiedergegeben werden – auch als Stream über das Internet.

2.1.4 Adobe Flash

Im Gegensatz zu den bisher untersuchten Techniken handelt es sich bei Flash nicht primär um eine Video-Lösung. Vielmehr ist Flash ein umfangreiches Authoring-Werkzeug zur Erstellung von sogenannten Flashfilmen. Dabei handelt es sich um teils interaktive Animationen oder Anwendungen, welche hauptsäch- lich auf Internetseiten eingesetzt werden. Ursprünglich wurde Flash von der Fir- ma Macromedia auf Basis des „Future Splash Animator“ der Firma FutureWave

-27- Webbrowserbasierte Lösungen zur Videoübertragung

entwickelt [Rick Waldron 2006]. Die erste Version von Flash veröffentlichte Mac- romedia Ende 1996. Der Funktionsumfang dieser Version beschränkte sich auf Animationen von Vektor- und Rastergrafiken sowie der Möglichkeit zur Audio- wiedergabe. Bereits ein halbes Jahr später folgte Version 2 mit der Unterstützung für einfache Nutzerinteraktionen. In den folgenden Jahren wurde Flash um zahl- reiche neue Funktionen und Möglichkeiten erweitert. Die Verarbeitungsge- schwindigkeit der Flashfilme wurde immer wieder verbessert und die Autho- ring-Umgebung optimiert. Ein wichtiger Meilenstein war dabei die im Jahr 2000 erschienene Version 5. In dieser Version wurde die Scriptsprache ActionScript 1.0 für Flash eingeführt. Diese stellt seither eine elementare Komponente von Flash dar, die bis heute immer mehr Bedeutung gewinnt. Durch ActionScript ist es möglich komplexe Anwendungen auf Basis von Flash zu erstellen, Eingaben zu verarbeiten, aus der Flashanwendung über das Internet mit einem Server zu kommunizieren oder ganze Flashfilme allein durch Scripte zu erstellen. Außer- dem wurde in Version 5 die Unterstützung für XML-Daten integriert, womit seit- her ein flexibles, standardisiertes Datenaustauschformat zur Verfügung steht. Ac- tionScript wurde mit der 2003 veröffentlichten Version 7 (Flash MX 2004) auf Version 2.0 erweitert. ActionScript unterstützt seitdem objektorientierte Pro- grammierung. Durch die Möglichkeit den ActionScript-codes in separate Dateien auszulagern wird die Programmlogik zudem besser von der Grafikerstellung ge- trennt, was der Übersicht bei der Erstellung von Flashanwendungen sehr zu Gute kommt.

Die Unterstützung für Videos ist in Flash seit der Version 6, auch Flash MX ge- nannt, integriert. Diese wurde 2002 veröffentlicht. Verglichen mit RealVideo, QuickTime Video und Windows Media Video ist dies sehr spät. Durch seine wei- te Verbreitung für Animationen auf Webseiten hatte Flash jedoch bereits eine gu- te Ausgangssituation, um auch im Internetvideomarkt schnell Fuß zu fassen und den Konkurrenten Marktanteile abzunehmen. Für die Komprimierung der Vide- os lizenzierte Macromedia den Sorenson Spark Codec, auf den zu dieser Zeit auch QuickTime setzte.

Momentan ist die Version 8 von Flash aktuell. Die wichtigsten Neuerungen dieser Version sind neue Filtereffekte, Leistungssteigerungen beim Abspielen von Flash-

-28- Webbrowserbasierte Lösungen zur Videoübertragung

filmen und die Einführung des neuen, leistungsfähigeren Videocodecs VP6 von On2. Der Hersteller verspricht dabei eine den Konkurrenzformaten Windows Media 9 und RealVideo 9 überlegene Videoqualität bei gleicher Bitrate [On2 2006]. Inwiefern der Codec dieses Versprechen hält, wird in Kapitel 2.2 unter- sucht. Flash 8 wurde 2005 noch unter dem Namen Macromedia Flash 8 veröffent- licht. Mit der Übernahme von Macromedia durch die Firma Adobe änderte sich auch der Name in Adobe Flash 8. Die Veröffentlichung von Version 9 von Adobe Flash wird für den Sommer 2007 erwartet. Eine der wichtigsten Neuerung wird die Erweiterung von ActionScript zu Version 3.0 sein.

Die Handhabung von Videos ist in Flash vollkommen anders als bei den bisher vorgestellten Videolösungen. Als Multimedia-Authoring-Umgebung stellt Flash nicht einfach einen Player zur Video Wiedergabe dar. Tatsächlich stellt Flash noch nicht einmal einen solchen fertigen Videoplayer zur Verfügung. Vielmehr erstellt der Videoanbieter mithilfe von Flash eine Videowiedergabeanwendung, die dann als Flashanwendung eingebettet in einer Webseite dem Nutzer zur Ver- fügung gestellt wird. Abbildung 11 zeigt den „FLV Player“ von Martijn de Visser als Beispiel wie ein solcher selbst gestalteter Player aussehen kann. Martijn de Vissers Quelloffene Player wird selbst gern als Ausgangsbasis für eigens ange- passte Flash Videoplayer verwendet. So nutzt ihn etwa die ARD für Videoschlag- zeilen der tagesschau auf deren Homepage.

Abbildung 11: FLV Player von Martijn de Visser (Quelle: [Martijn de Visser 2006])

-29- Webbrowserbasierte Lösungen zur Videoübertragung

Bei der Erstellung eines solchen Flash Videoplayers stehen dem Autor sämtliche gestalterischen und technischen Möglichkeiten von Flash zur Verfügung und die- se sind im Bezug auf Videos außergewöhnlich viele. Videofilme werden in Flash, wie andere Grafiken, Animationen oder Texte, als so genannte MovieClips be- handelt. Diese internen Objekte können in der Flashanwendung beliebig positio- niert oder in Ebenen übereinander gelegt werden. Sie können überblendet, ge- dreht, skaliert, verzerrt, maskiert oder mit Filtern verändert werden. Dies kann alles live, parallel zum Ablauf der Anwendung und während der Wiedergabe des oder der Videos geschehen. Auf diese Art ist eine völlig freie Kombination belie- biger Medientypen wie Bilder, Text, Audio und Video möglich. Besonders inte- ressant ist in diesem Zusammenhang auch, dass der von Flash verwendete VP6 Codec die Enkodierung eines Alphakanals unterstützt. Auf diese Art können im Video beliebige Bereiche als transparent festgelegt werden. Videos können so vielseitig als Overlaykomponente eingesetzt werden, etwa in Form eines Video- Logos oder eines gefilmten Avatars.

Ein weiterer wichtiger Bestandteil von Flash ist Actionscript. Mit ActionScript steht dem Autor eine mächtige Scriptsprache zur Verfügung Abläufe zu steuern und insbesondere Interaktivität hinzuzufügen. Von einfachen Maus- und Tasta- tureingaben über komplexe Formulare bis hin zu interaktiven Spielen ist alles möglich. Flash bietet daher nicht einfach nur die Möglichkeit Videos abzuspielen, sondern sie in eine eigene, beliebig komplexe multimediale Anwendung zu integ- rieren und mit anderen Medien zu kombinieren. Dabei ist der Autor auch nicht auf die Flashanwendung allein beschränkt. Mittels JavaScript kann er außerdem mit den Elementen der Webseite kommunizieren, in welcher die Flashanwen- dung integriert ist. Damit der Autor einer Flashanwendung zur Videowiedergabe die grundlegenden Steuerungen wie Abspielen, Pause, Stopp, etc. nicht jedes Mal neu entwickeln muss, wurde dem Flash 8 Editor eine Videokomponente beige- legt, die diese Funktionen bereit stellt. Sie kann im eigenen Flashprojekt einfach eingesetzt und leicht an das eigene Design anpasst werden.

In Flash stehen drei Möglichkeiten zur Verfügung aus der Flashanwendung her- aus auf Videodaten zuzugreifen. Die einfachste aber am wenigsten flexible ist, das Video direkt in die Flashanwendung zu integrieren. Das ist vor allem sinn-

-30- Webbrowserbasierte Lösungen zur Videoübertragung

voll, wenn das Video fester Bestandteil der Anwendung ist, etwa als bewegter Hintergrund oder animiertes Logo. Die am häufigsten genutzte Möglichkeit hin- gegen ist, das Video per progressive Download von einem Webserver nachzula- den. Diese Möglichkeit bietet mehr Flexibilität bei der Wiedergabe vieler ver- schiedener Viedeos. Sie hält aber gleichzeitig den zusätzlichen Aufwand gering, da der zur Auslieferung der Flashanwendung genutzte Webserver auch die Vi- deos übertragen kann. Bei der dritten Möglichkeit wird das Video als on-demand oder live Stream von einem Flash Media Server übertragen. Dieser wird von A- dobe derzeit für 4759 EUR zuzüglich Umsatzsteuer angeboten. Als Besonderheit können mit dem Flash Media Server auch Videos vom Nutzer zum Server und von dort wieder zu anderen Nutzern übertragen werden. Auf diese Weise lassen sich mit Flash sogar beliebig gestaltete, interaktive Videochatanwendungen erstellen, vorausgesetzt der Nutzer verfügt über eine Webcam.

Zur Produktion von Flashvideos (FLV) liefert Adobe zusammen mit der Autho- ring-Umgebung auch einen Videoencoder aus. Dieser kann Videos mit beiden von Flash unterstützten Videocodes enkodieren. Dabei kommt wahlweise das single pass Verfahren mit konstanter Bitrate oder das multi pass Verfahren mit variabler Bitrate zum Einsatz. Der Encoder unterstützt einfache Videoschnittauf- gaben, wie Änderung der Bildgröße und Kürzen des Eingangsvideos. Ein Werk- zeug zur Batchverarbeitung mehrerer Filme ist ebenfalls enthalten. Außerdem bringt Flash Exportplugins für einige der wichtigsten Videoschnittwerkzeuge mit, wie z.B. Adobe Premiere, Adobe After Effects, Avid Xpress und Apple QuickTime Pro. Zusätzlich bieten die Dritthersteller On21 und Sorenson2 kosten- pflichtige, vollwertige FLV-Encoder für Flashvideo an. Zahlreiche kostenlose FLV-Encoder sind auf Basis des Open Source Projekts FFMPEG3 verfügbar. Einer der bekanntesten ist der der Riva FLV Encoder4.

Die wichtigste Komponente von Flash für den Nutzer ist der Flash Player. Hier- bei handelt es sich um eine Laufzeitumgebung die zur Wiedergabe und Ausfüh-

1 On2 Flix Exporter 8 for Flash: http://www.on2.com/consumer/flix-exporter/ 2 Sorenson Squeeze 4.3 Compression Suite: http://www.sorensontech.com/solutions/prod/comp_win.php 3 FFMPEG: http://ffmpeg.mplayerhq.hu/ 4 Riva FLV Encoder: http://www.rivavx.com/index.php?id=483&L=0

-31- Webbrowserbasierte Lösungen zur Videoübertragung

rung von Flashfilmen und -anwendungen benötigt wird. Mit jeder neuen Version von Flash wurde auch eine neue Version des Flash Players zur Unterstützung der neusten Funktionen notwendig. Endnutzer können sich den Flash Player als Browserplugin auf der Homerpage von Adobe kostenlos herunterladen1. Der Flash Player steht für Windows, Mac OS und Linux zur Verfügung und unter- stützt damit alle wichtigen Betriebsysteme. Die aktuelle Version 9 wurde im No- vember 2006 veröffentlicht. Dieser unterstützt bereits die Funktionen der nächs- ten Flash-Version. Adobe sorgt so bis zu deren Veröffentlichung schon für eine breite Basis installierte Player vor. Mit weniger als 1,5 MiB (Windows Version) ist das Installationspaket für den Flash Player verglichen mit den bisher betrachteten Videolösungen, sehr klein. Er kann daher selbst von Nutzern mit schmalbandi- gen Internetverbindungen, wie analogem Modem oder ISDN, in kurzer Zeit her- untergeladen werden. Dies kann einer der Gründe für die hohe Verbreitung des Flash Players unter den Internetnutzern sein. Nach Angaben von Adobe liegt sie weltweit bei rund 97% [Adobe 2006a]. Ein anderer Grund für die hohe Verbrei- tung ist, dass sich Flash über die Zeit mangels Konkurrenz zum Quasistandard für Animationen und Vektorgrafiken im Internet entwickelt hat. Die W3C- Standard SVG für Vektoranimationen hat sich aufgrund fehlender Unterstützung bei den Browserherstellern bis heute kaum durchgesetzt. Die beiden aktuellsten Versionen des Browsermarktführers Internet Explorer unterstützen SVG nicht und die Weiterentwicklung des bisher am weitesten verbreiteten SVG Plugins „SVG Viewer“ wird Adobe aufgrund der Konkurrenz zum hauseigenen Flash- format 2008 einstellen [Adobe 2006c]. Ein Konkurrenzformat zu Flash mit nen- nenswerter Nutzerbasis ist daher auf absehbare Zeit nicht in Sicht.

Adobe weitet die Unterstützung für Flashfilme momentan auf den Markt der Mobilen Geräte aus. Mit dem Flash Player Lite bietet Adobe die Flash- Laufzeitumgebung für Mobile Geräte wie Handy, Smartphones und PDAs an [Adobe 2006d]. Die für Mitte 2007 angekündigte Version 3 von Flash Lite bringt dann auch das Flashvideo Format in die Welt der mobilen Systeme. Mit Windows Mobile, Symbian S60 und Qualcomm BREW sollen dabei drei der wichtigsten

1 http://www.adobe.com/shockwave/download/?P1_Prod_Version=ShockwaveFlash

-32- Webbrowserbasierte Lösungen zur Videoübertragung

mobilen Betriebssysteme unterstützt werden [heise 2007]. Durch die beliebten Videotauschportale wie Youtube und Google Video, welche ebenfalls auf die Flashtechnik setzten, könnte sich auch die Mobilversion des Flash Players schnell verbreiten.

Die aktuelle Authoring-Umgebung Adobe Flash 8 wird momentan einzeln für US $ 699 angeboten oder als Bestandteil des Webentwicklungspakets Studio 8, wel- ches für US $ 999 verkauft wird.

2.1.5 Java

Java ist eine von SUN Microsystems entwickelte Plattformunabhängige Pro- grammiersprache [SUN 2005]. Die Plattformunabhängigkeit wird erreicht, durch eine spezielle Laufzeitumgebung, die Java Virtual Machine in der die Javapro- gramme ausgeführt werden. Diese JVM wird von SUN für praktisch alle relevan- ten Betriebssysteme angeboten. Die Installationspakete für Windows und Linux sind jeweils rund 16 MiB groß und können auf der von SUN betriebenen Java- Homepage1 kostenlos heruntergeladen werden. Eine spezielle Variante von Java- programmen, die sogenannten Applets, können direkt über das Internet im Web- browser gestartet werden. Das dafür benötigte Browserplugin ist im Installati- onspaket der JVM enthalten.

Java bringt an sich keine Bibliotheken zur Videoverarbeitung mit. SUN hat hier- für explizit das Java Media Framework (JMF) entwickelt, welches ebenfalls kos- tenlos erhältlich ist [SUN 2004]. Die JMF API unterstützt die Übertragung von Video- und Audiodaten von einem Streaming Server über RTP/RTSP. Ein einfa- cher Player kann dabei schon mit wenigen Codezeilen, sowohl als eigene An- wendung wie auch als Applet für den Browser, implementiert werden,. Einfache Benutzeroberflächen für den Player können mit der GUI-Bibliothek AWT erstellt werden. Diese bildet die bekannten Standardbedienelemente des Betriebsystems nach. Oberflächen mit beliebigem Design sind jedoch im Vergleich zu den ande- ren vorgestellten Videoübertragungslösungen recht aufwendig zu implementie- ren. Dies gilt besonders für animierte Bedienelemente.

1 http://www.java.com/de/download/manual.jsp

-33- Webbrowserbasierte Lösungen zur Videoübertragung

Leider hat das JMF einen gravierenden Nachteil. Es unterstützt lediglich einige veraltete und wenig effiziente Codecs des QuickTime Formats, sowie das MPEG1 Format. Letzteres kann sogar nur mit den speziellen Linux- und Windows- Varianten des JMF benutzt werden. Aus heutiger Sicht ist die Kompressionsleis- tung dieser Codecs völlig unzureichend, insbesondere für Streaming über das In- ternet. Ein praktischer Einsatz von Java mit JMF für Internetvideoangebote kommt daher kaum in Frage. Es sind derzeit auch keine Beispiele bekannt, die davon Gebrauch machen würden. Leider hat es zudem den Anschein, dass SUN die Weiterentwicklung des JMF eingestellt hat. Die letzte Überarbeitung der API ist datiert auf 1999 und die letzte Bugfix-Version des gesamten Frameworks wur- de im Mai 2003 veröffentlicht.

Eine alternative Java-Bibliothek zur Videowiedergabe mit Java stammt von IBM. Das „IBM Toolkit for MPEG-4“ unterstützt sowohl die Wiedergabe als auch die Produktion von Mediendaten im MPEG 4 Standard [IBM 2006]. Damit steht für Java ein leistungsfähiger Videocodec zur Verfügung. Durch eine nahezu voll- ständige Implementierung des MPEG 4 Standards ist die Wiedergabe zudem nicht auf reine Audio- und Videodaten beschränkt. Ferner können eingebettet in die MPEG 4-Mediendatei 2D Inhalte, Texte, Animationen und Interaktionsele- mente wiedergegeben werden, so wie sie zum Beispiel aus DVD-Menüs bekannt sind. Die MPEG 4 Datenströme kann das Toolkit entweder per On-demand Streaming über RTP/RTSP, als Progressive Download über HTTP oder ganz ein- fach lokal von der Festplatte entgegennehmen. Es kann dabei in eigenständigen Java Anwendungen als auch in Java Applets eingesetzt werden. Aufgrund des Si- cherheitsmodells für Java Applets muss der Javacode eines eigenen Applets sig- niert sein, um Streams über von RTP/RTSP oder von der Festplatte wiedergeben zu können. Der Herausgeber einer solchen Anwendung benötigt also ein gültiges Zertifikat einer Certificate Authority (CA). Das IBM Toolkit for MPEG-4 befindet sich momentan noch in der Entwicklung und kann über IBMs Forschungsbreich alphaWorks bezogen werden. Aufgrund des Entwicklungsstatus der Software gewährt IBM keinerlei Support oder Garantien für die Benutzung der Bibliothek. Zudem ist das Toolkit nicht kostenlos erhältlich. Eine Lizenz zur eigenen internen Nutzung beginnt bei US$ 500, eine uneingeschränkte Lizenz mit dem Recht zur öffentlichen Nutzung kostet US$ 7000 zuzüglich Umsatzsteuer.

-34- Webbrowserbasierte Lösungen zur Videoübertragung

2.2 Qualitätsvergleich der Videokompression

Ein wichtiges Merkmal der Videoübertragungslösungen ist die Effizienz der ein- gesetzten Videokompressionsverfahren. In diesem Kapitel wird daher die Enko- dingqualität der aktuellen Videocodecs der in Kapitel 2.1 beschriebenen Video- übertragungslösungen gegenübergestellt und verglichen: QuickTime H264, Re- alVideo 10, Windows Media Video 9 und Flashvideo VP6. Zusätzlichen wird der MPEG2 Videocodec mit in den Vergleich aufgenommen. MPEG2 wird zur Vi- deokompression bei Video-DVDs und bei der digitalen Fernsehübertragung ein- gesetzt. Außerdem ist MPEG2 der leistungsfähigste Codec, der vom Java Media Framework zur Videoübertragung mit Java unterstützt wird.

2.2.1 Testvoraussetzungen und Vergleichsmetriken

Für den Vergleich der Videocodecs wurde zunächst ein Testvideo erstellt. Als Ausgangsmaterial dafür dienten der HD-Trailer „BBC Motion Gallery: An- des“[Apple 2006], der HD-Trailer „Super Speedway“[Microsoft 2006e] sowie ei- ner vom Sachsen Fernsehen Chemnitz zur Verfügung gestellten Originalaufnah- me einer Moderationsszene. Aus diesen Filmen wurden zahlreiche unterschiedli- che Szenen entnommen und für das Testvideo neu zusammengestellt. Die Szenen variieren im Detailreichtum des Motivs, der Bewegungsart und der Bewegungs- geschwindigkeit. Sie stellen damit verschiedene Herausforderungen an die Vide- ocodecs, was somit einen umfangreichen Vergleich der Videoqualität ermöglicht.

Das Testvideo enthält 4948 Einzelbilder. Dies ergibt bei einer Bildrate von 25 Bil- dern pro Sekunde eine Spieldauer von rund 186 Sekunden. Die Auflösung des Videos beträgt 384x288 Pixel. Das entspricht der halben Bildhöhe und -breite der PAL-Auflösung. Die Datenrate des unkomprimierten Testvideos liegt damit bei 64800 kbps. Daraus ergibt sich eine Videodatei mit einer Größe von rund 1470 MiB.

Für den Vergleich der Kompressionsqualität der Videocodecs wird das Testvideo mit jedem Codec in den drei Datenraten 500 kbps, 200 kbps und 50 kbps enko- diert. Die resultierenden Videodateien werden anschließend mit dem Ausgangs- video als Referenz verglichen. Dabei kommen zwei verschiedenen Vergleichs- metriken zum Einsatz, das aus der Signalverarbeitung abgeleitete Signal-

-35- Webbrowserbasierte Lösungen zur Videoübertragung

Rauschverhältnis und der relativ neue Structual SIMilarity Index (SIMM). Das Signal-Rauschverhältnis, aus dem Englischen peak signal-to-noise ratio als PSNR abgekürzt, bezeichnet in der Signalverarbeitung das Verhältnis von Nutzsignal- leistung zur Rauschleistung. Die Einheit des PSNR ist das logarithmische Dezibel. Beim Qualitätsvergleich von Bildern wird für das PSNR der mittlere quadratische Fehler als Störgröße zu Grunde gelegt. Der Wertebereich des PSNR liegt zwi- schen 0 dB und ∞. Größere Werte bedeuten eine größere Ähnlichkeit zwischen dem Referenzbild und dem Testbild. ∞ steht für zwei identische Bilder. Typische Werte liegen etwa zwischen 30 dB und 40 dB. Das PSNR ist eine häufig benutze jedoch eher simple Metrik, denn sie ignoriert viele Aspekte des menschlichen vi- suellen Systems. Für den menschlichen Betrachter erscheinen verschiedenen Ar- ten von Bildfehlern unterschiedlich störend. Der 2004 von Zhou Wang entwickel- te Structual SIMilarity Index (SSIM) versucht diese Eigenschaften besser zu be- rücksichtigen. Die Bewertung der Ähnlichkeit zweier Bilder erfolgt bei dieser Metrik über eine strukturelle Bildanalyse [Wang 2004]. Die resultierenden Werte liegen im Bereich von 0 bis 1. Größere Werte bedeuten eine größere Ähnlichkeit zwischen Referenzbild und Testbild. Der Wert 1 steht für zwei identische Bilder.

Zur Berechung der beiden Metriken wird das Video Quality Studio von Visumal- chemia genutzt [Visumalchemia 2004]. Dieses arbeitet im YUV-Farbraum und be- rechnet das PSNR und den SSIM für jedes Bild im Testvideo und jeden Kanal se- parat. Da das menschliche Auge auf Helligkeitsabweichungen empfindlicher rea- giert als auf Farbfehler, wird der Helligkeitskanal Y bei der Berechung des PSNR und SSIM für das gesamte Bild stärker gewichtet, als die beiden Farbkanäle U und V. Der Ergebniswert für das gesamte Video wird durch Mittelung der Ein- zelergebnisse aller Bilder berechnet.

Als drittes Merkmal wird beim Qualitätsvergleich der Videocodecs betrachtet, wie genau die Encoder die Vorgabe der Zielbitrate eingehalten haben. Eine Un- terschreitung der Zielbitrate bedeutet letztendlich verschenkte Videoqualität. Ei- ne Überschreitung der Zielbitrate kann zu Problemen bei der Videoübertragung führen, wenn die zur Verfügung stehende Netzwerkbandbreite dann nicht mehr ausreicht. Dies ist vor allem bei schmalbandigen Interverbindungen wie ISDN wichtig.

-36- Webbrowserbasierte Lösungen zur Videoübertragung

2.2.2 Testergebnisse und Auswertung

Nachfolgend werden die Testergebnisse des Codecvergleichs betrachtet. Dabei werden zuerst auf die Ergebnisse der Enkodierung mit 500 kbps und konstanter Bitrate eingegangen. Danach folgen 200 kbps und 50 kbsp, auch jeweils als kon- stante Bitrate. Bei der Betrachtung der einzelnen Datenraten wird die jeweils er- reichte Bildqualität der Videocodecs anhand des Verlaufs des SSIM über das ge- samte Testvideo in einem Diagramm dargestellt und verglichen. Außerdem wer- den die Unterschiede in der Qualität der einzelnen Codecs anhand von drei aus- gewählten Einzelbildern aus dem Video direkt gegenüber gestellt. Diese, in Abbildung 12 dargestellten Vergleichsbilder repräsentieren Szenen aus dem Testvideo, die jeweils unterschiedliche Anforderungen an die Videocodecs stell- ten.

Abbildung 12: Ausgewählte Vergleichsszenen aus dem Testvideo

In der ersten Szene, im Bereich von Bild 2150 aus dem Testvideo, wird ein Was- serfall in Nahaufnahme dargestellt. Hauptmerkmale dieser Szene sind eine gleichmäßig schnelle aber in mehrere Richtungen wirkende chaotische Bewegung mit vielen Details in Form von spritzendem Wasser. Dabei hat das gesamte Motiv einen sehr ähnlichen Farbton. Bei zu starker Kompression können die Details hier schnell zu einer einheitlichen Fläche verwaschen. Die Szene um Bild 3253 zeigt einen schnellen Kameraschwenk der zwei fliegende Papageien verfolgt. Die far- benfrohen Vögel heben sich dabei stark von dem schnell vorbeiziehenden un- scharfen Hintergrund ab. Neben Farbauswaschungen an den Rändern der Vögel kann es hier vor allem durch die schnelle Bewegung zu einem starken Detailver- lust bei der Kompression kommen. Die dritte Szene von Bild 4200 ist eine typi- sche Moderationsszene. Sie enthält nur wenig Bewegung, einen stillstehenden, homogenen Hintergrund und den Moderator als Motiv. Dadurch sollte dieses Motiv auch bei niedrigen Bitraten eine gute Darstellungsqualität haben. Eine Be-

-37- Webbrowserbasierte Lösungen zur Videoübertragung

sonderheit in dieser Szene ist jedoch die Schrifteinblendung am unteren Bild- schirmrand. Hier liegt daher auch das Hauptaugenmerk, denn die Einblendung sollte stets lesbar sein. Überdies sollte das Gesicht des Moderators und dessen Mimik noch gut erkennbar sein.

Kompression mit 500 kbps und konstanter Bitrate

Abbildung 13 zeigt den Verlauf des SSIM für die vier Videocodecs QuickTime, RealVideo, Windows Media und Flash Video bei 500 kbps. Wie zu sehen ist, lie- gen die Codecs bei dieser Datenrate bezüglich der Bildqualität eng beieinander.

500 kbps CBR 1,00

0,95

0,90

0,85 SSIM

0,80 QuickTime RealVideo 0,75 Windows Media Flash Video 0,70 0 500 1000 1500 2000 2500 3000 3500 4000 4500 Bildnummer

Abbildung 13: Verlauf des SSIM über das Testvideo für die Codecs bei 500 kbps

QuickTime und RealVideo sind den beiden Konkurrenten in den meisten Szenen bei dieser Metrik geringfügig überlegen. Das erste Drittel des Testvideos, in dem hauptsächlich gleichmäßig ruhige Kamerafahrten gezeigt werden, stellt für kei- nen der Codecs ein besonderes Problem dar. Erst im mittleren Bereich, der ver- schiedene Szenen mit vielen schnellen Bewegungen und vielen Details zeigt, bricht die Bildqualität deutlich sichtbar ein. Besonders kritisch ist die Szene im Bereich von Bild 1590 bis 1790. Sie zeigt die Nahaufnahme einer Schar abheben- der Flamingos im Wasser. Hier kommen alle getesteten Codecs selbst bei 500 kbps an ihre Grenzen. Besonders kritisch ist die Szene für Flashvideo VP6. Der Codec muss hier einzelne Bilder überspringen, um die Datenrate einhalten zu

-38- Webbrowserbasierte Lösungen zur Videoübertragung

können. Dies schlägt sich natürlich in einem schlechten SSIM nieder, da das in diesem Moment dargestellte Bild nicht mit dem Originalbild übereinstimmt.

Ein ähnliches Problem hat Windows Media, hier jedoch an einer eher unkompli- zierten Stelle. Es hat die 24 Bilder lange Schwarzblende bei Bild 4030 und 4246 aus unbekannten Gründen verkürzt dargestellt. Das ist an dieser Stelle besonders störend da der Moderator so deutlich zu früh eingeblendet wird. Er würde somit kurze Zeit vor der normalerweise mitlaufenden Tonspur erscheinen.

Der MPEG2 Codec wurde aus Gründen der Übersichtlichkeit in einem separaten Diagram in Abbildung 14 dargestellt. Zum Vergleich wurde QuickTime in den Datenraten 500 kbps und 200 kbps gegenübergestellt. Bei den einfacheren Szenen kann MPEG 2 dabei noch relativ gut mit den moderneren Codes mithalten. Die Bildqualität liegt dabei ungefähr auf dem Niveau der 200 kbps Ergebnisse der anderen Codecs. Deutlich fällt jedoch auf, das MPEG bei 500 kbps kaum Reserven für komplexere Szenen hat. Der Encoder muss immer wieder Bilder auslassen, was sich in einem sehr schlechten SSIM für diese Szenen niederschlägt. Der Co- dec ist bei 500 kbps mit einigen Szenen des Testvideos bereits überfordert.

MPEG 2 vs. Quicktime 1

0,9

0,8 SSIM 0,7

QuickTime (500 kbps) 0,6 QuickTime (200 kbps) MPEG 2 (500 kbps)

0,5 1 501 1001 1501 2001 2501 3001 3501 4001 4501 Bildnummer

Abbildung 14: Verlauf des SSIM für MPEG2 bei 500 kbps verglichen mit Quicktime

In der nachfolgenden Abbildung 15 ist das Einzelbild 2150 aus den verschiedenen Enkodingergebnissen der einzelnen Videocodecs bei 500 kbps dem Original ge- genübergestellt.

-39- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 15: Vergleich von Bild 2150 aus dem Testvideo bei 500 kbps CBR

QuickTime und mehr noch RealVideo weisen eine starke Weichzeichnung des Bildes auf. Viele Details im Vordergrund sind dadurch verschwunden, der BBC- Schriftzug ist bei RealVideo nicht mehr lesbar. Zudem geben die beiden Codecs die Farben mit weniger Sättigung wieder. Die meisten Details dieser Szene wer- den von Flash und MPEG2 erhalten. Beide Codecs geben außerdem die Farben am getreusten wieder, wenn auch etwa verrauscht. Windows Media bildet so- wohl bei der Detailwiedergabe und Weichzeichnung als auch bei der Farbtreue einen Kompromiss zwischen QuickTime/RealVideo und Flash/MPEG2.

-40- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 16: Vergleich von Bild 3253 aus dem Testvideo bei 500 kbps CBR

Auch bei den in Abbildung 16 verglichenen Bildern liefern QuickTime und Real- video etwas blasse Farben. Ansonsten erhalten sie aber eine hohe Detailschärfe und einen gleichmäßigen Hintergrund. RealVideo neigt wie auch schon im vo- rangegangen Testbild stärker zu Verwaschungen als QuickTime. Dennoch liefern beide Codecs in dieser Szene ein sichtbar besseres Ergebnis als die beiden Konku- renten. Flash und Windows Media neigen zu einer leichten Blockbildung im Hin- tergrund und MPEG2 hat Probleme mit Farbauswaschungen beim rot der Papa- geien. Flash und MPEG zeigen auch hier wieder die beste Farbtreue.

-41- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 17: Vergleich von Bild 4200 aus dem Testvideo bei 500 kbps CBR

Beim in Abbildung 17 gegenübergestellten dritten Vergleichsbild hat, wie bereits erwartet, keiner der Codecs größere Probleme. Die Schrifteinblendung ist bei al- len lesbar, obgleich sie bei Windows Media etwas unscharf ist und bei MPEG2 starke Kompressionsartefakte an den Rändern aufzeigt. Bei QuickTime und Re- alVideo fallen besonders die matten Farben im Bereich der Hauttöne auf. Flash besticht hier wieder durch die natürlichsten Farben und zeichnet zudem die Schrift der Einblendung am schärfsten.

-42- Webbrowserbasierte Lösungen zur Videoübertragung

Kompression mit 200 kbps und konstanter Bitrate

200 kbps CBR 1,00

0,95

0,90

0,85 SSIM

0,80 QuickTime RealVideo 0,75 Windows Media Flash Video 0,70 0 500 1000 1500 2000 2500 3000 3500 4000 4500 Bildnummer

Abbildung 18: Verlauf des SSIM über das Testvideo für die Codecs bei 200 kbps

Das Diagramm in Abbildung 18 zeigt den Verlauf des SSIM für die mit 200 kbps enkodierten Videos. Die Ergebnisse sind denen bei 500 kbps ähnlich. Auch hier liegen die Codecs relativ dicht beieinander. Die Reserven bei den besonders an- spruchsvollen Szenen in der Mitte des Testvideos sind bei dieser Datenrate bei den meisten Codecs jedoch aufgebraucht. Neben Flash überspringt auch RealVi- deo bei der Flamingoszene Bilder. Der schlechte SSIM-Wert bei RealVideo ist an dieser Stelle im Diagramm wegen der hohen Informationsdichte jedoch nur schlecht zu erkennen. Am besten kommt Windows Media bei 200 kbps mit diesen Abschnitten zurecht. Jedoch tritt bei diesem Codec auch hier wieder das uner- klärliche Problem bei den Schwarzblenden auf. Die Moderationsszene beginnt zu früh und wird daher am Anfang von Windows Media Video um einige Bilder ge- streckt.

MEPG 2 ist mit dem Testvideo bei 200 kbps schon völlig überfordert und wird daher bei den weiteren Betrachtungen nicht mehr berücksichtig. Der Codec muss- te bei dieser Datenrate über das gesamte Testvideo zahlreiche Bilder auslassen, so dass das Ergebnis eher einer Diashow von einzelnen Ausschnitten glich.

-43- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 19: Vergleich von Bild 2150 aus dem Testvideo bei 200 kbps CBR

Das Ergebnis der Wasserfallszene in Abbildung 19 fällt bei 200 kbps ähnlich aus wie bei 500 kbps. QuickTime und besonders RealVideo neigen zu starken Verwa- schungen. Flashvideo zeigt die meisten Details, neigt dieses Mal jedoch zu einer leichten Blockbildung und einem stärkeren Farbrauschen. Der BBC Schriftzug ist bei Flash gerade noch erkennbar. Windows Media fällt hier mit örtlichen Farb- abweichungen ins Grünliche negativ auf.

-44- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 20: Vergleich von Bild 3253 aus dem Testvideo bei 200 kbps CBR

Bei der Papageienflugszene mit 200 kbps, in Abbildung 20 dargestellt, treten die Unterschiede deutlicher hervor. Besonders auffällig ist die deutlich erkennbare Blockbildung im Szenenhintergrund des Flashvideos. Andererseits weist Flash hier unter allen Testvideos die meisten Details im Bereich der Papageien auf. Ein- zelne Federn am Flügel sind noch gut zu unterscheiden, während bei allen ande- ren, insbesondere RealVideo, nur noch eine verwaschene Fläche zu sehen ist. Den besten Kompromiss aus gleichmäßigem Hintergrund und detaillierten Vorder- grund demonstriert QuickTime. RealVideo verwäscht das Bild sehr stark, beson-

-45- Webbrowserbasierte Lösungen zur Videoübertragung

ders die Farben der Papageien. Windows Media tendiert sowohl zu Verwaschun- gen als auch zur Blockbildung.

Abbildung 21: Vergleich von Bild 4200 aus dem Testvideo bei 200 kbps CBR

Die Moderatorszene komprimieren die vier Codecs auch bei 200 kbps noch sehr gut, wie in Abbildung 21 zu sehen ist. Die Schrift der Einblendung bleibt auch bei dieser Datenrate noch gut lesbar. Ein Unterschied zu den 500 kbps Videos ist kaum zu erkennen. Entsprechend ändert sich auch an der Bewertung der einzel- nen Bilder gegenüber den zuvor getroffenen Aussagen nichts.

-46- Webbrowserbasierte Lösungen zur Videoübertragung

Kompression mit 50 kbps und konstanter Bitrate

50 kbps CBR 1

0,9

0,8 SSIM 0,7

QuickTime 0,6 RealVideo Windows Media Flash Video 0,5 0 500 1000 1500 2000 2500 3000 3500 4000 4500 Bildnummer

Abbildung 22: Verlauf des SSIM über das Testvideo für die Codecs bei 50 kbps

Wie im Diagramm in Abbildung 22 zu erkennen ist, hat sich die Bildqualität der Testvideos bei 50 kbps deutlich verschlechtert. Bei den komplexeren Szenen ha- ben bis auf QuickTime alle Codecs mit Bildauslassungen zu kämpfen. Dabei muss man jedoch berücksichtigen, dass QuickTime es dafür mit der vorgegebe- nen Bitrate nicht allzu genau genommen hat. Um keine Bilder auslassen zu müs- sen, hat QuickTime die Zielbitrate um über 40% überschritten und stattdessen mit rund 70 kbps enkodiert. Eine Übertragung des Videos über ISDN ist damit nicht mehr ohne Unterbrechung der Wiedergabe möglich. Am besten kommt unter Einhaltung der niedrigen Datenrate RealVideo zurecht, das in einigen weniger anspruchsvollen Szenen die anderen Codecs übertrifft. Eine Enkodierung mit MPEG2 war bei dieser Datenrate nicht möglich.

-47- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 23: Vergleich von Bild 2150 aus dem Testvideo bei 50 kbps CBR

Das Originalbild ist beim Vergleich der Testbilder in Abbildung 23 nur noch be- dingt wiederzuerkennen. Alle Codecs verschleifen den Wasserfall zu einer mehr oder weniger wolkigen Darstellung. Welche der Darstellungen hier besser ausse- hen, kann fast nur noch subjektiv entschieden werden. Quicktime und RealVideo zeigen ein sehr detailarmes aber eher homogenes Bild, das vor allem auch in der Bewegung ruhiger erscheint. Flash erhält auch hier wieder die meisten Details, leidet aber unter stellenweise starken Farbverschiebungen, die sich in der Bewe- gung störend zeigen. Windows Media zeigt ein gleichermaßen unscharfes wie unruhiges, sehr aquarellartiges Bild.

-48- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 24: Vergleich von Bild 3253 aus dem Testvideo bei 50 kbps CBR

Bei der Papageienszene in Abbildung 24 überzeugt dieses Mal vor allem Win- dows Media. Der Kompromiss aus groben Hintergrund und verwaschenem Vor- dergrund geht hier auf. Die Blockartefakte, wenngleich vorhanden, sind nicht so stark ausgeprägt wie bei Flash. Überdies sind die Papageien nicht so stark verwa- schen wie bei QuickTime und RealVideo. Besonders letzteres produziert in dieser Sequenz eine aquarellartige Fläche, die in der Bewegung zu schwimmen scheint. Flash zerlegt das Bild bei dieser Bitrate in deutlich sichtbare und in der Bewegung sehr störende, grobe Blöcke.

-49- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 25: Vergleich von Bild 4200 aus dem Testvideo bei 50 kbps CBR

Mit der in Abbildung 25 verglichenen Moderationsszene kamen die Codecs bei 50 kbps sehr unterschiedlich zurecht. QuickTime schnitt hier am Schlechtesten ab. Sowohl das Gesicht des Moderators als auch die Einblendung sind völlig un- kenntlich. Bei Windows Media ist zumindest die Schrift noch lesbar. Das Gesicht des Moderators verwischt jedoch auch hier stark. Das mit Abstand beste Ergebnis liefert hier RealVideo. Sowohl das Gesicht als auch die Schrift sind klar erkenn- bar. Das Ergebnis unterscheidet sich kaum von den Ergebnissen bei 200 kbps und 500 kbps. Auch Flashvideo präsentiert in dieser Szene noch ein gutes Ergebnis. Die Schrifteinblendung ist zwar von Kompressionsartefakten gesäumt, bleibt aber

-50- Webbrowserbasierte Lösungen zur Videoübertragung

lesbar. Ebenso ist das Gesicht gut erkennbar. Der Hintergrund leidet jedoch unter einer deutlichen Blockbildung.

Zusammenfassung

Eine Aussage, welcher Codec die beste Kompressionsqualität erreicht, ist schwer zu treffen. Sicher ist, dass sich der MPEG2 Codec für Videoübertragungen über das Internet kaum eignet. Bei schnellen Bildbewegungen ist er selbst bei hohen Bitraten schnell überfordert und muss Bilder überspringen. Niedrigere Bitraten, etwa für schmalbandige Internetverbindungen wie ISDN, sind gar nicht möglich. Die anderen Videocodecs liegen relativ eng beieinander. Sowohl QuickTime, als auch RealVideo zeigen bei der Bildqualität eine eher stark weichgezeichnete Dar- stellung, besonders RealVideo verwischt das Bild dabei oft zu stark. Flashvideo hingegen schafft es meist viele Details wiederzugeben. Reicht die Datenrate dafür aber nicht aus, neigt der Codec schnell zur Blockbildung. Windows Media geht den Mittelweg aus Weichzeichnung und Blockartefakten. Leider ist es damit nicht immer erfolgreich, so dass sich beide Fehler zusammen manchmal noch störender auswirken. Eine deutliche Stärke des Flashvideos ist die Farbwiedergabe. In den Tests zeigt es die originalgetreusten Farben. Die anderen Codecs lassen die Far- ben mehr oder weniger stark unter einem Grauschleier verblassen. Insgesamt kann man sagen, dass die Videoqualität von QuickTime und RealVideo geringfü- gig besser ist als bei Windows Media und Flashvideo. Die in Abbildung 26 darge- stellten mittleren SSIM-Werte für das gesamte Testvideo bestätigen das. Die we- niger aussagekräftigen PSNR-Werte zeigen etwas größere Abstände. Anschei- nend bewertet diese Metrik weichgezeichneten Bilder von Realvideo und Quick- Time günstiger.

-51- Webbrowserbasierte Lösungen zur Videoübertragung

QuickTime Durchschnittlicher SSIM QuickTime Durchschnittlicher PSNR RealVideo RealVideo Windows Media Windows Media 1,0 Flash Video 45 Flash Video MPEG2 0,962 0,968 MPEG2 0,942 0,945 0,957 0,958 0,942 0,9 0,936 0,931 40 41,62 0,897 0,889 40,40 39,29 0,8 0,863 0,856 38,73 38,83 0,824 37,11 35 36,05 35,24 35,17 35,37 0,7 34,98 30 32,58 32,06 0,6 30,64 25 0,5 SSIM 0,4 20 PSNR (dB)PSNR 0,3 15 0,2 10 0,1 5 0,0 50 kbps, CBR 200 kbps, CBR 500 kbps, CBR 0

Abbildung 26: Durchschnittliches SSIM und PSNR der Testvideos

Bei den Datenraten ist zu sagen, dass 500 kbps bei einer Videogröße von 384x288 Pixeln und 25 Bildern pro Sekunde für die meisten Situationen ausreichend ist. Bei Szenen mit wenig Bildbewegung, wie Moderationen oder Interviews ist selbst mit 200 kbps eine gute Qualität erreichbar. Einzelne komplexere Szenen lassen sich außerdem durch die Verwendung von einer variablen Bitrate und einer En- kodierung in zwei Durchgängen ausgleichen. Das Diagramm in Abbildung 27 zeigt dies am Beispiel von Flashvideo bei einer Bitrate von 200 kbps.

200 kbps VBR und CBR 1,00

0,98

0,96

0,94

0,92

0,90 SSIM 0,88

0,86

0,84 Flashvideo 200 kbps CBR 0,82 Flashvideo 200 kbps VBR 0,80 1 501 1001 1501 2001 2501 3001 3501 4001 4501 Bildnummer

Abbildung 27: Verbesserung der Qualität in kritischen Szenen durch VBR-Encoding

Die mittlere Gesamtqualität des Videos ändert sich dabei nur minimal. Bei kriti- schen Szenen, wie der bereits zuvor erwähnten Flamingoszene zwischen Bild 1590 und Bild 1790, können diese damit enorm verbessert werden. Die dafür nö- tige Datenrate spart der Encoder dann an anderen, weniger komplexen Stellen

-52- Webbrowserbasierte Lösungen zur Videoübertragung

ein, so dass die mittlere Datenrate über das gesamte Video gleich bleibt. Wie gut die Umverteilung funktioniert hängt vor allem vom Encoder und der Qualität des Analysedurchlaufs ab. Der Nachteil dieser Methode ist die etwa doppelt so lange Dauer beim Enkodieren des Videos.

Die vorgegebene Zielbitrate haben die meisten Codecs während des Tests bis auf kleine, tolerierbare Abweichungen eingehalten. Tabelle 1 listet die Ergebnisse im Einzelnen auf. Wie zu sehen ist, hat Flashvideo bei der CBR Enkodierung etwas zurückhaltend gerechnet und meist rund 5 % Datenrate und damit auch Bildqua- lität verschenkt. Bei der VBR-Enkodierung weicht der Encoder dafür oft nach o- ben ab. Da Flash in beiden Fällen jedoch ein recht konstantes Verhalten zeigt, kann man diese Abweichungen leicht kompensieren, in dem man die Zielbitrate im CBR-Modus etwa 5% höher und im VBR-Modus etwa 6% bis 7% niedriger an- setzt.

CBR VBR 500 kbps 200 kbps 50 kbps 500 kbps 200 kbps 50 kbps QuickTime 505 kbps (+1%) 205 kbps (+2%) 71 kbps (+41%) 503 kbps (+1%) 204 kbps (+2%) 52 kbps (+3%) RealVideo 494 kbps (-1%) 199 kbps (0%) 51 kbps (+2%) 500 kbps (0%) 187 kbps (-7%) 53 kbps (+6%) Windows Media 493 kbps (-1%) 203 kbps (+2%) 56 kbps (+13%) 492 kbps (-2%) 196 kbps (-2%) 44 kbps (-11%) Flashvideo 473 kbps (-5%) 192 kbps (-4%) 53 kbps (-5%) 526 kbps (+5%) 221 kbps (+10%) 77 kbps (+55%) MPEG2 500 kbps (+0%) 253 kbps (+27%) --500 kbps (+0%) -

Tabelle 1: Über- bzw. Unterschreitung der Zielbitrate der Codecs beim Testvideo

Die anderen Codecs halten die Datenraten bei 500 kbps und 200 kbps etwas bes- ser ein. Am genausten Arbeitet RealVideo. MPEG2 trifft besonders bei 500 kbps sehr genau, sowohl bei konstanter, als auch bei variabler Datenrate. Bereits bei 200 kbps überschreitet der Codec, trotz der Auslassung vieler Bilder beim Enko- dieren die Zielbitrate erheblich um rund 27%. Niedrigere Bitraten waren mit MPEG2 auch nicht möglich.

Bei einer Zielbitrate von nur 50 kbps hatten aber auch die anderen Codecs teils erhebliche Probleme die Vorgabe einzuhalten, da sich hier natürlich schon gerin- ge Abweichungen prozentual stark auswirken. So überschreitet Flash die Zielbit- rate im VBR-Modus um 55 % bei 50 kbps. Ähnlich hoch überschreitet QuickTime bei 50 kbps CBR die Vorgabe, nämlich um 41%. Beides ist so hoch, dass das Video anschließend nicht mehr unterbrechungsfrei über Schmalbandverbindungen, wie

-53- Webbrowserbasierte Lösungen zur Videoübertragung

ISDN mit 64 kibit/s, übertragen werden kann. Aber auch Windows Media liegt mit Abweichungen von 13 % (CBR) und -11% (VBR) nicht unerheblich daneben. Am genauesten trifft auch bei 50 kbps RealVideo die Vorgabe.

Betrachtet man jedoch die Bildqualität, welche sich bei 50 kbps noch erreichen lässt, so ist festzustellen, dass der Einsatz von Videostreaming bei Schmalband- verbindungen ohnehin kaum sinnvoll erscheint. Dies gilt umso mehr, wenn man berücksichtigt, dass im Testvideo noch keine Audiospur enthalten war, welche noch zusätzlich Bandbreite benötigen würde.

2.3 Verbreitung der Videoformate

Um ein möglichst großes Publikum zu erreichen, ist es wichtig zu wissen welche Videoformate bei den Internetnutzern am weitesten verbreitet sind. Adobe hat hierzu 2006 eine Studie beim Marktforschungsunternehmen Millward Brown1 in Auftrag gegeben [Adobe 2006a]. Diese untersuchte die weltweite Marktdurchdri- nung der verschiedenen Browserplugins. Dazu wurden per Email freiwillige Teilnehmer aus zehn Ländern, darunter auch Deutschland, zur Teilnahme an der Untersuchung aufgefordert. Etwa jeder Fünfte der Befragten stammte aus den USA, weniger als ein Zehntel kam aus Deutschland. Bei der Umfrage wurden den Befragten die URL zur Testseite übermittelt, auf der nacheinander ein Bild jeweils in einem anderen Medienformat eingebettet angezeigt wurde. Die Befragten soll- ten darauf antworten, ob sie das Bild auf ihrem Computer sehen konnten oder nicht. Abbildung 28 zeigt das Ergebnis dieser Untersuchung. Demnach erreicht der Flash Player von Adobe eine Verbreitung von über 98% unter den Internet- nutzern. Danach folgt Java mit fast 87%. Der Mediaplayer von Microsoft erreicht eine Marktdurchdringung von knapp über 83% und ist damit am dritthäufigsten vertreten. Mit recht großem Abstand folgt an fünfter Stelle Apples QuickTime Player, der mit rund 67% bei gerade noch zwei Drittel aller Internetnutzer instal- liert ist. Noch weniger Verbreitung findet der RealPlayer von RealNetworks. Er ist mit etwas über 55% nur bei wenig mehr als der Hälfte aller Nutzer installiert.

1 http://www.millwardbrown.com/

-54- Webbrowserbasierte Lösungen zur Videoübertragung

Abbildung 28: Adobe-Studie zur Verbreitung der Browserplugins (Quelle: [Adobe 2006a])

Um zu überprüfen, ob diese Zahlen, auch auf deutsche Internetnutzer und insbe- sondere die Besucher von Internetseiten der Regionalen Fernsehsender Sachsens und Nordbayerns übertragbar sind, wurde im Rahmen dieser Diplomarbeit eine eigene Erhebung durchgeführt. Hierfür wurde eine Anwendung in den Script- sprachen JavaScript und PHP entwickelt, welche die beim Besucher einer Inter- netseite zur Verfügung stehenden Browserplugins automatische ermittelt. Diese Anwendung wurde für den Zeitraum von rund einem Monat auf den Internetsei- ten der Fernsehsender Dresden-Fernsehen, Franken-TV, Mittelsachsen-TV, Sach- sen-Fernsehen, TV-Aktuell, TV-Dessau, TV-Oberfranken und TV-Touring einge- setzt. Während dieser Periode wurden auf diesen Seiten insgesamt 40048 ver- schiedene Besucher gezählt. Durch setzten eines anonymen Cookies im Browser der Besucher, wurde verhindert, dass ein und derselbe Gast mehrfach erfasst wurde.

Die Ergebnisse der Erhebung sind in Abbildung 29 dargestellt und spiegeln im Wesentlichen die Ergebnisse aus der Untersuchung von Adobe wieder. So liegt das Flash-Plugin mit 95% Verbreitung auch unter den Besucher der Lokalfernseh- seiten ganz vorn. Mit 94% folgt der Media Player von Microsoft. Dieser hohe Wert dürfte vor allem auf den hohen Anteil der Microsoft Betriebsysteme zu- rückzuführen sein. Die verschiedenen Windows Versionen, welche alle stan-

-55- Webbrowserbasierte Lösungen zur Videoübertragung

dardmäßig mit dem Media Player ausgeliefert werden, waren mit insgesamt rund 96% die weitaus am häufigsten vertretenen Betriebsysteme.

Der Abstand des QuickTime Plugins zu den beiden meistverbreiteten Plugins ist unter den hier betrachteten Nutzern noch größer als in der Adobe-Studie. Mit 52% ist der QuickTime Player bei gerade einmal der Hälfte aller betrachteten Computer installiert. Dies könnte unter anderem auch an der geringen Präsents von Macintosh-Systemen liegen. Die Apple-Computer waren mit nur 2.1% selten vertreten. Die geringste Verbreitung aller Plugins hatte jedoch auch in dieser Er- hebung der RealPlayer. Obwohl RealNetworks seinen Player für alle wichtigen Betriebsysteme anbietet, ist er mit nur rund 44% bei nicht einmal der Hälfte aller Besucher installiert.

Abbildung 29: Verbreitung der Browserplugins unter den Besuchern der Webseiten der Lokal- fernsehsender

Eine Sonderrolle bei der Auswertung spielt die Java Virtual Machine für Java Applets. Für diese wurde in der Erhebung eine Verbreitung von über 96% festge- stellt. Leider kann diese Zahl keine Aussage über die tatsächliche Anzahl der in- stallierten JVM geben. Die Verbreitung der JVM kann mit automatischen Metho- den nur sehr schwer zuverlässig überprüft werden. Dies hat mehrer Gründe. Zum einen verwaltet Microsofts Internet Explorer 6 die zur Detektion von Java zuständige JavaScript-Methode window.document.javaEnabled() min- destens unter WindowsXP nicht korrekt. Der Browser meldet auch dann eine vor- handene und aktivierte Java-Unterstützung, wenn gar keine JVM installiert ist. Mitunter ist dieses Phänomen auch im Firefox Browser zu beobachten, wenn eine

-56- Webbrowserbasierte Lösungen zur Videoübertragung

bereits vorhandene JVM deinstalliert wurde. Damit ist die Detektion auf den am weitesten verbreiteten Betriebsystem-Browser-Kombinationen nicht zuverlässig möglich.

Zum anderen lieferte Microsoft bis 2003 den Internet Explorer mit einer eigen, veraltete JVM aus, welchen nicht den vollen Funktionsumfang von SUNs JVM unterstützte. Diese erlangte somit automatisch eine hohe Verbreitung. Nachdem Microsoft die Unterstützung für seine JVM´s auslaufen lies, wurden die veralte- ten Installationen jedoch nicht automatisch entfernt oder aktualisiert. So ist auch heute noch eine unbekannte Anzahl dieser JVM aktiv. Welche JVM tatsächlich auf einem System installiert ist, kann jedoch nur durch das Starten eines Java Applets im Browser dieses Systems festgestellt werden. Das kann jedoch zu Feh- lermeldungen führen, falls keine JVM installiert ist oder zu Unterbrechungen des der Seitenanzeige während des Ladevorgangs der JVM. Da dies den Betrieb einer im produktiven Einsatz befindlichen Webseite stark stören würde, konnte eine genaue Erhebung der Verbreitung der Java Applet Unterstützung bei den Besu- chern nicht durchgeführt werden. Zudem würde eine Erhebung auf einer separa- ten Internetseite mangels Besucherverkehrs keine aussagekräftigen Ergebnisse liefern. Außerdem stellt sich das Problem der korrekten Detektion der JVM vor dem Start des Plugins nicht nur für diese Erhebung, sondern auch im Falle einer aktiven Nutzung in einem Projekt.

Da die Verbreitung von Java nicht zuverlässig ermittelt werden konnte und in der Studie von Adobe nicht angegeben ist, welche Version der JVM erkannt wur- de, bleibt die Anzahl der vollwertigen JVM-Installationen unbekannt. Zusam- menfassend kann also gesagt werden, dass der Flash Player, wie in Abbildung 29 noch einmal dargestellt ist, die höchste gesicherte Verbreitung unter den betrach- teten Browserplugins hat. Er erreicht somit das größtmögliche Publikum. Nur knapp gefolgt vom Media Player von Microsoft. Apples QuickTime Player und RealNetworks RealPlayer erreichen hingegen jeweils nur etwa die Hälfte aller po- tentiellen Zuschauer. Des Weiteren darf davon ausgegangen werden, dass die Verbreitung des Flash Players in Zukunft zumindest unter den Internetvideo- affinen Nutzern noch weiter zunimmt, da die neuen großen Videoportale wie Google Video oder YouTube momentan ausschließlich auf diese Technik setzen.

-57- Anforderungen regionaler Fernsehsender

Kapitel 3

3 Anforderungen regionaler Fernsehsender

In diesem Kapitel werden die Anforderungen von regionalen Fernsehsendern an eine Lösung zur Übertragung ihres Fernsehprogramms über das Medium Inter- net ermittelt. Die Anforderungen wurden in erster Linie durch Interviews mit Vertretern der sächsischen Regionalfernsehsender KabelJournal1 und Sachsen- fernsehen Chemnitz2 ermittelt. Weiterhin wurden Anforderungen durch die Ana- lyse der aktuellen Internetauftritte beider Sender ermittelt, sowie durch die Beo- bachtung der Fernsehausstrahlung des Sachsenfernsehprogramms im Oktober 2006.

KabelJournal ist ein Regionalfernsehsender mit Sitz in Grünhain-Beierfeld. Der Sender wurde 1992 gegründet. Das Sendegebiet umfasst die Landkreise Aue- Schwarzenberg und Annaberg in Sachsen. Eine Studie der Sächsischen Landesan- stalt für privaten Rundfunk und neue Medien vom Mai 2006 hat für diese Region 74400 potentielle Zuschauer in 36500 Haushalten ermittelt [SLM 2006]. Kabel- Journal gehört damit zu den mittelgroßen regionalen Sendern in Sachsen. Der Anteil der täglich einschaltenden Zuschauer über 14 Jahre liegt bei 7,7 % (etwa 4700 Personen).

Sachsenfernsehen Chemnitz ist ebenfalls ein Regionalfernsehsender, dessen Sen- degebiet die Stadt Chemnitz und das Chemnitzer Land abdeckt. In der SLM- Studie wurden in dieser Region rund 276000 potentielle Zuschauer in rund 138000 Haushalten ermittelt. Damit hat Sachsenfernsehen Chemnitz die dritt- größte Reichweite unter den regionalen Fernsehsendern in Sachsen. Bezogen auf die tatsächliche Zuschauerzahl ist Sachsenfernsehen Chemnitz gar der größte sächsische Lokalfernsehsender. Die Studie gibt an, dass 21 % der potentiellen Zu- schauer täglich einschalten, das sind rund 52.000 der über 14-jährigen Zuschauer [SLM 2006]. Sachsenfernsehen Chemnitz ist außerdem Gründer des Gemein-

1 http://www.kabeljournal.de/ 2 http://www.sachsenfernsehen.de/

-58- Anforderungen regionaler Fernsehsender

schaftsprojekts kanal81. Unter diesem Namen haben sich derzeit 16 Regionalsen- der aus Ost- und Süddeutschland zu einer deutschlandweiten Nachrichten- und Informationsplattform zusammengeschlossen. Der Zuschauer erhält dabei eine zentrale Anlaufstelle für regionale und überregionale Informationen. Die einzel- nen Sender können so durch Kooperation eine stärkere Marktposition erreichen. Außerdem bietet der Verbund die Möglichkeit Filmmaterial untereinander aus- zutauschen und so das eigene Programm durch überregionale Neuigkeiten und Informationen zu erweitern.

3.1 Umfang des Videomaterials und Übertragungsanforderungen

Verglichen mit dem Vollprogramm landesweiter Fernsehsender entsteht bei regi- onalen Fernsehsendern wöchentlich wesentlich weniger neues Filmmaterial. Ka- belJournal gibt selbst an, etwa eine Stunde Bewegtbildmaterial pro Woche zu produzieren. Sachsenfernsehen erstellt nach eigenen Aussagen etwa vier Stunden Videomaterial pro Woche. Aufgrund dessen unterscheidet sich auch die Zusam- mensetzung des Filmmaterials stark von dem eines landesweiten Vollprogramm- senders. So produziert keiner der Sender Unterhaltungsserien oder gar Filme. Der größte Teil der Sendezeit wird für Lokalnachrichten oder Kurzberichte genutzt. Die einzelnen Beiträge haben dabei eine durchschnittliche Länge von etwa zwei bis fünf Minuten. Längere Reportagen sind deutlich seltener. Bei Sachsenfernse- hen betrifft dies die Sendung „Sonntagsgespräch“. Diese Talk-Sendung hat eine durchschnittliche Länge von rund 30 Minuten und wird jeden Sonntag ausge- strahlt. Andere Sondersendungen wie „Top of the Groove“ und „BVMW-TV“ er- scheinen nur alle zwei Wochen. Dabei handelt es sich bei Top of the Groove um eine 30-minütige Zusammenstellung von Beiträgen um das Thema Musik und bei BVMW-TV um eine etwa 10-minütige Talkshow.

Die Aktualität der übrigen Sendungen und des Programms im Allgemeinen vari- iert je nach Regionalsender. So produziert Sachsenfernsehen sein Hauptnachri- tenmagazin „Drehscheibe Chemnitz“ täglich neu. Innerhalb des Tages wird die

1 http://www.kanal8.de/

-59- Anforderungen regionaler Fernsehsender

Sendung einmal um 10 Uhr gesendet und dann ab 18 Uhr bis 1 Uhr nachts stünd- lich wiederholt. KabelJournal geht hier einen anderen Weg. Das Fernsehpro- gramm von KabelJournal ist wochenaktuell und besteht primär aus dem Nach- richtenmagazin „Rundblick“. Die Beiträge dazu werden einmal pro Woche pro- duziert und inklusive Moderation zu einem rund einstündigen Programm zu- sammengeschnitten. Diese Programmstunde wird dann, jeweils freitags begin- nend, eine Woche lang vier Mal pro Tag ausgestrahlt.

Live-Übertragungen finden bei Regionalsendern aufgrund des damit verbunde- nen technischen Aufwands fast nie statt. KabelJournal überträgt keine Sendungen Live. Sachsenfernsehen nutzt die Live-Übertragung nur sehr selten, etwa zu be- sonderen Anlässen wie Wahlen. Nach eigenen Angaben werden derartige Live- Sendungen höchstens einmal pro Jahr produziert.

Die wichtigsten Inhalte der Regionalen Fernsehsender sind demzufolge einzelne Lokalnachrichtenbeiträge von etwa zwei bis fünf Minuten Dauer. Die Beiträge werden je nach Sender wöchentlich bis höchstens täglich neu produziert und kommen auf eine Gesamtspieldauer von ein bis höchsten vier Stunden pro Wo- che inklusive Moderationen.

3.2 Werbeeinblendungen

Die Haupteinnahmequelle der Regionalfernsehsender ist Werbung. KabelJournal und Sachsenfernsehen gehen dabei unterschiedliche Wege. KabelJournal setzt bei Werbung stark auf Standbilder, welche für die Werbenden kostengünstig zu pro- duzieren sind. Sie werden als sogenannte Bildschirmzeitung nacheinander für ei- nige Sekunden eingeblendet. Die einzelnen Seiten dieser Bildschirmzeitung lie- gen in der Redaktion in gängigen Bildformaten wie JPEG oder Bitmap vor. Zu- sätzlich dazu wird die Sendung „Treffpunkt“ ausgestrahlt. Dabei handelt es sich um eine Dauerwerbesendung, in der in mehren Beiträgen Unternehmen, Einrich- tungen, Innovationen und Personen aus den jeweiligen Regionen vorgestellt werden.

Im Gegensatz dazu setzt Sachsenfernsehen häufiger auf kurze Werbefilme. Diese sind dabei nicht immer durch Kameraaufnahmen entstanden, sondern werden oft

-60- Anforderungen regionaler Fernsehsender

als Animationen im Computer erstellt. Hierzu hat der Sender ein spezielles Werkzeug entwickelt, welches im Baukastensystem kostengünstig mit auswähl- baren Standardelementen einen kurzen Animationsfilm erstellt. Das Ergebnis liegt dann im Adobe Flash Format vor und wird im Screen Capture1 Verfahren in ein fernsehkompatibles Videoformat gewandelt.

Sachsenfernsehen setzt zudem bereits stark auf Werbung im Internet. Die Web- seiten des Senders enthalten zahlreiche Werbebanner und Anzeigen in den ver- schiedensten Formaten, von reinen Textanzeigen, über einfache Bildbanner bis hin zu aufwendigen Flashanimationen. KabelJournal hingegen blendet derzeit auf seinen Internetseiten keine Werbung für fremde Unternehmen ein. Lediglich ein einzelnes Bildbanner wirbt für weiterführende Dienstleistungen des Sen- derunternehmens.

Für eine Übertragung des Fernsehprogramms im Internet ist es sinnvoll, wenn sich die bestehenden Werbeformen der Regionalsender auch hier leicht integrie- ren lassen. In erster Linie sind dies herkömmliche Werbefilme, die, wie die Hauptfilme im vom Player unterstützten Videoformat vorliegen. Darüber hinaus sollten sich aber ebenso die Einzelbilder einer Bildschirmzeitung direkt wieder- geben lassen, ohne diese erst aufwendig in ein Videofilmformat konvertieren zu müssen. Um den Unterhaltungswert solcher Standbildwerbung für den Nutzer zu steigern, sollte es möglich sein diese Bilder mit einer separaten Audiospur, zum Beispiel in Form eines Musikstreams, zu unterlegen. Des Weiteren erscheint es sinnvoll, neben diesen bisherigen Werbetechniken auch bestehende Internet- werbeformate in das Webfernsehen zu integrieren. Das System sollte daher auch moderne Flashanimationen als Werbespot wiedergeben können. Den Internet- werbetreibenden könnte so ein neues Werbeformat mit erhöhter Aufmerksamkeit durch den Zuschauer angeboten werden, ohne dass sie neue Techniken einsetzen müssen. Für die Sender könnte diese Werbeform eine zusätzliche Einnahmequel- le bedeuten, insbesondere dann, wenn auf der Webseite bisher auf herkömmliche Online-Werbung in Form von Bannern und Popups verzichtet wurde.

1 Beim Screen Capture Verfahren wird das Quellvideo auf dem Bildschirm wiedergegeben und Bild für Bild vom Com- puter intern von der Bildschirmanzeige kopiert. Das Verfahren ist sehr Rechenaufwändig und langsam.

-61- Anforderungen regionaler Fernsehsender

3.3 Anzeigen von zusätzlichen Informationen

Bereits jetzt erstellen sowohl KabelJournal als auch Sachsenfernsehen zu vielen ihrer Nachrichtenbeiträge auch kurze Onlineartikel auf ihren Webseiten. Die Ar- tikel enthalten einen kurzen Text zum entsprechenden Ereignis, meist ein oder mehrere Fotos und mitunter weiterführende Links zum Thema. Bei der Übertra- gung der Fernsehbeiträge im Internet wäre es daher sinnvoll, wenn solche zusätz- lichen Informationen und Begleittexte zusammen mit dem jeweiligen Beitrag an- gezeigt werden würden. Dies würde dem Zuschauer gegenüber dem herkömmli- chen Fernsehen einen echten Mehrwert bieten.

Darüber hinaus wäre eine solche zusätzliche Informationsanzeige auch im Zu- sammenhang mit den Werbeeinblendungen sinnvoll. Solche Zusatzinformatio- nen könnten neben dem eigentlichen Werbespot zum Beispiel Adress- und Kon- taktinformationen zum beworbenen Unternehmen, eine Anfahrtsskizze oder ein Link zur Unternehmenswebseite sein. Von diesen Zusatzangaben könnten somit sowohl der Werbende als auch der Zuschauer profitieren. Der so generierte Mehrwert wiederum würde sich durch steigende Werbeeinnahmen auch für die Regionalsender auszahlen.

Eine weitere Möglichkeit zusätzliche Informationen anzuzeigen, wäre deren Ein- blendung direkt im Bereich des Videobilds als Overlay. So könnten nachträglich Logos oder Texte in den Film eingeblendet werden, ohne diesen selbst bearbeiten zu müssen. Dies wäre vor allem für einen Senderverbund wie Kabel8 interessant. Die Sender könnten so die gleichen Filmbeiträge auf der jeweils eigenen Webseite mit dem eigenen Senderlogo anzeigen, ohne dass die Videodateien dazu mehr- fach vorliegen müssten. Das spart Ressourcen und vor allem Arbeitszeit bei der Erstellung des Filmmaterials.

3.4 Programmzusammenstellung, –steuerung, Nutzerinteraktion

Klassisches Fernsehen über Rundfunkantenne, Satellit oder Kabel ist ein rein pas- sives Medium. Der Nutzer ist lediglich Zuschauer und seine Interaktions- und Auswahlmöglichkeiten beschränken sich auf Ein-, Aus- oder Umschalten. Im Ge- gensatz dazu ist das Internet interaktiv. Die Nutzer sind es gewohnt, im Internet

-62- Anforderungen regionaler Fernsehsender

selbst auszuwählen, was sie wann wo anschauen und nutzen wollen. Eine Studie der ARD über das Onlineverhalten von Internetnutzern hat ergeben, dass die Verweildauer im Internet in den letzten Jahren abgenommen, die Nutzungshäu- figkeit jedoch zugenommen hat [ARD 2005]. Es erscheint daher wenig sinnvoll, das Programmangebot der regionalen Fernsehsender eins zu eins auf das Internet zu übertragen. Vielmehr soll der Nutzer aus einem Katalog der verfügbaren Nachrichten-, Reportagen- und Informationsbeiträge die für ihn interessanten auswählen können. Der Nutzer soll das Programm, das er ansehen möchte, so selbst gestalten und zusammenstellen. Dies könnte beispielsweise durch eine manuelle Auswahl aus einer Katalogliste erfolgen. Am flexibelsten und für den Nutzer komfortabelsten ist jedoch eine automatische Generierung eines Pro- gramms durch die Eingabe einiger Parameter, ähnlich wie bei einer Suchanfrage. So könnte der Nutzer sich etwa alle Nachrichten der vergangenen Woche zu ei- nem bestimmten Thema anzeigen lassen. Die Videolösung muss daher das Ab- spielen mehrerer einzelner Filme als zusammenhängendes Programm über eine Playliste unterstützen. In diese Playliste sollen dann auch automatisch Werbefil- me oder Werbebilder zwischen den einzelnen Beiträgen eingefügt werden.

Ein weiterer Unterschied zum herkömmlichen Fernsehen ist die mögliche Nut- zerinteraktion über das Zusammenstellen der Programmliste hinaus. Da die Vi- deos on-demand, also erst nach Anforderung durch den Nutzer übertragen wer- den, besteht für diesen auch die Möglichkeit die Wiedergabe der Filme zu steu- ern. Neben Pausieren und Fortsetzen der Wiedergabe kann dies auch das Vor- und Zurückspulen innerhalb eines Beitrags sein. Auch das Überspringen einzel- ner Filme wäre möglich und erhöht den Komfort für den Nutzer. Bei der Wieder- gabekontrolle muss jedoch ein Unterschied zwischen den inhaltlichen Beiträgen und den Werbeblöcken gemacht werden. So ist es nicht im Interesse der Werben- den und damit auch nicht des Senders, wenn der Nutzer die Werbefilme einfach überspringen kann. Das Videosystem muss demzufolge zwischen Werbung und inhaltlichen Beiträgen unterscheiden und die Wiedergabekontrollen während der Werbefilme deaktivieren können.

Als dritte Form der Nutzerinteraktion wäre eine Art interaktives Fernsehen mit Rückkanal im Internet vorstellbar. Der Nutzer könnte dann direkt auf Filmbeiträ-

-63- Anforderungen regionaler Fernsehsender

ge reagieren und diese zum Beispiel bewerten. Auch Formulareingaben, etwa für die sofortige Rückmeldung zu Gewinnspielen oder das Abonnement von Zu- satzdiensten wie Newslettern wäre denkbar.

3.5 Anforderungen an die Infrastruktur und Schnittstellen

Einer der wichtigsten Punkte für eine möglichst große Akzeptanz beim Nutzer ist, dass die Wiedergabesoftware einfach zu handhaben ist. Dazu zählt vor allem, dass der Anwender sie sofort benutzen kann, ohne erst zusätzliche Fremdsoft- ware herunterladen und installieren zu müssen. Die notwendige Laufzeitumge- bung für den Videoplayer sollte also bereits eine möglichst große Verbreitung haben, um ein möglichst großes Publikum anzusprechen. Nur so können auch Gelegenheitsnutzer von dem Angebot angesprochen und möglicherweise über- zeugt werden. Zudem ist zu bedenken, dass eine Installation von zusätzlicher Software bei einigen Nutzern gar nicht möglich ist, weil sie die nötigen Rechte nicht besitzen. Dies kann zum Beispiel bei Arbeitsplatzrechnern der Fall sein oder auch bei einem Besuch der Webseite vom Rechner eines Internet-Cafés aus, etwa im Urlaub, um sich über Neuigkeiten aus der Heimat zu informieren.

Von Seiten der Regionalsender steht für die Einrichtung einer aufwendigen Infra- struktur für das Videostreaming nur ein geringes Budget zur Verfügung. Keines der interviewten Unternehmen verfügt bisher über spezielle Streaming Server. Normale Webserver sind jedoch bei allen vorhanden, mindestens in Form von professionellen Hostingpaketen bei externen Hostingprovidern. So verfügt so- wohl KabelJournal als auch Sachsenfernsehen über eigene Webauftritte. Kabel- Journal bietet sogar selbst Hostingdienste für Dritte an. Zusätzliche spezielle Streaming Server bedeuten jedoch zusätzlichen Administrationsaufwands und in dem meisten Fällen auch hohe Lizenzkosten für die Sender. Angebote von exter- nen Streaming Server-Hostern verursachen, je nach Umfang, laufende Kosten von derzeit einigen hundert Euro pro Monat. Es wäre daher günstiger, wenn das Vi- deoangebot über die bereits existierende Infrastruktur der Regionalsender betrie- ben werden könnte. Die bevorzugte Methode der Videoübertragung sollte daher der progressive Download über einen normalen Webserver sein.

-64- Anforderungen regionaler Fernsehsender

Ein dritter wichtiger Punkt ist, dass sich das Videosystem leicht in die bestehen- den Redaktionsysteme und Webseiten der Sender integrieren lässt. Das heißt, das Videosystem sollte sich mit wenigen Zeilen HTML-Code an beliebiger Stelle in die Webseite einbinden lassen. Eine Änderung der vorhandenen Seitenstruktur ist nicht möglich. Außerdem sollte sich das System zudem optisch an das Design der jeweiligen Seite anpassen lassen.

Zur Übermittlung der Inhalte an die Abspielsoftware muss eine offene und fle- xible Schnittstelle vorgesehen werden. Diese muss so gestaltet sein, dass sie mit möglichst wenig Aufwand in die von den Sendern eingesetzten Webredaktions- systeme integriert werden kann.

-65- Prototypische Umsetzung einer Web-TV Anwendung

Kapitel 4

4 Prototypische Umsetzung einer Web-TV Anwendung

Im Rahmen der Diplomarbeit wurde ein Prototyp zur Übertragung des Fernseh- programms regionaler Fernsehsender im Internet entwickelt. Der Entwurf basier- te dabei auf dem in Kapitel 2 gewonnen Erkenntnissen über die möglichen Video- lösungen und berücksichtigt die in Kapitel 3 ermittelten Anforderungen der Fernsehsender. Die Überlegungen zu diesem System sowie dessen Umsetzung werden in diesem Abschnitt dargestellt.

4.1 Vorüberlegungen und Auswahl einer Technik

In Kapitel 2 wurden fünf Videolösungen verglichen, die für die Umsetzung der Web-TV Anwendung in Frage kommen. Am Anfang der Umsetzung stand daher die Auswahl einer dieser Lösungen als Entwicklungsbasis. Die Auswahlkriterien richteten sich dabei nach den in Kapitel 3 ermittelten Anforderungen der regiona- len Fernsehsender.

Einer der wichtigsten Punkte ist die Erreichbarkeit der Nutzer. Wenn diese zur Nutzung des Web-TVs erst zusätzliche Software Dritter installieren müssen, sind bereits zu Beginn Hürden aufgestellt, die die Akzeptanz der Anwendung verrin- gern würde. Daher ist es wichtig, dass die eingesetzte Videolösung schon bei ei- nem möglichst großen Anteil der potentiellen Nutzergruppe vorhanden ist. Wie die Untersuchung in Kapitel 2.3 gezeigt hat, ist dies besonders bei Quicktime und RealVideo ein Problem. Bei beiden Lösungen könnte nur rund jeder zweite ohne weiteren Aufwand die Anwendung direkt nutzen. Windows Media und Adobe Flash haben hier einen eindeutigen Vorteil. Beide Techniken stehen bei fast jedem Besucher der Webseite der Sender zur Verfügung. Bei Java war es leider nicht möglich die tatsächliche Verbreitung zu ermitteln.

Bei dem Kriterium der Bildqualität konnte sich keines der Systeme deutlich ab- setzen. QuickTime und RealVideo erreichten ein nur geringfügig besseres Ergeb- nis als Windows Media und Flash. Java hätte hier den Vorteil anführen können,

-66- Prototypische Umsetzung einer Web-TV Anwendung

mit MPEG2 direkt das bei digitalen TV-Produktionen übliche Videoformat zu un- terstützen. Jedoch hat sich dieses Format für die Übertragung im Internet als nicht brauchbar erwiesen. Die erreichten Kompressionsraten sind verglichen mit denen der anderen Videocodecs deutlich schlechter, so dass die zu übertragenden Datenmengen zu groß wären. Java ist daher für die Entwicklung der Web-TV Anwendung ungeeignet.

Bei den unterstützen Übertragungsarten gibt es zwischen den übrigen betrachte- ten Systemen nur wenige Unterschiede. Alle unterstützen die Übertragungsmodi progressive Download von einem beliebigen Webserver sowie On-demand Streaming und Live Streaming von einem Streaming-Server. Dabei benötigt jedes der Formate den jeweils zum System gehörigen Streaming-Server des eigenen Herstellers. In diesem Punkt unterscheiden sich die vier Systeme jedoch stark. So stellen sowohl Apple für QuickTime als auch Microsoft für Windows Media die benötigten Streaming Server kostenlos zur Verfügung. Diese setzen jedoch zum Betrieb das jeweils hauseigene Serverbetriebssystem in einer aktuellen Version voraus durch die nicht unerhebliche zusätzliche Kosten entstehen können. Bei Apple ist dies mindesten MacOS X Server 10.4 für QuickTime und bei Microsoft Windows Server 2003 für Windows Media. Zumindest bei QuickTime stellt dies für den praktischen Einsatz ein Problem dar, da das MacOS Serverbetriebsystem sehr exotisch ist und auch bei größeren Hosting-Providern meist nicht angeboten wird. Die Streaming Server von RealVideo und Adobe Flash laufen hingegen auf mehreren verschiedenen Serverbetriebsystemen, darunter auch einige kosten- günstige Linux-Varianten. Dafür sind die Streaming Server der beiden Anbieter selbst nicht kostenlos zu erhalten. Sowohl Adobe und besonders RealNetworks verlangen nicht unerhebliche Summen für diese Systeme.

Zwischen den Videolösungen gibt es recht deutliche Unterschiede Bezüglich der unterstützten Medienformate und der Flexibilität ihrer Einsatzmöglichkeiten. Zwar unterstützen alle neben der Wiedergabe von Videofilmen auch einige Standbildformate, die drei Systeme QuickTime, RealVideo und Windows Media beschränken sich hier jedoch auf die reine Anzeige im Abspielfenster. Die Anzei- ge zusätzlicher Informationen parallel zum Film ist nicht möglich. Auch die Kon- trolle über die Bedienelemente ist eingeschränkt. So bietet von den drei genann-

-67- Prototypische Umsetzung einer Web-TV Anwendung

ten Systemen lediglich Windows Media die Möglichkeit die Nutzerkontrolle bei einzelnen Filmen, zum Beispiel Werbung, zu deaktivieren. Des Weiteren ist die Oberfläche des jeweiligen Playerplugins bei keinem der drei Systeme optisch ver- änderbar. Adobe Flash stellt hier als vollwertiges Multimediaframework völligen Handlungsfreiraum für den Autor zur Verfügung. Neben Video und Standbil- dern unterstützt es nativ Animationen und Texte als Medium. Da Flash zudem keine feste Oberfläche für den Videoplayer vorgibt stehen auch hier alle Gestal- tungsmöglichkeiten offen ein beliebiges GUI zu erstellen und dieses flexibel an die jeweiligen Anforderungen anzupassen. Dabei können die unterstützten Me- dientypen beliebig miteinander kombiniert und angeordnet werden. Die Anzeige von passenden Text- und Bildinformationen zusätzlich zum eigentlichen Film ist damit kein Problem.

Ein besonderes Alleinstellungsmerkmal von Adobe Flash gegenüber den andern Systemen ist die Unterstützung beliebiger Nutzerinteraktionen. Durch die flash- eigene Programmiersprache ActionScript können in den Videoplayer und sogar in die Wiedergabemedien beliebige Nutzerinteraktionselemente integriert wer- den. Dies kann von einem einfachen klickbaren Objekt über ein komplexes For- mular bis hin zu einem interaktiven Spiel alles sein. Die übrigen Videolösungen bieten hier keine oder nur eingeschränkte Möglichkeiten, etwa in Form klickbarer Links.

Ein weiteres wichtiges Kriterium ist die Möglichkeit flexible Playlisten der wie- derzugebenden Medien zu erstellen und an den Player zu übergeben. QuickTime bietet hier die am wenigsten praktikable Lösung. Eine im Quelltext der Webseite festgelegte Abspielliste ist zu wenig flexibel und das Compositing im QuickTime- Moviecontainer erfordert den Einsatz spezieller Authoringsoftware. RealVideo und Windows Media hingegen unterstützen SMIL als Beschreibungssprache für Playlisten. Dieses einfache Textformat kann mit wenig Aufwand von einfachen Scripts beispielsweise auf einem Webserver erzeugt werden. Die Möglichkeiten verschiedene Medientypen in den Playlisten zu kombinieren und gegebenenfalls weitere Informationen hinzuzufügen ist dabei natürlich auf die Fähigkeiten des jeweiligen Players beschränkt. So können, wie oben bereits beschrieben, nur ein- geschränkt Interaktionselemente wie klickbare Links definiert werden. Auch bei

-68- Prototypische Umsetzung einer Web-TV Anwendung

den Medientypen selbst beschränken sich die Kombinationsmöglichkeiten im Wesentlichen auf die bloße Wiedergabereihenfolge. Windows Media ermöglicht es darüber hinaus die Kontrollelemente des Players für jeden Film einzeln an- o- der abzuschalten.

Adobe Flash gibt hingegen kein eigenes Playlistenformat vor. Flash unterstützt jedoch die Verarbeitung von XML-Daten mithilfe von Actionscript. Durch dieses strukturierte Textformat besteht auch größerer Handlungsfreiraum für die Um- setzung. Aufbau und Struktur der Playliste können genau den Anforderungen entsprechend angepasst werden. Beim Erzeugen einer Playliste im XML-Format gelten die gleichen Vorteile wie bei den SMIL-Playlisten von RealVideo und Windows Media. Dabei ist die Generierung von XML-Daten oft noch einfacher, da die meisten Programmiersprachen und viele Webanwendungen native Unter- stützung für dieses weit verbreitete Datenformat mitbringen.

Aufgrund all dieser Vorteile, der großen Flexibilität und der sehr hohen Verbrei- tung eignet sich Adobe Flash am besten zur Umsetzung einer Web-TV Anwen- dung, die die Anforderungen und Bedürfnisse Regionaler Fernsehsender erfüllt. Dieses hohe Maß an Flexibilität und Freiheit in den Gestaltungsmöglichkeiten hat jedoch auch den Nachteil, dass viele der Playerelemente, wie zum Beispiel die Steuerkontrollen oder die Auswertung der an den Player übergebenen Playliste innerhalb von Flash erst noch den Anforderungen entsprechend erstellt werden müssen. Dies bedeutet gegenüber den vorgefertigten Systemen einen höheren Entwicklungsaufwand. Um diesen Entwicklungsaufwand für zukünftige Systeme zu reduzieren und vor allem den Aufwand für spätere Veränderungen und Er- weiterungen des Prototyps gering zu halten, muss das System möglichst modular aufgebaut werden. Der Entwurf der Web-TV Anwendung mit Adobe Flash wird daher in den folgenden Kapiteln im Detail beschrieben.

4.2 Umsetzung des Players

In diesem Kapitel wird der Designentwurf des Web-TV Players und seine Umset- zung näher erläutert. Dabei werden der modulare Aufbau der zugrundeliegen- den Architektur, der Aufbau der Oberfläche und das Funktionsprinzip der XML- Playliste beschrieben.

-69- Prototypische Umsetzung einer Web-TV Anwendung

4.2.1 Modularität der Programmierung

Beim Entwurf des Prototyps war es besonders wichtig, dass das System modular aufgebaut wird. Dies erleichtert insbesondere die Überarbeitung und Erweite- rung der Anwendung an die sich ändernden Anforderungen eines wachsenden Unternehmens und des sich schnell ändernden Internets. Außerdem war es wich- tig, die Anwendung so zu gestalten, dass das Aussehen der Oberfläche leicht und möglichst uneingeschränkt änderbar ist, ohne dabei auf die Programmierung der Logik und Steuerung Einfluss nehmen zu müssen. Daher wurde bei Umsetzung auf eine konsequente Anwendung des Model-View-Controller Prinzips geachtet. Dazu wurden zunächst alle Optischen Elemente der Oberfläche in einem Flash- Dokument erstellt, angeordnet und mit Bezeichnern versehen. Im Prototyp ist dies die Datei player.fla im Quellcode-Ordner auf dem Begleitdatenträger zu dieser Arbeit. Diese Datei trennt alle visuellen Elemente sauber von der Pro- grammlogik ab und bildet somit die View-Schicht.

Die gesamte Steuerung, die Kontrolllogik und das Verhalten der einzelnen Ober- flächenelemente, wie zum Beispiel der Buttons, wurden separat in ActionScript 2.0 Klassen implementiert. Diese bilden also die Controller-Schicht. Dabei hat je- des GUI-Element seine eigene AS-Klasse. Auf diese Art ist es leicht möglich das Verhalten einzelner Elemente zu ändern ohne andere zu beeinflussen. Ebenso wurden die in Abschnitt 4.4 aufgeführten Wiedergabeelemente als separate AS- Klassen implementiert. Dies ermöglicht es vor allem für zukünftige Anforderun- gen mit wenig Aufwand weitere Wiedergabeelemente zu entwickeln und in die Anwendung zu integrieren. Besonders sinnvoll ist dies bei den Film-Objekten. Diese haben eine gemeinsame Basis-Klasse movie.as. Davon abgeleitet sind die drei im Prototyp unterstützen Medientypen Flash Video als progressive Downlo- ad, Standbildern und Flash-Animationen. Um später noch weitere Medientypen zu unterstützen genügt es eine weitere Ableitung dieser Basisklasse zu erstellen und die entsprechenden Modifikationen vorzunehmen, um die besonderen Merkmale des neuen Medientyps zu unterstützen. Die einzelnen AS-Klassen der Anwendungslogik werden in der Flash-Entwicklungsumgebung über die Biblio- thek mit den entsprechenden Oberflächenobjekten verknüpft, deren Verhalten sie implementieren. Zentrales Element der Anwendungslogik ist die Klasse main-

-70- Prototypische Umsetzung einer Web-TV Anwendung

Manager.as. Diese übernimmt die Zentrale Steuerung und die Kommunikation zwischen den übrigen Playerkomponenten. Sämtliche Aktionen werden über die- se Klasse ausgeführt. Daher haben alle aktiven Klassen, also solche die selbst Ak- tionen auslösen können, eine Referenz auf die mainManager-Klasse.

Die Modelschicht, also die Datenhaltung wird nicht von der Web-TV Anwen- dung implementiert. Sie ist Bestandteil des Redaktionssystems oder Videoarchivs des jeweiligen Regionalsenders und unterliegt nur dessen Kontrolle. Daher ist es umso wichtiger, dass die Model-Schicht sauber von der Logik des Players ge- trennt ist. Dies geschieht über eine separate Schnittstelle, der Playliste. Die Play- liste ist eine XML-Datei mit einer festgelegten Struktur. Sie übermittelt die Zugriffsadresse der wiederzugebenden Elemente sowie Metainformationen an den Web-TV Player. Weitere Details zur Playliste werden im Abschnitt 4.2.3 be- schrieben.

4.2.2 Die Oberfläche des Web-TV Players

Für die Standardoberfläche des Web-TV Players wurde ein modernes aber neut- rales und funktionales Design entwickelt. Dabei wurde vor allem dem Umstand Rechnung getragen, dass der Player neben dem eigentlichen Film auch Zusatzin- formationen zu diesem anzeigen können soll. Da der Player außerdem primär für die Wiedergabe ganzer Playlisten, bestehend aus mehreren Filmen, entwickelt wurde, wurde auch eine Möglichkeit zur Anzeige des Playlisteninhalts berück- sichtigt. Daher wurde für die Oberfläche des Web-TV Players das in Abbildung 30 dargestellte drei Fenster Design entwickelt. Zentrales Element ist dabei der von anderen Mediaplayern gewohnte Wiedergabeteil. Dieser besteht aus dem Bildschirm und den typischen Kontrollbuttons „Start/Pause“, einem Button zum Stummschalten und dem zugehörigen Regler zur Lautstärkeregulierung sowie einer Fortschrittsanzeige. Diese zeigt gleichzeitig den Ladefortschritt des aktuel- len Films sowie die aktuelle Wiedergabeposition an. Über den Slider an der Fort- schrittsanzeige kann außerdem stufenlos im Video vor und zurück gesprungen werden. Neu für einen browserbasierten Mediaplayer sind die beiden Button ne- ben dem Start/Pause-Knopf. Diese dienen dazu, in der Playliste ein Element vor oder zurück zu springen. Des Weiteren hat das Wiedergabefenster eine Informa- tionsanzeige, welche den Titel des aktuellen Films sowie die Zeit der aktuellen

-71- Prototypische Umsetzung einer Web-TV Anwendung

Abspielposition anzeigt. Diese Informationsanzeige ist nur dann sichtbar, wenn ein Film ausgewählt ist und abgespielt wird. Im oberen Player in Abbildung 30 ist dies nicht der Fall und daher auch keine Informationsanzeige zu sehen. Die Zeit- anzeige rechts neben der Informationsanzeige läuft rückwärts auf Null. Dies hat den Vorteil, dass man während der Wiedergabe jederzeit sieht, wie lang der Film von der aktuellen Position aus noch dauern wird.

Abbildung 30: Die Oberfläche des Web-TV Players mit geschlossenen Zusatzfenstern (oben) und vollständig geöffnet

Links und rechts neben dem Wiedergabeteil befinden sich die beiden zusätzli- chen Fenster zur Anzeige der Playliste (Links) und der Zusatzinformationen zum Video (rechts). Da der Web-TV Player mit diesen Fenstern in horizontaler Rich- tung viel Raum einnimmt, können beide über kleine Buttons am Fensterrand ge- schlossen und wieder geöffnet werden. Abbildung 30 zeigt den Web-TV Player sowohl mit geschlossenen (oben) als auch mit geöffneten Seitenfenstern (unten).

-72- Prototypische Umsetzung einer Web-TV Anwendung

Die im Infofenster angezeigten Zusatzinformationen können aus bis zu drei ver- schiedenen Elementen bestehen. Ganz oben wird der Titel der Zusatzinformatio- nen angezeigt. Darunter ein beliebig langer Text. Dieser kann mit HTML- Elementen und CSS formatiert werden. Mit dem HTML-Tag img können beliebig Bilder in den Textblock integriert werden. Der Text umfließt die Bilder dabei au- tomatisch. Als drittes Element können Links festgelegt werden, welche zusam- mengefasst als Linkliste unterhalb des Texts angezeigt werden. Diese sind in Abbildung 30 nicht dargestellt. Abbildung 32 auf Seite 89 zeigt ein anderes Bei- spiel von Zusatzinformationen in dem eine solche Linkliste enthalten ist. In den Abschnitten 4.4.6 bis 4.4.10 werden die einzelnen Elemente des Infofensters de- tailliert beschrieben.

Die Oberfläche des Web-TV Players ist durch das MVC-Prinzip und den Mög- lichkeiten von Flash leicht änderbar. Sie kann somit zum Beispiel leicht an die Corporate Identity eines Senders angepasst werden. Um Aussehen des Web-TV Players zu ändern, muss die Datei player.fla aus dem Quellcode-Ordner in Adobe Flash (Version 8 oder neuer) geöffnet werden. Hier können die einzelnen Elemente beliebig in Farbe und Form geändert und passend auf der Bühne (die Zeichnungsfläche) positioniert werden. Solche Elemente, die je nach Inhalt dy- namisch im Player angezeigt werden, wie etwa die Buttons der Playliste oder die Elemente der Zusatzinformationsanzeige, sind nicht auf der Bühne zu finden. Sie sind in der Bibliothek abgelegt und können dort zum Bearbeiten geöffnet werden. Alle Bibliothekselemente wurden thematisch zusammengehörig gruppiert und benannt, so dass sie leicht aufgefunden werden können.

4.2.3 Das Playlistsystem

Das Playlistensystem ist eine flexible Schnittstelle zur Übermittlung der Inhalte an den Web-TV Player. Die Playlisten selbst bauen dabei auf das offene XML- Format auf. Dieses strukturierte Textformat hat den Vorteil, dass es vom Men- schen direkt gelesen und geschrieben werden kann. Da es sich zudem im Internet bereits bei den meisten Anwendungen als das Datenaustauschformat der Wahl etabliert hat, ist auch die Unterstützung der der meisten Programmiersprachen für XML sehr gut. Dies eröffnet zwei grundlegende Möglichkeiten Playlisten für den Web-TV Player zu erstellen. Die einfachste ist, dass ein Redakteur selbst

-73- Prototypische Umsetzung einer Web-TV Anwendung

händisch eine Playliste aus den Filmen erstellt, die abgespielt werden sollen. Da- für reicht ein einfacher Texteditor, der jedem Betriebssystem beiliegt, aus. Die Playliste kann dann auf einem Webserver abgelegt und für den Player zugänglich gemacht werden. Die weitaus interessantere und mächtigere Variante ist jedoch die Playliste Mittels eines Scripts oder Programms automatisch zu erstellen. So könnte etwa ein bestehendes Redaktionssystem um einen XML-Export erweitert werden, der so die Playliste aus ausgewählten Elementen des Videoarchivs er- stellt. Auch hier genügt es anschließend die Playlisten auf einem Webserver für den Player zugänglich zu machen. Noch flexibler wird das System jedoch, wenn die Playliste dynamisch direkt mittels einer Serveranwendung direkt auf dem Webserver erstellt wird. Hier können bei der Generierung etwaige Eingaben des Nutzers berücksichtigt werden. Damit ist es möglich den Nutzer selbst das Pro- gramm bestimmen zu lassen. Er könnte zum Beispiel eine Suchanfrage an den Webserver schicken, der daraufhin die Datenbank eines Videoarchivs nach Tref- fern durchsucht und daraus automatisch eine individuelle Playliste generiert und an den Web-TV Player übermittelt.

Dabei gibt es grundsätzlich zwei Möglichkeiten eine Playliste an den Player zu übergeben. Bei der ersten wir der URL zur Playliste als Parameter beim Einbin- den des Players in die Webseite übergeben. Auf diese Art wird dem Player die initiale Playliste übermittelt und bestimmt, was der Player als erstes anzeigen soll. Weitere Details zum Einbinden des Players in eine Webseite und der Para- meterübergabe werden im Kapitel 4.3.2 beschrieben.

Bei der zweiten Möglichkeit wird die Playliste direkt aus dem Player heraus ge- laden. Dazu muss die Playliste einen Film oder ein Overlay vom Typ SWF enthal- ten. Dieses Flashfilmformat ermöglicht es durch Verwendung der Programmier- sprache ActionScript Nutzerinteraktionselemente in das Wiedergabemedium zu integrieren. Weitere Details zu diesen Medientypen werden in den Kapiteln 4.4.3 und 4.4.5 beschrieben. Der Web-TV Player wurde so entwickelt, dass Medien des Typs SWF Zugriff auf die zentrale mainManager-Klasse des Players erhalten. Sie können so den Player durch ActionScript mit den in der mainManager-Klasse zur Verfügung gestellten Methoden steuern. So kann durch den Aufruf der Methode mainManager.loadPlaylist(url) aus dem Player heraus eine neue Playliste

-74- Prototypische Umsetzung einer Web-TV Anwendung

geladen werden, ohne den Player selbst neu zu laden. Der Parameter url ist da- bei der String der URL zur neuen Playliste. Da der URL auch Parameter im GET- Format enthalten kann, können hier auch Variablen übergeben werden, auf deren Basis, wie oben beschrieben, eine dynamische Playliste von einem Serverscript generiert wird. Durch die vielfältigen Möglichkeiten des SWF-Medientyps erge- ben sich hier zahlreiche verschiedene Einsatzszenarien des Web-TV Players. So können beispielsweise Interaktive Filmereihen erstellt werden, bei denen der Zu- schauer durch Interaktion entscheidet wie es weiter gehen soll. Ebenso sind Ein- gabeformulare möglich, durch die der Nutzer seine Individuelle Playliste zu- sammenstellen kann. Aber auch Endlosfernsehen im Web ist so möglich, einfach indem sich am Ende jeder Playliste ein SWF-Film befindet der automatisch eine neue Playliste lädt. Das Playlistenssystem macht den Web-TV Player zusammen mit den vielfältigen Möglichkeiten der SWF-Medien zu einer flexibel einsetzbaren Multimediaanwendung für den Webbrowser.

Die Document Type Definition der XML-Playlistenformats ist in Listing 3 in An- hang C aufgeführt. Sie befindet sich außerdem zusammen mit einem umfangrei- chen Beispiel einer Playlisten-XML-Datei auf dem Begeleitdatenträger zu dieser Arbeit (siehe Anhang A).

4.3 Einsatz der Web-TV Anwendung in eine Webseite

In diesem Kapitel wird beschrieben, was nötig ist um die Web-TV Anwendung in eine Web-Seite zu integrieren und welche Möglichkeiten dabei bestehen, das Ver- halten der Anwendung den jeweiligen Anforderungen des Einsatzszenarios an- zupassen.

4.3.1 Konfigurationsmöglichkeiten

Der Web-TV Player bietet verschiedene Konfigurationsmöglichkeiten, die sein Verhalten und den Umgang mit den wiederzugebenden Inhalten beeinflussen. Diese Parameter können auf zwei unterschiedlichen Wegen geändert werden. Die Standardwerte der Parameter werden in der Quellcodedatei settings.as fest- gelegt. Damit die Änderungen an dieser Stelle wirksam werden, muss der Web- TV Player in der Flash Entwicklungsumgebung neu exportiert werden. Wenn da-

-75- Prototypische Umsetzung einer Web-TV Anwendung

bei der Parameter readSettingsFromHTML mit dem Wert true belegt wurde, können die Standardwerte aller weiteren Konfigurationsparameter durch Über- geben gleichnamiger Variablen beim Einbinden des Players in eine Webseite ü- berschrieben werden. Wie dies funktioniert wird im nachfolgenden Kapitel be- schrieben. Die Parameterübergabe beim Einbinden in die Webseite hat den Vor- teil, dass damit das Verhalten des Web-TV Players individuell an das jeweilige Einsatzszenario angepasst werden kann. Allerdings muss bei dieser Übergabeme- thode beachtet werden, dass die Parameter vom Nutzer im HTML-Quellcode durch spezielle Tools, wie zum Beispiel Firebug1, verändert werden könnten. Er könnte damit die vorgegebenen Einstellungen mit etwas Aufwand umgehen und die Einstellungsparameter nach eigenem Ermessen verändern. Daher lässt sich die Konfigurationsparameterübergabe mit dem Wert false bei dem Konfigura- tionsparameter readSettingsFromHTML deaktiviern. In diesem Modus gelten dann in jedem Fall die fest einkompilierten Standardeinstellungen aus der Datei settings.as. Es ist auch möglich für jedes Einsatzszenario eine separate Versi- on des Web-TV Players mit den passenden Standardeinstellungen zu exportieren.

Nachfolgend sind die möglichen Parameter aufgelistet und ihre Funktion kurz beschrieben.

Parameter: Mögliche Werte: readSettingsFromHTML true, false

Funktion: Der Parameter legt fest, ob die anderen Standardparameter durch gleichnamige Variablen beim Einbetten des Players in eine Webseite überschrieben werden dü- rfen (true) oder nicht (false).

Parameter: Mögliche Werte: controlAdverts true, false

1 Firebug ist ein kostenloses Debuging Addonhttp://www.getfirebug.com/

-76- Prototypische Umsetzung einer Web-TV Anwendung

Funktion: Mit diesem Parameter wird festgelegt, ob die Playerkontrollen bei als Werbung markierten Playlisteneinträgen für den Anwender nutzbar bleiben (true) oder nicht (false). Damit kann der Player so eingestellt werden, dass Werbeblöcke nicht übersprungen oder verkürzt werden können. Der Regler für die Lautstärke bleibt von dieser Einstellung unbeeinflusst und ist immer bedienbar. Zu beachten ist, dass in einer im Player geladenen Playliste für jeden Eintrag individuell der Parameter disablecontrols festgelegt werden kann. Dieser bestimmt eben- falls ob die Bedienelemente des Players bei dem Film, bei dem er gesetzt wurde, an oder abgeschaltet werden sollen. Er hat dabei aber in jedem Fall eine höhere Priorität, als der globale Parameter controlAdverts. Weitere Details zu disablecontrols und zum Markieren eines Films als Werbespot sind in den Kapiteln 4.4.2 und 4.4.3 beschrieben.

Parameter: Mögliche Werte: advertiseBevorFilm true, false

Funktion: Wenn dieser Parameter auf true gesetzt ist und der Anwender im Playlisten- fenster einen Film direkt auswählt, zeigt der Web-TV Player zunächst einen als Werbung markierten Film aus der Playliste an, bevor der vom Nutzer ausgewähl- te Film abgespielt wird. Wählt der Nutzer keinen Film direkt über das Playlisten- fenster, so hat der Parameter keine Auswirkung. Die Filme und Werbeblöcke werden dann in der Reihenfolge abgespielt, wie sie in der Playliste festgelegt wurden. Die Wirkung dieses Parameters kann durch die weiteren Parameter randomAdvertBevorFilm und AdvertBevorFilmProbability zusätzlich beeinflusst werden.

Parameter: Mögliche Werte: randomAdvertBevorFilm true, false

Funktion: Dieser Parameter hat nur eine Auswirkung, wenn advertiseBevorFilm auf true gesetzt ist. In diesem Fall legt randomAdvertBevorFilm fest, ob vor dem

-77- Prototypische Umsetzung einer Web-TV Anwendung

Film ein beliebiger Werbeblock aus der gesamten Playliste abgespielt werden soll (true) oder der Werbeblock, der sich in der Playliste direkt vor dem Film befin- det (false). So kann entweder die Dynamik der Werbeeinblendungen durch den Zufallsfaktor erhöht werden oder aber ein thematisch mit dem Film verbunder Werbeblocke zusammen mit diesem wiedergegeben werden.

Parameter: Mögliche Werte: AdvertBevorFilmProbability 0 .. 1

Funktion: Dieser Parameter hat nur eine Auswirkung, wenn advertiseBevorFilm auf true gesetzt ist. In diesem Fall kann mit AdvertBevorFilmProbability die Wahrscheinlichkeit bestimmt werden, mit der bei Direktauswahl eines Films im Playlistenfenster ein Werbeblock vorgeschaltet wird. Ein Wert von 1 bedeutet, dass immer ein Werbeblock vorgeschaltet wird. Bei 0 wird nie Werbung vorge- schaltet.

Parameter: Mögliche Werte: showAdvertisementsInPlaylist true, false

Funktion: Dieser Parameter legt fest, ob als Werbung markierte Filme als Einträge im Play- listenfenster des Web-TV Players erscheinen sollen (true) oder nicht (false). Der Parameter ist vor allem im Zusammenhang mit den Parametern advertiseBevorFilm und randomAdvertBevorFilm wichtig. Wenn der Nutzer im Playlistenfenster direkt einen Film zum Betrachten auswählt, und der Web-TV Player aufgrund dieser beiden Einstellungen einen Werbeblock vor- schaltet, so würde die Auswahlmarkierung im Playlistenfenster an eine andere Stelle springen als der Nutzer geklickt hat. Dieses Verhalten kann für den Nutzer verwirrend wirken oder sogar als Fehler in der Anwendung wahrgenommen werden. Daher ist es sinnvoll, Werbefilme in diesem Fall nicht im Playlisten- fenster anzeigen zu lassen.

-78- Prototypische Umsetzung einer Web-TV Anwendung

Parameter: Mögliche Werte: autoplay true, false

Funktion: Dieser Parameter legt fest, ob der Web-TV Player nach dem Laden einer Playliste sofort mit der Wiedergabe des ersten Eintrags beginnen soll (true) oder nicht (false).

Parameter: Mögliche Werte: preloadCount 0 .. ∞

Funktion: Mit dem Parameter preloadCount kann bestimmt werden, wie viele Filme im Hintergrund voraus geladen werden sollen. Ein hoher Wert erhöht den Komfort für den Nutzer, weil nachfolgende Filme so gegebenenfalls schon komplett gela- den wurden. Für den Dienstanbieter bedeutet das Vorausladen vieler Filme unter Umständen jedoch zusätzlichen Netzwerkverkehr, weil der Nutzer vielleicht gar nicht alle Filme anschaut, die übertragen wurden.

Parameter: Mögliche Werte: openInfoWindow true, false

Funktion: Dieser Parameter legt fest, ob das Informationsanzeigefenster des Web-TV Play- ers geöffnet (true) oder geschlossen (false) sein soll, wenn der Player gestartet wird.

Parameter: Mögliche Werte: openPlaylistWindow true, false

Funktion: Dieser Parameter legt fest, ob das Playlistenfenster des Web-TV Players geöffnet (true) oder geschlossen (false) sein soll, wenn der Player gestartet wird.

-79- Prototypische Umsetzung einer Web-TV Anwendung

4.3.2 Integration des Players in eine Webseite

Um den Web-TV Player einzusetzen, muss die swf-Datei des aus Flash exportie- ren Players auf einem Webserver abgelegt werden. Des Weiteren wird eine HTML-Datei benötigt, in die der Web-TV Player eingebettet werden soll. Das Einbetten kann nun über die bekannten HTML-Tags Object (für Internet Explo- rer) und Embed (alle anderen aktuellen Browser) geschehen. Flash erzeugt beim Export der Anwendung den benötigten Code automatisch. Das Problem dabei ist jedoch, dass bei dieser einfachen Variante, nicht erkannt wird, ob der Nutzer ü- berhaupt einen passenden Flashplayer installiert hat. Ist dem nicht so, erscheint statt des Web-TV Players ein vom verwendeten Browser abhängiger Platzhalter in der Webseite. Dies macht auf einer professionellen Seite einen schlechten Ein- druck und hilft vor allem auch dem Nutzer nicht viel. Der Web-TV Player sollte daher über eine vorgeschaltete Flashdetection in die Webseite eingebunden wer- de. Hierzu hat sich inzwischen die freie JavaScript-Bibliothek SWFObject etabliert [Geoff Stearns 2006]. Über diese kann der Web-TV Player komfortabel mit weni- gen Zeilen Code an beliebiger Stelle in die Webseite integriert werden. Nutzer ohne passenden Flashplayer bekommen so eine vom Webentwickler festlegbare Fallbacklösung angezeigt. In Listing 1 ist der HTML- und JS-Code dargestellt, der benötigt wird um den Web-TV Player mittels SWFObject in eine Webseite zu in- tegrieren.

Listing 1: HTML und JS-Code zur Integration des Web-TV Players in eine Webseite

1.

2. Sie benötigen eine aktuelle Flashversion 3. 4.

5. 6.

Dabei wird zunächst ein beliebiger DIV-Container angelegt (Zeile 1 bis 4). Dieser enthält den HTML-Code, der als Fallbacklösung angezeigt werden soll, falls der Nutzer keinen passenden Flashplayer installiert hat. Im Beispiel enthält der Fall- backblock weiteren Code, der angezeigt wird, wenn der Nutzer kein JavaScript

-80- Prototypische Umsetzung einer Web-TV Anwendung

aktiviert hat (Zeile 3), denn dieses ist Voraussetzung für SWFObject. Der Inhalt dieses DIV-Containers wird, falls beim Nutzer ein passender Flashplayer gefun- den wurde, durch den Einbettungscode des Web-TV Players ersetzt. Der DIV- Container benötigt daher eine ID (Zeile 1), über die er von JavaScript aus adres- siert werden kann.

In den Zeilen 6 bis 11 in Listing 1 befindet sich nun das eigentliche Einbettungs- script. Dabei wird zunächst eine neue Instanz von SWFObject erzeugt. Dabei ist der erste Parameter dieses Aufrufs der wichtigste. Er enthält den relativen oder absoluten Pfad zur swf-Datei des Web-TV Players. Der zweite Parameter legt die frei wählbare ID des Flashfilms fest. Die nachfolgenden Parameter geben die Brei- te, Höhe, die erforderlich Flashversion, die Hintergrundfarbe und die Wiederga- bequalität an.

Der so erzeugten SWFObject-Instanz können nun Parameter für die Einbettung angehängt werden. Hier sollte unbedingt der wmode Parameter mit dem Wert transparent belegt werden (Zeile 8). Dies sorgt dafür, dass der Hintergrund der Box, welche den Web-TV Player umgibt transparent erscheint und so eventu- ell darunterliegende Teile der Webseite durchscheinen lässt. Außerdem, bewirkt dieser, dass der Web-TV Player in einem HTML-Layer an beliebige Stelle in der Seite positioniert werden kann.

Zusätzlich zu den Einbettungsparametern können der SWFObject-Instanz nun noch Variablen zugewiesen werden, die an den Flashfilm, also den Web-TV Play- er übergeben werden sollen. An dieser Stelle muss eine initiale Playliste festgelegt werden (Zeile 9). Auf dieselbe Art und Weise können auch die in Kapitel 4.3.1 be- schriebenen Konfigurationsparameter an den Player übergeben werden.

Zum Schluss wird durch den Aufruf der Methode write() die Detektion des er- forderlichen Flashplayers gestartet und der Web-TV Player in die Seite eingebet- tet. Als Parameter muss dabei die zuvor in Zeile 1 festgelegte ID des Ziel-DIV- Containers übergeben werden.

-81- Prototypische Umsetzung einer Web-TV Anwendung

4.3.3 Bereitstellen von Inhalten

Da die vom Web-TV Player unterstützen Medien (siehe Kapitel 4.4) in der Play- liste sowohl über relative als auch absolute Pfade referenziert werden können, können sie auf dem gleichen Webserver wie auch der Web-TV Player abgelegt werden. Je nach Umfang der zur Verfügung stehenden Mediadateien kann es sinnvoll sein, hierfür einen separaten Webserver vorzuhalten. Dieser benötigt in erster Linie viel Festplattenspeicher und eine breitbandige Anbindung ans Inter- net, da besonders die Videostreams je nach Qualität und gleichzeitiger Nutzer- zahl viel Bandbreite benötigen. Dafür erfordert dieser separate Webserver relativ wenig Prozessorleistung, da er keine Serverscripte oder andere rechenintensiven Webanwendungen verarbeiten muss. Beim Bereitstellen der Mediadaten auf ei- nem separaten Server unter einer eigenen Domain muss jedoch das Sicherheits- modell des Adobe Flashplayers beachtet werden. Dieses schränkt jede Flashan- wendung so ein, dass sie nur Daten von der Domain nachlädt, von der sie selbst geladen wurde. Dies verhindert, dass fremde Flashanwendungen einfach Daten von fremden Servern laden und nutzen können. Damit der Web-TV Player den- noch Filme von einer fremden Domain laden kann, muss diese fremde Domain dem Player den Zugriff auf die Daten explizit gestatten. Dies geschieht indem im web-root Verzeichnis des Webservers, auf dem die zu ladenden Mediadateien liegen eine Datei mit dem Namen crossdomain.xml abgelegt wird. In dieser Datei wird festgelegt, von welchen Domains aus Flash auf diese Dateien zugrei- fen darf. Listing 2 zeigt, wie der Inhalt einer solchen crossdomain.xml-Datei aus- sieht. Im Beispiel wurde der Zugriff für die Domains example.com und www.example.com gewährt. Ausführliche Informationen zur domainübergeifen- den Kommunikation mit Flash sind in der Onlinedokumentation von Adobe zu finden [Adobe 2006g]

Listing 2: crossdomain.xml mit Freigabe für example.com

1. 2. 3. 4. 5. 6.

-82- Prototypische Umsetzung einer Web-TV Anwendung

Bei der Berechtigungszuweisung über eine crossdomain.xml ist zu beachten, dass diese nur die Zugriffe von Flashanwendungen reglementiert, da nur diese die Datei auswerten und respektieren. Ein direkter Zugriff, etwa durch Eingabe der URL in der Adressleiste des Browsers, wird damit nicht verhindert.

4.4 Unterstütze Wiedergabeelemente und ihre Funktionen

Der Web-TV Player unterstützt mehrere verschiedene Medientypen und Wieder- gabeelemente. In einer Playlistendatei im XML-Format können mehrere solche Elemente festgelegt und so zu einem Programm zusammengestellt werden. In diesem Kapitel werden alle zur Verfügung stehenden Wiedergabeelemente be- schrieben. Dabei wird die Funktion des Elements erläutert, die jeweilige Notation in der Playlistendatei gezeigt und alle möglichen Parameter und Optionen er- klärt. Nicht alle Playlistenelemente repräsentieren unmittelbar ein Wiedergabeob- jekt im Player. Einige dienen nur der inhaltlichen Strukturierung oder beeinflus- sen das Verhalten anderer Elemente. Ein ausführliches Beispiel einer XML- Playliste für den Web-TV Player sowie die vollständige Document Type Definiti- on befinden sich auf dem Begeleitdatenträger zu dieser Arbeit. Die DTD ist au- ßerdem in Listing 3 in Anhang C einsehbar.

4.4.1 Die Playliste

XML-Notation:

Parameter: keine

Beschreibung: Das Playlist-Element ist das Wurzelelement der Playlisten-XML-Notation. Es markiert Beginn und Ende der Playliste und enthält alle Einträge der Playliste als Kindknoten. Es hat selbst keine direkte Funktion. Das Playlist-Element ist in jeder Playlistendatei zwingend erforderlich.

-83- Prototypische Umsetzung einer Web-TV Anwendung

4.4.2 Playlisteneinträge

XML-Notation:

Parameter: navtitle : Bezeichnung des Playlisteneintrags in der Playlistenansicht disablecontrols : Explizites An- oder Abschalten der Bedienelemente

Beschreibung: Mit dem Item-Element wird ein einzelner Playlisteneintrag definiert. Alle Kind- elemente dieses Elements bilden zusammen diesen Playlisteneintrag. Das Item- Element selbst dient nur der logischen Strukturierung der Playliste. Die Reihen- folge der Item-Elemente in der XML-Notation legt auch die Reihenfolge der Play- listeneinträge im Web-TV Player fest. Über den Parameter navtitle wird die Bezeichnung des Playlisteneintrags im Playlistenfenster des Players festgelegt. Der Parameter ist zwingend erforderlich. Der optionale Parameter disablecontrols bestimmt explizit, ob die Kontrollelemente des Web-TV Players während der Wiedergabe dieses Elements für den Nutzer freigegeben oder blockiert sind. Mögliche Werte für diesen Parameter sind true (Kontroll- elemente an) und false (Kontrollelemente aus). Wenn dieser Parameter benutzt wird, werden damit etwaige Voreinstellungen zur Playersteuerung, die über die Konfigurationsoptionen des Players gesetzt wurden, überschrieben. Der Parame- ter hat immer Vorrang.

4.4.3 Videos, Bilder und Animationen als Filme

XML-Notation:

Parameter: type : Typ des Films (Werte: flv, image oder swf) src : Quelladresse des Films linkurl : Zieladresse beim Klick auf den Film durch den Nutzer content : Art des Films (Wert: advertisement) duration : Spieldauer des Films in Sekunden (nur bei type="image")

-84- Prototypische Umsetzung einer Web-TV Anwendung

Beschreibung: Das Movie-Element ist zentraler Bestandteil jedes Playlisteneintrags, denn es rep- räsentiert den eigentlichen Film, der in diesem Eintrag wiedergegeben werden soll. Das Element ist daher ein obligatorisches Kindelement des Item-Elements. Der Web-TV Player unterstützt drei verschiednen Medienformate zur Wiederga- be als Film. Das Medienformat des jeweiligen Films wird über den type- Parameter des Movie-Elements festgelegt. Die drei Werte flv, image oder swf stehen zu Auswahl. Dabei bezeichnet flv einen im Flashvideoformat enkodier- ten Film, image eine einzelne Bilddatei im JPEG, GIF oder PNG-Format und swf ein Adobe Flash-Animationsfilm. Die Quelladresse der jeweiligen Mediendatei wird im src-Attribut festgelegt. Diese beiden Parameter sind daher zwingend er- forderliche Angaben bei jedem Movie-Element.

Die weiteren Parameter linkurl, content und duration sind optional. Durch die Angabe des Parameters linkurl wird der Film bei der Wiedergabe anklick- bar. Klickt der Nutzer auf dann auf den Film, wird der im Parameter angegebene URL in einem neuen Browserfenster geöffnet. Der Parameter content legt die Art des Inhalts des Videos fest. In der Prototypversion unterstützt dieser Parame- ter nur den Wert advertisement. Damit wird der Inhalt des Films als Werbe- spot gekennzeichnet. Je nach Konfiguration des Players wird ein als Werbung ge- kennzeichneter Film anders behandelt als die übrigen Filme. Er kann zum Bei- spiel aus der Playliste ausgeblendet und die Playerkontrollen vorübergehend de- aktiviert werden. Nähere Details zu den möglichen Konfigurationseinstellungen und deren Auswirkung werden im Kapitel 4.3.1 behandelt. Der dritte optionale Parameter duration hat nur eine Auswirkung, wenn der Typ des Videos image ist. Ein solches Standbild verhält sich im Player so wie ein normales Video, wel- ches nur ein stehendes Motiv zeigen würde. Über den Parameter duration wird die Abspieldauer dieses virtuellen Videos in Sekunden festgelegt. Wird der Pa- rameter weggelassen, erhält das Standbild eine Standardwiedergabedauer von zehn Sekunden.

-85- Prototypische Umsetzung einer Web-TV Anwendung

4.4.4 Zusätzliche Audiospuren

Parameter: src : Quelladresse des Sounds loop : Den Sound als Schleife abspielen (Werte: true oder false)

Beschreibung: Das Soundelement ermöglicht es eine separate Tonspur zu einem Film an- zugeben. Dies ist primär zur akustischen Untermalung von Filmen gedacht, die durch ihren Medientyp selbst keine Audiounterstützung mitbringen, wie zum Beispiel Standbilder. Das Sound-Element kann jedoch prinzipiell bei allen Film- typen verwendet werden. So lässt sich zum Beispiel auf einfache Weise ein Video, dessen Tonspur nur Sprache enthält, nachträglich und je nach Bedarf mit ambien- ter Musik unterlegen. Das Sound-Element ist ein optionales Kindelement des I- tem-Elements. Es kann pro Item nur ein Sound angegeben werden. Der Parame- ter src gibt die Quelladresse der Tonspur an. Es werden nur Audiodaten im MP3 Format unterstützt. Der optionale Parameter loop legt fest, ob der Sound als Endlosschleife abgespielt werden soll. Mögliche Werte sind true und false. Der Standardwert ist false.

4.4.5 Overlays

XML-Notation:

Parameter: x : x-Abstand vom Bildschirmrand in Pixeln y : y-Abstand vom Bildschirmrand in Pixeln pos : Position auf dem Bildschirm (Werte: bottom, right, top, left) src : Quelladresse der Overlaydatei transparent : Transparenz des Overlays in % (Werte: 0 bis 100)

-86- Prototypische Umsetzung einer Web-TV Anwendung

Beschreibung: Mithilfe des Overlay-Elements können zusätzliche Bilder und Animationen auf dem Bildschirm des Web-TV Players angezeigt werden, die den eigentlichen Film überlagern. Das Overlay-Element ist ein optionales Kindelement des Item- Elements. In jedem Item können mehrer Overlays angelegt werden. Diese werden alle gleichzeitig auf dem Bildschirm angezeigt. Die Reihenfolge, in der die Over- lays in der Playliste definiert sind entspricht bei der Darstellung im Player der Überlagerungsreihenfolge. Das letzte Overlay überlagert alle vorherigen. Der src-Parameter ist zwingend notwendig. Er gibt die Quelladresse des Overlays an. Alle weiteren Parameter sind optional. Die Parameter x, y und pos bestim- men die Lage des Overlays auf dem Bildschirm. x und y legen dabei den Abstand des Overlays vom Bildschirmrand in Pixeln fest. Ihr Standardwert ist 0. Mit pos kann angegeben werden, an welcher Ecke des Bildschirms sich das Overlay aus- richtet. Dabei können alle möglichen Kombinationen der Werte top und bottom mit left und right angegeben werden. Der Standardwert ist "top left". Über den letzten Parameter transparent kann das Overlay transparent auf dem Bildschirm angezeigt werden. Die Transparenz wird dabei in Prozent von 0 bis 100 angegeben. Eine Transparenz von 100 bedeutet, dass das Overlay unsicht- bar ist. Die Transparenz ist vor allem für Overlayformate sinnvoll, die selbst kei- ne Alpha-Transparenz unterstützen.

Als Overlays können Bilddateien im JPEG-, GIF- oder PNG-Format sowie Adobe- Flashfilme im swf-Format genutzt werden. Dies macht Overlays zu einer sehr vielseitigen Möglichkeit zusätzliche Elemente im Film einzublenden ohne den Film selbst zu bearbeiten. So können nachträglich Senderlogos, Informationstexte, Abdecker oder Maskierungen, wie etwa die aus dem herkömmlichen Fernsehen bekannten schwarzen 16:9-Formatbalken über das Video gelegt werden. Dabei empfiehlt sich besonders das PNG-Bildformat, da es direkt Alphatransparenz un- terstützt und sich damit besser freistellen und optisch in das Videobild integrie- ren lässt.

Eine Besonderheit ist die Möglichkeit Flash-Filme als Overlays einzusetzen. Da- mit stehen die gesamten Möglichkeiten von Flash zur Verfügung, das Aussehen des Videos nachträglich zu ändern. Vor allem ist dieses Format nicht auf Stand-

-87- Prototypische Umsetzung einer Web-TV Anwendung

bilder beschränkt. Somit können auch animierte Overlays erstellt werden. Noch weitaus mächtiger ist jedoch die Möglichkeit auch ActionScript in den Flash- Overlays einsetzen zu können. So können mit einfachen Mitteln interaktive Ele- mente erstellt und über dem Video eingeblendet werden. Abbildung 31 zeigt ei- nen Screenshot des Web-TV Players bei dem drei verschiedene Overlays über dem Film eingeblendet worden sind. Bei den beiden Overlays mit den Nummern eins und zwei wurde ein PNG-Bild als Logo eingeblendet. Mit Hilfe des Transpa- rent-Parameters wurde das Logo bei Nummer zwei stärker durchscheinend dar- gestellt. Das Overlay drei zeigt ein Beispiel für ein interaktives Flash-Overlay. Bewegt der Nutzer den Mauszeiger über den unteren Bereich des Videos blendet sich das Overlay selbstständig ein und bietet ihm die Möglichkeit eine Bewertung für das Video abzugeben. Der benötigte ActionScript-Code zum Einblenden der Bewertungsanzeige und zum Versenden der Bewertung befindet sich direkt im Flashfilm des Overlays und ist vollkommen unabhängig vom Web-TV Player.

Abbildung 31: Verschiedene Overlays über einem Video (1 und 2: Bildoverlay im PNG Format, 3: interaktives Flash-Overlay)

-88- Prototypische Umsetzung einer Web-TV Anwendung

4.4.6 Zusätzliche Informationen

XML-Notation:

Parameter: keine

Beschreibung: Im Info-Element können Zusatzinformationen zum gezeigten Film angegeben werden. Es ist ein optionales Kindelement des Item-Elements und hat keine Pa- rameter. Das Info-Element selbst enthält keine Informationen. Es dient der Struk- turierung und gruppiert die Informationselemente, die in diesem Informations- block angegeben werden sollen. Abbildung 32 zeigt beispielhaft das Ergebnis ei- nes solchen im Info-Element definierten Infoblocks. Die darin rot hervor gehobe- nen Bereiche eins bis drei stellen die innerhalb des Infoelements definierbaren E- lemente dar. Bereich eins ist die Überschrift, Bereich zwei der HTML-Textblock und Bereich drei die Linkliste. Diese Elemente werden nachfolgend beschrieben. Wenn die Höhe des Informationsfensters für die darin angezeigten Inhalte nicht ausreicht, wird am rechten Rand automatisch eine Scrollbar eingeblendet.

Abbildung 32: Elemente der Zusatzinformationsanzeige (1: Überschrift, 2: HTML-Textblock, 3: Linkliste)

-89- Prototypische Umsetzung einer Web-TV Anwendung

4.4.7 Zusätzliche Informationen: Überschrift

XML-Notation:

Parameter: keine

Beschreibung: Das Title-Element ist ein Kindelement des Info-Elements. Es legt die Überschrift des Infoblocks fest und ist zwingend erforderlich, wenn ein Infoblock definiert wurde. Der anzuzeigende Text wird innerhalb des Title-Elements in einem XML- CDATA-Abschnitt angegeben. In Abbildung 32 ist das Ergebnis des Title- Elements in der Informationsansicht in dem rot hervorgehobenen Bereich eins zu sehen.

4.4.8 Zusätzliche Informationen: HTML-Text

XML-Notation: html-tags ]]>

Parameter: keine

Beschreibung: Das Text-Element ist ein optionales Kindelement des Info-Elements. Innerhalb des Text-Elements wird in einem CDATA-Abschnitt der Text zur Anzeige im In- fobereich festgelegt. Dabei dürfen einfache HTML-Elemente zur Formatierung benutzt werden. Unterstützt werden zum Beispiel die Tags zur Fettschrift , Schrägschrift und zum Unterstreichen . Des Weiteren können über das Anchor-Tag klickbare HTML-Links innerhalb des Textes festgelegt werden. Mit dem Image-Tag können zusätzlich Bilder im Textblock definiert wer- den. Der Text umfließt die Bilder dabei automatisch. Eine vollständige Liste aller unterstützten HTML-Elemente und deren Gebrauch kann in den Live-Docs von Adobe online abgerufen werden [Adobe 2006e].

-90- Prototypische Umsetzung einer Web-TV Anwendung

4.4.9 Zusätzliche Informationen: Formatierung des HTML-Texts

XML-Notation: