Archive for the 'webTV' Category

Touch my flash

Published on February 22, 2010 in Tech and webTV. 0 Comments

Tim Pritlove hat mich dankenswerterweise auf einen Artikel mit der Überschrift: “An Adobe Flash developer on why the iPad can’t use Flash” aufmerksam gemacht.
Daniel Eran Dilger Morgan Adams – seineszeichens Flash Entwickler – zählt darin viele Argumente auf, warum Flash auf dem iPad wahrscheinlich keine tolle Anwendererfahrung wäre.

Vorneweg I: Ich hatte bei dem Artikel eigentlich das übliche “Wir lieben S. Jobs und Flash ist total blöd” gebashe erwartet. Das bleibt aber aus. Und das Kernargument des Artikels habe ich selbst so zum ersten mal gelesen … und es ist intelligent. Außerdem passt es gerade zum aktuellen Diskurs.

Vorneweg II: Das Thema “Zukunft von Flash” kocht immer noch höher. Aktuell will ich nur auf zwei Artikel in der deutschen IT-Szene hinweisen. 1.) FSF: Google soll Flash den Todesstoß versetzen / Golem.de mit hochamüsanten Kommentaren und 2.) Google: weniger Gears, mehr HTML 5 / heise.de mit wirklich höchstamüsanten Kommentaren. Wer sich duch die beiden Kommentar-Threads durchgearbeitet hat, der hat einen recht guten Überblick was gerade an Pro und Kontra Flash Argumenten so geht – und obendrein welche Schimpfwörter eigentlich gerade so “En Vogue” sind.

Kommen wir also zum Kernargument. Multi-Touch Systeme sind keine 1 zu 1 Übersetzung der guten alten Maus. Das trifft insbesondere meinen Link aus dem letzten Artikel von The Flash Blog. Dort wird einmal sehr lustig und anschaulich gezeigt, wie das Internet ohne Flash aussieht. Die Kernaussage ist quasi: Lasst zu, dass Adobe Flash auf die Endgeräte portiert – und alles wird gut.

Das ist etwas zu kurz gedacht. Obwohl Multitouch Systeme bestimmte Eingaben (Zoom, Slides, Scroll) viel schöner umsetzen als es mit einer Maus möglich ist, bietet die klassische Maus bezogen auf einen Bildpunkt oder Knopf o.ä. vier Zustände der Interaktion: Mouse Over, Klick, Doppelklick und rechte Maustaste. Wenn wir Doppelklick und die Verwendung der rechten Maustaste mal außer acht lassen bleiben immer noch zwei Zustände die Mausbenutzer alltäglich anwenden. Wir sind gewohnt bei Mouseover mit mehr Informationen und Interaktionsmöglichkeiten versorgt zu werden und diese dann mit dem Mausklick zu aktivieren. Beispielsweise blenden die meisten Videoplayer die Controlls erst bei Mouseover ein. Die neuen Apple-Produkte kennen diesen “Mouseover” Zustand nicht.

Ich stimme mit Daniels Morgans Ergebnis nicht überein, dass damit Flash und das iPad einfach nicht zusammen passen – aber eines ist richtig: Für die Produzenten von Flash Inhalten bedeuten Multitouch Displays eine größere Umstellung, als allgemein angenommen wird. Es wird ein Prozess der Anpassung stattfinden.

Ein Beispiel für einen ähnlichen Anpassungsprozess sind die Lauftexte bei Nachrichtensendern. Moderne LCD-Bildschirme geben Fernsehbilder als 25p – Format und nicht als 25i Format wieder – dadurch geht eine Menge Bewegungsinformation verloren. Die meisten Nachrichtensender haben sich daher dem neuen Medium angepasst und benutzen anstatt der Lauftexte kleine Tafeln, die sich am unteren Bildrand austauschen und deutlichen besser für das Netz zu komprimieren sind und auf LCD Bildschirmen sehr gut darzustellen sind.

Eine neue Technologie bedeutet also zum einen nicht, dass man die alten Inhalte 1zu1 übernehmen kann – zum anderen bedeutet aber auch eine technologische Neuerung nicht automatisch, dass alles schon dagewesene Mumpitz ist.

Nachtrag 22. Feb 14:30 Uhr / Da war ein Dreher im Artikel. Daniel Eran Dilger ist der Autor des Eintrages. Der Inhalt und die Argumente stammen aber von Morgan Adams. Nochmal danke @tim für das aufmerksame Lesen.

Warum alle Flash hassen – und wir es trotzdem nutzen.

Published on February 11, 2010 in code and webTV. 3 Comments

via @MadeMyDay

In letzter Zeit häufen sich die Anfragen bei unserer Firma, warum wir in noch so vielen Fällen auf Adobe Flash für das Frontend setzen. Die Technologie sei überholt – die Alternativen mit Javascript und html5 mannigfaltig und außerdem verabschiedet sich Apple offenkundig mehr und mehr vom Flash-Player auf den Plattformen iPhone, iPod und iPad.

Zunächst einmal wird diese Diskussion mit sehr vielen Emotionen geführt. Ich bin immer wieder erstaunt, wie viele Menschen (vor allem Entwickler) Adobe Flash vom Grunde ihres Herzens hassen. Kaum eine andere Technologie ist so stark verbreitet und hat so wenige Freunde.

Warum alle Flash hassen:

Die Abneigung gegen Flash als Entwicklungsumgebung und den damit verbundenen Flash-Player ist u.a. erklärbar aus den ersten Versionen der Entwicklungsumgebung. Die ersten Versionen von ActionScript und der dazugehörigen grafischen Entwicklungsumgebung hatten den Namen nicht verdient. Vor allem lenkten sie aber den Unmut von Entwicklern auf sich, da mit diesen Entwicklungsumgebungen auf einmal jeder Grafiker sich aus bunten Kästchen und ein wenig klicki-klacki einen Prototypen hat zusammenzimmern können. Auf einmal wurden in jedem Meeting Prototypen von Menschen herumgereicht, die in ihrem Leben noch keine Zeile Code geschrieben hatten. Das hatte etwas von Konkurrenz, aber auch sehr viel von Dilettantismus. Softwareentwickler mussten sich auf einmal rechtfertigen, warum sie für etwas mehrere Monate Zeit brauchen – wo doch Frau A. aus der Buchhaltung einen Prototypen in 5 Stunden bauen konnte. Das war eine sehr frustrierende Zeit.

Zusätzlich kam mit der Entwicklung von Flash auf einmal die Unart auf, Webseiten mit einem Flash-Intro beginnen zu lassen. Jeder Benutzer musste sich ein teilweise mehrminütiges fragwürdiges grafisches Machwerk anschauen, bevor er an die gesuchte Information kommen konnte. An diesem Umstand trifft Macromedia (denen gehörte damals Flash) keine direkte Schuld – aber die Wirkung auf die Akzeptanz bei den IT-affinen Usern war verheerend.

Ferner ist Flash heute eine so komplexe Umgebung geworden, dass man bei der Entwicklung in Flash sehr viele unanständige Fehler machen kann … und sie werden andauernd gemacht. Oftmals liefern Flash-Seiten keinen RSS Feed aus, haben keine Permalinks auf einzelne Zustände der Seite und werden von den Suchmaschinen nicht gefunden. All dies sind Features, die man bei der Entwicklung in einem nicht-Flash-Framework meistens “geschenkt” bekommt – und sie sind in Flash-Umgebungen wirklich etwas umständlich zu erzeugen.

Die Apfel-Rolle

Äpfel und Birnen

http://www.flickr.com/photos/apfelherz/275675061/ via http://www.flickr.com/photos/apfelherz/

Jetzt kommt noch Apple um die Ecke und versucht der Technologie Flash praktisch den Gnadenstoss zu versetzen. Die neuen Apple Geräte (iPhone, iPod, iPad) unterstützen kein Flash und etwaige Entwicklungen Flash trotzdem auf die Plattformen zu portieren werden unterbunden. Das Argument für die nicht Flash Unterstützung ist die “Fehlerhaftigkeit” des Flash Players … und im übrigen kann den Flash Player doch sowieso keiner Ausstehen. Das sagt zwar keiner – ist aber trotzdem immanenter Bestandteil der Argumentation. Nun kommt im Fall Apple ein Umstand dazu, der öffentlich nicht so intensiv diskutiert wird. Adobe Flash bietet die Möglichkeit sehr einfach Systeme für die Verteilung von Video- und Audiomedien aufzubauen. Eine direkte Konkurrenz zum iTunes Store. Warum sollten die User der i-Produkte weiterhin ihre Musik und ihre Video über den i-Store kaufen, wenn es auf dem gleichen Gerät einen komfortablen Zugriff auf andere Geschäfte mit einem evtl. anderem Preismodell oder einer werbefinanzierten Medienverteilung gibt? Es ist nicht im Interesse von Apple dieses auf den neuen Proprietären Medienwiedergabe- und Mediekauf-Geräten zu unterstützen.

Ich liebe Apple Produkte – wie fast jeder, der einmal auf einem Mac gearbeitet hat – aber ich möchte nicht, dass Technologien die sich als Standard etabliert haben aus meinem Geräten ausgesperrt werden. An dieser Stelle sei auf diesen Artikel verwiesen http://theflashblog.com/?p=1703 er beschreibt sehr schön, wie das Netz ohne Flash aussieht. Und ich bin es als User inzwischen auch schon etwas satt beim surfen auf meinem iPhone andauernd auf das blaue “es-geht-leider-nicht” Logo zu stossen.

Warum wir trotzdem mit Flash arbeiten

Wir entwickeln mit der schnee von morgen (schneevonmorgen.com) Lösungen für professionelle Broadcaster und betreiben u.a. die Plattform dctp.tv. Als die Entwicklung an diesem Projekt gestartet ist, haben wir viele Möglichkeiten evaluiert. html5 war damals noch kein Thema – aber inzwischen haben wir uns auch intensiv mit den Möglichkeiten von html5 auseinandergesetzt. html5 ist die aktuelle Weiterentwicklung des html Standards und wird bereits von der aktuellsten Browser-Generation unterstützt. In html5 ist ein neuer Video-Tag enthalten mit dem es sehr einfach möglich wird Videos in Webseiten einzubinden. YouTube und Vimeo haben bereits html5 Versionen ihrer Seiten entwickelt. Das ist sehr vielversprechend.

Unsere Kunden besitzen Rechte an der Ausstrahlung von Medien – sind aber nicht in jedem Fall an der Verbreitung von Kopien der Medien interessiert. Das bedeutet: es gibt einen Unterschied ob ich einem Zuschauer die Möglichkeit gebe einen Film anzusehen, oder ob ich ihm die Möglichkeit gebe den Film herunterzuladen. Die Filme auf YouTube und Vimeo werden schon heute mit einer Technologie ausgeliefert, die eine lokale Kopie der Videodatei auf dem Rechner des Zuschauers erstellt. Dies ist für ein modernes Rechtemanagement nicht in jedem Fall zielführend. Der html5 Standard benötigt aber einen direkten Link auf eine Download-Location der Videodatei. Jeder User kann sich also den Quelltext der Seite ansehen und findet sofort den Link auf die Datei zum downloaden. html5 unterstützt kein Live-Streaming von Ereignissen und kein Streaming von Medieninhalten. html5 ist lediglich eine – sehr gute – Möglicheit um eine Mediendatei schnell und einfach auf einer Webseite (dem eigenen Blog) einzubinden.

Wenn ich in Diskussionen unseren Standpunkt bezüglich des Rechtemanagements vertrete höre ich oft die Antwort: “Ja – jetzt verstehe ich, warum ihr den Flash-Player einsetzen müsst … aber muss denn die ganze Seite in Flash sein?”.

Das ist eine gute Frage. Und die Antwort muss hier differenzierter ausfallen. Der Kern der Antwort besteht in der Frage: Macht denn die Seite irgendeinen Sinn ohne den Flash-Player? Und unsere Antwort darauf ist: Nein. Im konkreten Fall webTV und wenn das Zentrale Film-wiedergabe-Dings der Flash-Player ist – dann gibt es (außer einer möglichst schönen Fehlermeldung) nichts, was die Seite tun könnte um den Umstand zu verschönern, dass sie einfach nicht funktioniert. Um den Fernseher als Beispiel zu nehmen. Wenn der Bildschirm keine Filme darstellen kann – dann bringt mir auch die EPG Information keinen Vorteil.

Von diesem Grundgedanken ausgehend – und ich gebe zu es handelt sich hier bei der Konstruktion von webTV Sendern um eine sehr spezielle Anforderung – blieb also noch eine letzte Frage offen.

Noch einmal zusammengefasst:

  • Der Flash-Player wird (zunächst) das zentrale Video-wiedergabe-Ding sein, wenn es darum geht a) eine möglichst große Zuschauerzahl zu erreichen und b) die Filme nicht zum download freizugeben.
  • Eine webTV Seite ist ohne den Flash-Player defekt, da sie keinen anderen Sinn hat um möglichst schön die Videos anzuzeigen.

Also. Davon ausgehend ist die letzte Frage: Bringt es aus Entwicklersicht Vorteile eine Seite in einem Mix aus Javascript – Framework, DHTML, und einem Flash Framework zu entwickeln. Ist es günstiger oder stabiler oder besser zu handhaben? Unsere Antwort darauf ist: Nein. Mit Flex hat Adobe ein professionelles Entwicklungs-Framework bereitgestellt, welches schöne und integrative Werkzeuge für das Testen, Dokumentieren und Verwalten von größeren Softwareprojekten bietet. Wir debuggen an einer Stelle und nicht an fünf Fronten. Ich sehe die Entwicklung moderner Javascript-Frameworks mit großer Freude und werde den Vorgang regelmäßig erneut evaluieren. Aber bis heute bietet uns Flash bzw. Flex bei der Entwicklung, dem Styling und dem Testen von Webseiten (leider) den meisten Komfort.

An dem Tag, an dem es ein offener (echter) Standard schafft eine sichere und gestreamte Medienwiedergabe ohne Browserplugin auf über 90% der installierten Browser zu gewährleisten werde ich mich bekehren lassen und an dieser Stelle revidieren.

Dann legt mal los – auf die Kommentare bin ich gespannt!

Update 11. Feb 20:49 Uhr / Adobe PR Germany is now following you on twitter … so war das aber nicht gemeint.

Weihnachtsgeschenk an alle: Amazon bringt “Streaming aus der Cloud”

Published on December 16, 2009 in Tech and webTV. 3 Comments

Jetzt ist die Nachricht endlich draußen! Amazon bringt im Rahmen der Amazon Web Services (AWS) ein neues Feature auf den Markt. Was im Rahmen dieser kleinen Meldung heute veröffentlicht wurde:

http://aws.typepad.com/aws/2009/12/amazon-cloudfront-now-supports-streaming-media-content.html

hat das Potential den Markt für multimediale Inhalte im Web gehörig umzukrempeln. Wir hatten ausgiebig Gelegenheit die neuen Möglichkeiten im “geheimen” und mit hervorragender Unterstützung von Amazon in den letzten Monaten zu testen. Was Amazon hier auf den Markt bringt senkt die Einstiegshürde für Streaming Media enorm. Während das Aufsetzen einer “Streaming Infrastruktur” bislang aufwengig, teuer und umständlich war – und überdies für kleine Projekte unrealistisch ändert Amazon die Spielregeln.

Mit dem neuen Streaming-Feature muss der Anbieter seine Videodateien nur noch in einen speziellen Ordner ziehen (Bucket) und bekommt nach minimaler Konfiguration einen Streaming-Link (rtmp) auf seine Datei. So einfach!

Wir streamen mit der schnee von morgen webTV GmbH schon seit einem Monat beispielsweise dctp.tv mit dieser Technologie. Wir betreiben momentan noch parallel als Fallback eine eigene Streaming-Cloud (auch auf Amazon Servern) werden die aber in Zukunft nur noch für Live-Übertragungen und besonders sicheres Streaming (DRM) einsetzen.

Chaosradio 137

Published on December 11, 2009 in Me, Media & Links and webTV. 0 Comments

Besser spät als nie. Die meisten werden es schon gefunden haben – aber ich saß vor einem Monat auf dem “Sofa” von Tim Pritlove (das Sofa ist ein sehr schickes Podcast-Studio) und wir haben gemeinsam eine ganze Folge Chaosradio über Streaming gesprochen.

Die Sendung findet ihr hier:

http://chaosradio.ccc.de/cre137.html

Am 25. Dezember werde ich noch einmal im D-Radio zu hören sein. Mehr Informationen dazu folgen an dieser Stelle.

HTTP streaming. Segen oder Fluch? Flegen.

Published on October 19, 2009 in webTV. 0 Comments Tags: .

Inspiriert vom Artikel HTTP streaming aus dem CDN Strategy Blog sehe ich mich genötigt ein paar eigene Worte zum Thema HTTP streaming zu verbreiten.
In letzter Zeit haben mich mehrere Bekannte erregt kontaktiert mit Aussagen wie “der Tod der Streamingserver”, “da kann Adobe einpacken”, “endlich hält sich jmd. an die Standards” u.s.w.. Ich teile die Begeisterung zum Teil … und zum Teil auch nicht.
Vorerst: Was ist das “neue” HTTP streaming und wie unterscheidet es sich von herkömmlichen Technologien? Bei der herkömmlichen Streamingtechnologie (Windows Media Server, Flash Media Server / Wowza / Red5, QuickTime Streaming Server, Real Server …) fragt der Client in einem speziellen Protokoll nach dem Stream (rtmp, rtsp, mms). Der Datenaustausch findet wenn möglich in diesem speziellen Streaming-Protokoll über UDP statt und verursacht so sehr wenig Overhead an Daten (die Bandbreite wird also geschont). Darüberhinaus findet ein ständiger Datenaustausch zwischen Client und Server statt. Der Server versucht immer nur die gerade nötigen Pakete an den Client zu versenden. Wenn der Client an eine andere Stelle des Videos springt, dann erhöht der Server die Bandbreite kurzfristig stark um den Buffer des Clienten zu füllen (Burst). Danach wird die Bandbreite wieder auf das nötigste reduziert.
Die Übertragung im UDP Protokoll spart ca. 10% Bandbreite. Wenn Firewalls die Streaming Protokolle sperren ist es möglich den Stream automatisiert durch http zu tunneln (rtmpt bspw.).

HTTP streaming verwendet einen vollkommen anderen Ansatz. Die Film oder Audiodatei wird dabei in sehr viele kleine Schnipsel (Chunks) zerteilt. Der Client lädt sich eine “Playlist” Datei der Chunks herunter und fragt dann die benötigten Dateien via HTTP GET vom Server an. Der Client lädt zunächst den gesamten Header des Films herunter (der kann bei h264 und einem 30 minütigen Film einige 100 kb umfassen).
Das erste Problem für die Serverinfrastruktur ist, dass mit dieser Technologie sehr, sehr viele Requests auf kleine Files entstehen. Dabei ist es zunächst egal, ob die Chunks real als kleine Filmschnipsel vorliegen oder (sinnvollerweise) mit einem Byte-Range aus der Originaldatei abgefragt werden.
Ich habe noch nicht herausbekommen, was Adobe unter dem angekündigten HTTP streaming im kommenden Flash Player hauptsächlich für mobile Geräte versteht … wahrscheinlich wird es noch etwas proprietärer als man spontan vermuten möchte. Das IPhone unterstützt (seit FW 3.0) HTTPStreaming (Hier ein Link auf die Tech Specs). Auf ioncannon gibt es ein Tutorial wie man ein Video mit OpenSource Mitteln für gechunktes HTTP streaming vorbereitet.

Plug&Play ist etwas anderes. Auf der anderen Seite eröffnet dieser Ansatz die Möglichkeit eine Streaming-Infrastruktur ohne lästige Lizenzkosten zu realisieren. Meiner Einschätzung nach bietet HTTP streaming für große Spieler im Moment keine Möglichkeit die Kosten zu senken. Die benötigte Serverinfrastruktur für HTTP streaming (Transcoding, Verwaltung, Streaming, Logfiles, Statistiken) ist wahrscheinlich größer und komplexer (und daher auch teurer) als es mit bestehenden Streamingserver nötig ist. Trotzdem bietet HTTP streaming für Startups eine Möglichkeit einen Markt zu betreten der qua Investitionskosten einem kleinen Zirkel vorenthalten war.
Außerdem müssen wir proprietäre Protokolle natürlich schnellstmöglich aus dem Netz herausbekommen. Gerade an den relevanten Stellen “Video- und Audiostreaming gibt es endlich eine Alternative zu den bestehenden Lösungen – darüber können wir alle sehr froh sein.

webTV vs. IPTV

Published on October 8, 2009 in webTV. 4 Comments

What the …? Ein Thema, was mich schon seit langer Zeit nervt und ärgert ist die Abgrenzung zwischen IPTV und webTV. Der Markt für Filme im Netz ist de-fakto noch nicht einmal existent und irgendein Schlaumeier kommt auf die Idee den praktisch nicht-existenten Markt durch zwei zu teilen. Mit welchem Ziel?
Ist es nicht viel eher an der Zeit nach Gemeinsamkeiten zwischen IPTV und webTV zu suchen?
Der IPTV Markt wird – zumindest in Deutschland – noch dominiert von proprietären Set-Top-Boxen der Netzbetreiber die hauptsächlich ein Ziel verfolgen: Sich nicht mit der Konkurrenz zu verbinden.
Versucht doch mal als Alice Kunde einen Film der Telekom zu sehen – oder einen Film auf YouTube.
Dieses wird aber natürlich nicht bis in alle Ewigkeit gutgehen. Bald wird es Set-Top-Boxen (Die dann hoffentlich einen schöneren Namen haben – auch Media-Extender geht gar nicht) geben die einfach alles was es so gibt auf dem Fernseher anzeigen. Auch “webTV” und spätestens dann verschmelzen die Märkte wieder die heute mit soviel Energie und Ehrgeiz getrennt werden.