In the world of video, however, H.264 is everywhere. It’s in Blu-ray; it’s in the latest version of the ATSC American digital TV specification, it’s used with the European DVB family of digital TV specifications, it’s in the 3G-324M video call specification; hardware support is found in every modern smartphone, on every modern GPU (which will sooner or later translate into every modern CPU); it’s in camcorders and cameras and digital workflows. H.264 is not going away. It’s already entrenched, and the incorporation into TV standards means that in all likelihood, H.264 will be in use for decades.

WebM has none of this. There are efforts to provide hardware support for WebM, but widespread distribution of such features is some way off (if it ever happens at all; it may well remain a niche technology), and inclusion of WebM into the broadcast and optical disc standards is phenomenally unlikely.

Und ich schließe mich auch an: Auch jetzt dürfte der Anreiz für Videoplattformen nicht größer werden. Warum sollten sie denn jetzt ihre komplette Video-Infrastruktur von H.264 auf webM umstellen? Das ganze läuft nur darauf hinaus, dass Chrome User ab Version (10? 11?) dann eben vermehrt Flash (mit H.264-Player) sehen. Politische Entscheidung seitens Google? Das Geld (laut Artikel 6,5 Mio) könnten die aus der Portokasse bezahlen, und andere nicht non-royality Software wird weiterhin ausgeliefert: Flash, MP3, AAC.

It looks like sticking with Flash and ignoring <video> is indeed what SmugMug may end up doing. And who can blame them? Flash works for almost every Internet user, and Flash supports H.264.

Ich sagte es bereits früher: Nahezu alle Videoplayer sind eigentlich nur Flash Player mit H.264-Content.

Übrigens, schöner Schlusssatz des Artikels:

Google’s decision—a decision to exclude support for an open codec, giving users fewer choices and an objectively inferior browser, does nothing to advance the open web. It means eschewing open standards in favor of Google-controlled proprietary standards, and it means that Flash remains the single best mechanism for delivery of web video.

Das ist nicht in unserem Sinne, Google!

Ein Kommentar zu der Geschichte einiger Presseorgane, dass Google uns ja (in Suchergebnissen) nur manipulieren würde, dass es nur erkaufte Imagepolitur wäre, u.ä.

Lesenswert.

But who cares whether it’s great or it’s crap — isn’t the point of “open” supposed to be that the consumer can choose what they want on their own devices? Instead, open is proving to mean that the� carriers can choose what they want to do with Android.

In einer idealen Welt würde man den fiesen Kindern das Spielzeug aus der Hand nehmen und Google würde das nur noch unverändert lizenzieren. Wäre wesentlich mehr “open” für den Endkunden als heute.

via dfb

Etwas ähnliches hatte ich ja bereits einmal erwähnt, und dieser Artikel fasst es auch noch mal zusammen. Wenn das Spielchen wirklich so weiter geht, dann führt Android zu einer Welt, wo zwar die Basis mehr oder weniger “open” ist, nur der Enduser davon nichts mehr mitbekommt.

Also quasi teilweise so, wie es teilweise früher war.

Zusammengefasst lässt sich sagen: Die Provider haben bereits begonnen, “exklusive Zusatzleistungen” in Form von unlöschbaren Apps zu bringen. Und dabei handelt es sich nicht um Basics wie Mail oder Kalender, sondern PC-Bloatware-typischer Softwaremist halt.

Es scheint langsam so, als würde ein beachtlicher Teil von Androids “Open” von den Providern genutzt — und gleichzeitig zugemacht. Schade um den Grundgedanken an Android, aber es sind die Provider.. was soll man schon erwarten.

PS: Ja, das iOS hat auch einige Basics, die nicht zu löschen sind. Neben internen Apps wie den “Einstellungen” oder auch Essentials wie Mail und Browser sind dabei auch Wetter, Stocks, YouTube & Co. Streitbar, ob letzte nun wirklich jeder braucht.

Google hat jetzt veröffentlicht, wie die Verteilung von Softwareversionen grad so ist… und… Überraschung: Android 1.5 führt. Und dann 2.1, aber dicht gefolgt von 1.6. W-O-W. Die Geräte- und Mobilfunkhersteller lernen auch im dritten Erfolgsjahr von Apple einfach nicht dazu. Es wird die 66% der Benutzer sicher freuen, dass sie wahrscheinlich bspw. nie die offizielle Twitterapp nutzen können. Selbstverständlich nur ein Stellvertreter für alle neuen Apps – man muss ja kein Twitter nutzen.

Notiz am Rand: Während Golem.de korrekterweise von “Zwei Drittel aller Android-Smartphones sind veraltet” spricht, beschönigt Heise das mit “Android 2.1 holt auf”. Stimmt zwar, liest sich aber anders.

Weiterhin scheint sich Apple aber zu sträuben endlich auch Flash auf ihre mobile devices zu bringen. Während es bei der iPod Touch/iPhone-Palette durchaus verständliche Gründe aus Sicht der Performance und auch der Usability gibt, werden diese Gründe bei iPad natürlich geringer. Warum also sonst?

Performance

Leider haben Flashobjekte immer wieder die Angewohnheit, sowohl CPU- als auch RAM-lastig zu sein. Ob das nun ein Problem vom Flashplugin oder vom zuständigen Entwickler ist, das kann man so natürlich nicht sagen. Dazu kommt, dass Adobe sich nicht imstande sieht, für Nicht-Windows-Systeme eine ordentliche Version es Flashplayers herauszubringen.

Oder um es mal am Beispiel zu nehmen: Es ist definitiv nicht normal, dass ein Flashspiel wie Farmville auf einem iMac Core 2 Duo mit knapp 3Ghz und 4 GB Ram gerne mal 50-150% CPU und das Flash-Plugin alleine (also ohne Browser) über 200 MB beansprucht. Und zwar im “ohne Details”-Modus. Youtube-Videos sind da mit 40% und nicht nennenswertem RAM-Verbrauch gelinde gesagt überschaubar.

Diese Probleme könnten auch auf dem iPad oder iPhone auftreten, ein Umstand, den Apple definitiv vermeiden will. Performance-Killer sind nicht erwünscht (irgendwie auch verständlich).

User Interface (UI)

Flashanwendungen sind immer für eine Interaktion� mit einer Maus konzipiert. Wie sollen die mit einem Touchpad harmonisieren? De facto bedeutet das, das eine Reihe von Flashanwendungen nicht “funktionieren”, weil das Plugin keinen richtigen Unterschied zwischen Bewegen und Klicken oder Rechtsklick vermitteln kann bzw. das “Mauszeigerziehen” überhaupt nicht in der Form vorhanden ist. Und iPhone/iPad spezielle Gesten sind komplett unbekannt. Eine große Inkonsistenz – und von Adobe habe ich in der Richtung noch nichts gehört. Das ist auch nicht im Sinne von Apple, die ein konsistentes System anbieten wollen.

Stichwort Konsistenz: Selbst die einzelnen Flashplayer haben alle eine eigene UI und Benutzerführungslogik: Zusammenfassend kann man wohl sagen, dass der Play-Button meistens links ist. Mal darf man zoomen, mal gibt es Vollbild, mal darf man spulen. Manchmal ist der Button rund, mal ist er eckig. Das passt ebenfalls nicht in die konsistente und einfache Welt des iPhones – und iPads.

Nicht zu vergessen sind natürlich noch diese “Hammer-Player-mit-jedem-Schnickschnack-der-möglich-ist”-Flashanwendungen, bei denen definitiv ein Koller vorprogrammiert ist.

Die Alternative, einfach die Funktionen zu reduzieren, ist natürlich eine Sache von Adobe und vom dem Entwickler. Und, nein, nicht wirklich eine Option (die genutzt würde).

Festzuhalten ist also: native App > Web App > Flash App

Flash für alles und nichts

Flash ist eins der meist verbreitesten Internetplugins, und tatsächlich haben viele Seiten ein Flash “versteckt”.

• Werbung (und danach kräht außer der Werbebranche nun wirklich keiner nach);
• komplexe Anwendungen (wie etwa auch o.g. Farmville), die wohl als native bzw. Device-optimierte App wesentlich besser geeignet wären;
• Flashvideoplayer;
• “Ich-wusste-es-nicht-besser”-Statements.

Letzteres sind Dinge wie Navigationsmenüs oder “Webseitenlogos” in Flash, die in der Regel ein gutes Statement zur Inkompetenz aufweisen. Der Großteil ließe sich mit HTML/CSS/Javascript auch lösen (und ja, das Web bietet auch kostenlose(!) Frameworks für Animationen) – und das zu einem Bruchteil der benutzten Browserperformance. Aber Unkenntnis und das Flash-Buzzword bieten halt leider viel Potenzial für solche Lösungen. Nur einige hoch angesetzten (oder utopisch?) Anforderungen müssten wirklich Flash nutzen; und natürlich nur aus Flash bestehende Anwendungen. Diese Webseitenbetreiber wissen aber auch, dass sie damit eine Reihe von Leuten ausschließen (und sei es nur mangels großem Display). Kann sich jemand wirklich und ernsthaft die ZDF-Mediathek als Flashanwendung vorstellen? Auf dem iPhone? Auf dem iPad? Letzteres vielleicht, aber auch nur wenn die Auflösung mitspielt, denn Flash hat stets eine fixe Größe. Eine native App würde wohl jeder vorziehen, wohl auch zu Recht..

Am Beispiel: Die gesamte Produktpalette von Google wäre sicherlich nicht so erfolgreich, wenn sie Lösungen aus Flash nutzen würde. Man stelle sich das vor, Google Mail oder auch Microsofts Outlook Web als eine große Flashanwendung. Unfassbar, jeder würde den Kopf schütteln.

Als Fazit: Alternativen – und was wohl dahintersteckt

Als eine die Alternative für Flash ist HTML5/CSS3 anzusehen, welches u.a. eine starke Unterstützung für “Anwendungen” im klassischen Sinne anbietet.; beispielsweise Datenbank-API, File-API und natürlich das Video-Tag. Apple ist auf den Zug aufgesprungen, als sie das iPhone (in der ersten Version, wohlgemerkt!) mit dem hauseigenen Browser WebKit ausstatteten. Unterstützt mit der Tatsache, dass sie ein paar Ergänzungen in ihrer MobileSafari im Vergleich zum normalen WebKit machen, besitzen iPod/iPhone/iPad damit einen leistungsstarken Browser. Nicht ohne Grund setzt auch Google in Adroid auf diese Browserengine, wenngleich mit anderer Javascriptengine.

Der Browser selber hat im Gegensatz zu Flashplugins (die quasi ja nur eine Schnittstelle zu einer anderen Anwendung herstellen) den großen Vorteil, dass sein UI durch das Betriebssystem gesteuert wird. Im Gegensatz zum Flash, wo dies jeder Entwickler selber macht.

Flashvideo? Brauchen wir nicht, der HTML5-Videotag macht’s möglich. UI-Effekte wie Transformationen (größer, kleiner, verschieben, Farbwechsel) mit Javascript oder sogar Flash? Brauchen wir nicht, geht mit CSS3. Eine Flashapp zum Speichern von Daten (serverseitig)? Braucht man nicht, geht auch mit HTML5/Javascript. Außerdem gibt es integrierte Offline/Online-Sync-Möglichkeiten.

Für mich sind mögliche Offline-Webanwendungen ein Killerfeature für mobile devices, denn warum soll “Netz nicht verfügbar” immer bedeuten, das ich jetzt machtlos bin?

Um wieder zum Anfang anzuknopfen: Man hatte natürlich gehofft, das Apple ein Flashplugin für das iPad anbietet bzw. es unterstützt. So wie es im Moment aber aussieht, ziehen sie – mehr oder weniger direkt – gegen Adobe in den Krieg und setzen dabei weiterhin komplett auf HTML5 bzw. auf native Apps. Da die Geräte – glücklicherweise – eine gewisse Machtposition im Sektor der online mobile devices besitzen, sind die Anbieter von Diensten auf Alternativlösungen angewiesen, falls sie die doch große (und vor allem: sehr wichtige) Zielgruppe nicht ausgrenzen wollen. Davon können im Ende alle profitieren, wenn die *** proprietäre� Flashgeschichte schwindet und stattdessen kleine, Client-performante und offenere Lösungen entstehen.

Übrigens: Auch Google setzt bekanntlich auf HTML5. Nicht nur Google Gears wurde entwicklungsplanmäßig in die Tonne gehauen, sondern auch Neuentwicklungen entstehen alle im Fokus der HTML(5)-Features. Das neue Google Voice (leider ein unschöner US-only-Kandidat) bietet VoIP. Kein Flash, pures HTML/CSS/Javascript.

Und mal ehrlich: Vermisst jemand wirklich das Flashplugin auf dem iPhone? Oder: Nutzt jemand wirklich Flash auf einem anderen Smartphone so intensiv, das es notwendig ist? Wenn ja, für was?

Update, 29. Januar 2010

Tatsächlich gibt es Ansätze, wie man Multitouch und Gesten in Flash umsetzen kann. Denn eine Maus und einen Mauszeiger findet man auf Multitouchgeräten nicht – um Gegenteil: man hat mehrere Pointer. Das bedeutet aber nicht, das vorhandene Flashanwendungen das alle nutzen würde, haha. Zu früh gefreut.

Okay, also über das Webinterface (Nervstufe 1). Im Safari wählte ich die Datei und schrieb den kleinen Satz und drückte “Senden” — und da fiel mir auf, das die Mail gar keinen Anhang hatte? Also, nochmal “Neue Mail”, Datei wählen.. und nix. Kein Anhang.

Okay, also über den Firefox (Nervstufe 2). Die letzten Schritte wiederholt, und er lud auch brav die Datei mit Fortschrittsbalken hoch, nur um mir dann bei gefühlten 99, 999999999999999% (will heißen: die letzten 5 % haben mindestens 10x so lange wie die vorherigen 95% gebraucht) mitzuteilen, dass das Archiv wegen einer ausführbaren Datei nicht akzeptiert wird. Was? Hä?

Okay, prüfen wir die verf… Dateien (Nervstufe 3). Nun habe ich jede Datei geprüft, aber leider außer gefährlichen PDFs, sensiblen PNGs und potenziell terroristischen JPGs nur eine wirklich – naja, *hüstel* – nennenswerte Datei in irgendeinem Unterordner finden können: dateiname.chm. Warum auch immer. Umbenannt, wieder das Spielchen von vorne, keine Veränderung, Archiv immer noch illegal. (Nervfaktor 4).

Schlussendlich habe ich danach das Archiv.zip in Archiv.zip.itsonlyafuckingzipfile umbenannt und hochgeladen (via Mail).. und alles war wunderbar.