Digitaler Film. Artikel, Internet TV, Technologien, Videohoster

Nachdem der Flash Player beim ersten Proof of Concept etwas verstümmelt daher kam, möchte ich anlässlich einiger Verbessungen etwas Auführlicher auf die Features und die Auswirkungen des Players eingehen. Zuerst einmal hat der Player an sich ein kleines Face-Lift bekommen und ich habe die noch fehlenden Funktionen eingebaut. Zusätzlich zum Autor und Titel wird nun ein Thumbnail angezeigt und man kann in den Annotations die Länge des Films oder andere Meta-Daten angeben. Außerdem wird die aktuelle Abspielposition angezeigt. Der Pause/Play-Button funktioniert momentan jedoch erst nach 2-maligem Klicken (warum auch immer).

Als Bonus können die FLV-Dateien der Videos über einen Rechts-Klick herunter geladen werden (dazu muss vermutlich der Popup-Blocker deaktiviert sein). Das ist ein Feature bei dem ich nicht versteh, warum es die Videohoster nicht schon längst anbieten. Allein mein Blog erhält wöchentlich über über 1000 Seitenaufrufe der Anleitung zum Speichern von Flash-Videos bei YouTube und Co.

Das XSPF-Format

Noch ein paar Informationen zum XSPF-Format, das die Basis der Playlists des Players bildet. XSPF ist ein offenes XML-Format, das mittlerweile schon von einer ganzen Reihe von (Web-)Anwendungen unterstützt wird. Der Aufbau ist eigentlich selbsterklärend, trotzdem hier nochmal die wichtigsten Punkte, die zu einer Playlist gehören.


Umschließt das einzelne Video
http://lax-v10.lax.youtube.com/get_video?
video_id=p_YMigZmUuk Gibt den Ort der FLV-Datei an.
http://sjl-static3.sjl.youtube.com/vi/p_YMigZmUuk/2.jpg
Ort des Thumbnails.
YouTube Autor des Videos
Titel des Videos
2:07 min Zusätzliche Metainformationen

Die Vorteile des Breitbandplayers

Nachdem die prinzipiellen Funktionen des Players geklärt sind hier noch einige Vorteile, die ein Playlist gestützter Player bietet.

• Es lassen sich Videos von verschiedenen Videohostern in einem Player zusammenfassen. Es muss nicht für jedes Video ein eigener Flash-Player eingebunden werden. Der Vorteil ergibt sich auch bei einer Vielzahl von Videos von einem Videohoster.
• Es ist einfacher die Playlist zu aktualisieren. Der Besucher einer Seite sieht so immer eine aktuelle Auswahl an Videos. Momentan ist es zwar noch etwas Mühevoll an die FLV-Datein zu kommen und eine XSPF-Datei zu erstellen, doch Dienste, die Videos mit einem Klick automatisch der Playlist hinzufügen, werden kommen. Entsprechende Lösungen gibt es bereits für MP3 Playlisten.
• Produzenten, die an den Upload-Limits scheitern, müssen ihre Werke nicht mehr bis zur Unkenntlichkeit komprimieren. Der Breitbandplayer spielt die Videos der Playlist kontinuierlich ab. Der Produzent teilt sein Video in handliche Portionen und setzt es über eine Playliste wieder zusammen. Netter Nebeneffekt: die einzelnen Videos können als Kapitel direkt angesprungen werden.
• Mit XSPF hat man ein Format, das vielfältige Einsatzmöglichkeiten bietet. Die Playlisten und Channels der User könnten so zwischen Diensten ausgetauscht werden. Sollten die Videohoster XSPF oder etwas ähnliches Implementieren, würden sie damit ihre Playlist-Features aufwerten. Das kontinuierliche Abspielen einer Playlisten auf YouTube ist nicht gerade die Offenbarung (Seiten-Reload nach jedem Video). Außerdem wären die Playlisten nicht mehr nur auf den Mikrokosmos des einzelnen Videohosters beschränkt.
• Mit einer Forcierung des Playlist-Gedankens ergeben sich neue Ansätze für die Werbung. Das prinzipielle Problem aller Videohoster, die darüber nachdenken Pre-Roll oder Post-Roll Werbeclips an ihre Videos zu hängen ist, dass ein solches Vorgehen viele User abschrecken wird. Kein Wunder, denn der durchschnittliche YouTube-User verbringt ca. 30 Minuten auf der Seite. In dieser Zeit wird er wohl zwischen 10-15 Videos sehen und er würde somit auch 10-15 Werbespots sehen, nicht gerade Benutzerfreundlich. Mit dem Playlist-Konzept ließe sich Werbung in die Playlist integrieren und der User sieht die Werbung einmal beim Abspielen der Playliste zwischen zwei Clips.
• Einfacher Internet-TV Sender. Die Technik ist so einfach, dass sich damit einfach und schnell ein eigener Breitband-Kanal betreiben lässt. (Wenn die oben genannten Dienste existieren).

Was können die Videohoster dagegen tun?

Wie bereits im ersten Beitrag angedeutet ist es nicht selbtverständlich, dass die Videohoster eine solche Entwicklung begrüßen werden (Verlorenes Branding und Degradierung zum Infrastruktur-Provider). Was könnten sie also tun um eine solche Entwicklung zu verhindern?

• Verschlüsseln der FLV-URL. Wie bereits Angedeutet verschlüsselt Google Videos die URLs zu den FLV-Dateien. Allerdings habe ich festgestellt, dass dies lediglich das automatisierte Auslesen der URL verhindert. Man kann die URL trotzdem in den Player einbinden.
• Sperren des Fremdzugriffs per .htaccess. Ähnlich wie das Hotlinken von Bildern kann man auch das Hotlinken von FLV-Dateien unterbinden. Das Problem hierbei ist, dass anschließend wohl auch die original Player, die auf Blogs usw. eingebundenen sind nicht mehr funktionieren.
• Übergeben einer eindeutigen ID. Dailymotion übergibt mit der Anfrage für die FLV-Datei einen Code, der wiederum nur für kurze Zeit gültig ist. Ähnlich funktionieren die Breitbandplayer von Brightcove, die zudem noch die Quell-URL übergeben. Die Brightcove Datenbank überpfüft die die Gültigkeit dieser Daten vor der Auslieferung der FLV-Datei. Die Übergabe einer ID, die das Abspiel verifiziert ist sicherlich ein fruchtbarer Ansatz, der jedoch noch weiter verfeinert werden sollte.
• Entwicklung eines DRMs für Flash

Es gibt also Möglichkeiten für die Videohoster auszusteigen, bleibt noch die Frage wie man den Wunsch des Produzenten berücksichtigt. Momentan gibt es keine Möglichkeit aus den Profil-Seiten der Videohoster Rückschlüsse auf die Intention des Produzenten zu ziehen. Möchte er ein möglichst breites Publikum erreichen? Will er das Video eigentlich nur seinen Freunden zeigen? Will er damit Geld verdienen? Wünschenswert wäre es hier, dass die Produzenten, ähnlich wie del.icio.us eine Lizenz (Creative Commons, Copyright, Public Domain usw) für ihre veröffentlichten Videos auswählen können. Diese Lizenz kann dann beim Erstellen von Playlisten berücksichtigt werden.

Warum die Videohoster die URL nicht blockieren sollten.

Auf den ersten Blick erscheint es vernünftig, dass die Videohoster versuchen ihre Inhalte zu schützen und “Fremd-Nutzer” aussperren. Allerdings wird dabei ein wichtiger Faktor vergessen: Die Videohoster machen einen Spagat zwischen den Zuschauern und den Produzenten der Videos. Wenn sie versuchen ihre Zuschauerschaft zu maximieren, indem sie die Verbreitung der Videos einschränken schaden sie dadurch ihrem Ansehen bei den Produzenten.

Die Erklärung dafür liegt in der Natur der Videohoster. Fred Wilson umschreibt die DNA der Videohoster sehr treffend mit

services that feel centralized but are really application specific edge feeders. [...] I could post a video directly to my blog, but I don’t. I post it to vimeo, youtube, or blip.tv, and then from there I post it to my blog.

Hinzu kommt noch, dass die meisten User ungern auf Videos verlinken, sondern es bevorzugen Videos direkt an Ort und Stelle einzubinden. Der MySpace Musikplayer ist das beste Beispiel hierfür und auch der lässt sich per Playlist füttern.

Weitere Gründe dafür die FLV-Dateien so zugänglich, wie möglich zu machen habe ich im Artikel Nicht Tauschbörsen sind die Gefahr sondern die Lightnets. im Abschnitt “Die Macht der URL und des Links” ausführlich behandelt.

Bleibt noch zu sagen, dass das Vermischen und Remixen von Diensten mit Hilfe anderer Dienste ein elementarer Bestandteil der ganzen 2.0-Welt ist. Warum sollten sie sonst APIs anbieten?

Download der Dateien: XSPF-Playliste, Breitbandplayer 2, für die Quelldateien Email an mich.

Share This

Tags: none

Verwandte Artikel:

• Vorschau auf Sevenload 2.0
• Breitbandplayer, Quellcodes und Whitelabels
• Der nächste Schritt: Videohoster Mash-up mit dem eigenen Breitbandplayer.
• Videohoster im Porträt. Telepolis

10 Kommentare