1247941931|%d.%m.%Y
Adobe wirds freuen: Flash bleibt wohl weiterhin das Maß aller Dinge für Multimedia im Web, und eingebunden wirds in HTML wahrscheinlich bis ins 22. Jahrhundert hinein mit der bekannten, bescheuerten Mixtur aus <object> und <embed>. Das bewährte, alte Netscape-<embed> wird nämlich neben dem guten, alten W3C-<object> offizieller Sprachbestandteil von HTML5. Aus der eleganteren weil plugin-freien Variante, Audio- und Video-Ressourcen direkt im Browser verfügbar zu machen, wird dagegen wohl nichts, denn die Browser-Anbieter können sich nicht einigen, welche Codec-Standards für die neuen HTML5-Elemente <audio> und <video> verwendet werden sollen.
In der entstehenden Spezifikation zu HTML5 steht derzeit folgende interne Bemerkung:
It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. This is an ongoing issue and this section will be updated once more information is available.
Die neuen HTML5-Elemente <audio> und <video> sollen das Einbinden von Podcasts und Videos endlich so einfach machen wie das Einbinden von Grafiken. Voraussetzung dafür ist jedoch, dass es Formate gibt, die alle Browser genauso einfach und selbstverständlich umsetzen wie die Grafikformate PNG, JPEG und GIF. Bei Audio- und Video-Formaten geht es dabei letztlich um die sogenannten Codecs, die festlegen, nach welchen Algorithmen die akkustischen und visuellen Signale digital gespeichert werden. Unglücklicherweise ist jedoch die Lage auf dem Markt der bekannten Audio- und Video-Codecs sehr verworren. So verworren, dass sich die Browser-Anbieter nicht darauf einigen können, welche Codecs für <audio> und <video> zum Einsatz kommen sollen.
Die Situation bei den Browser-Anbietern
Google hat im Chrome-Browser den Codec OGG Theora implementiert. OGG-Formate haben im Gegensatz zu den meisten anderen Codecs den Vorteil, patentfrei zu sein. Lizenz-Probleme wie vor Jahren beim GIF-Format werden dadurch vermieden. Allerdings sind die Bit-Raten, also die Anzahl zu übertragender Daten pro Spieldauersekunde, bei OOG Theora nach Ansicht von Google derzeit noch zu hoch. Deshalb kommt im Chrome-Browser zusätzlich noch das H.264-Verfahren zur Datenkompression zum Einsatz. Dadurch werden durchaus ordentliche Ergebnisse erzielt, wie Google in einem HTML5-Demo-Video auf YouTube zeigt. Leider sind jedoch Teile des H.264-Verfahrens von Drittanbietern patentiert. Google selbst hat mit den Patentinhabern entsprechende Nutzungsverträge. Die Rechtslage würde aber nicht erlauben, Chromium inklusive H.264-Kompression weiterhin als OpenSource zu vertreiben. Da die Lizenzform von Chromium bleiben soll wie sie ist, kommt H.264 für Google auf Dauer nicht in Frage.
Apple weigert sich, im Safari-Browser OGG Theora zu implementieren, da OGG nicht in die hauseigene Multimedia-Landschaft passt, die von Quicktime geprägt ist. Folglich unterstützt Safari nur Quicktime als direkt interpretierbares Multimedia-Format. Quicktime ist von Apple lizenziert. Andere Browser-Anbieter, die Quicktime direkt in ihre Produkte implementieren wollten, müssten Lizenzvereinbarungen mit Apple treffen. Angesichts der wirtschaftlichen Bedeutung des Browser-Markts wird Apple aber sicher keine Appel-und-Ei-Verträge mit Safari-Konkurrenten schließen.
Mozilla (Firefox) und Opera haben wie Google Probleme mit dem H.264-Verfahren. Beim Firefox-Browser ist die Problematik die gleiche wie bei Chromium, nämlich die eigene OpenSource-Lizenzform, deren Regelungen zum Weitervertrieb der Software unvereinbar ist mit den Lizenz-Regelungen von H.264. Opera hat zwar keine OpenSource-Lizenzform, scheut jedoch die Kosten der H.264-Lizenzierung.
Microsoft schweigt sich ganz aus zu den Problemen. Im Grunde hat man die Antwort ja auch schon vor vielen, vielen Jahren gegeben, als im Internet-Explorer 2.0! das direkte Einbinden von AVI-Videos implementiert wurde. Microsoft hat ähnlich wie Apple eine gewachsene hauseigene Multimedia-Architektur und wird deshalb kaum bereit sein, deren Bedeutung durch die Implementierung konkurrierender, fremdlizensierter Softwaremodule im Internet Explorer zu schmälern.
Konsequenzen für die HTML5-Implementierung
Ian Hickson, Herausgeber der HTML5-Spezifikation beim W3-Konsortium, hat in einem vielbeachteten Mailinglisten-Beitrag folgendes zu diesem Thema geschrieben:
After an inordinate amount of discussions, both in public and privately, on the situation regarding codecs for <video> and <audio> in HTML5, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship.
I have therefore removed the two subsections in the HTML5 spec in which codecs would have been required, and have instead left the matter undefined, as has in the past been done with other features like <img> and image formats, <embed> and plugin APIs, or Web fonts and font formats.
Eine sehr interessante Passage! Es soll also es keine verbindlichen Vorgaben zur Implementierung von <audio> und <video> geben. Genau darin liegt jedoch der Hund begraben. Das „Offenlassen“, das Ian Hickson anspricht, hat nämlich bei anderen HTML- und CSS-Sprachbestandteilen in der Vergangenheit immer wieder für chaotische Verhältnisse, Verrenkungen und Ignoranz bei Entwicklern gesorgt. So wurden gut gemeinte Elemente wie <embed> und <object> zu unbrauchbaren Hülsen, die sich nur dank proprietärer Anwendungen wie Flash überhaupt mit Leben füllten. Ganz ähnlich war es wie von Hickson angesprochen bei den Möglichkeiten, via CSS Schriftartendateien einzubinden.
Einer der wichtigsten Ansätze von HTML5 ist es, in jeder Hinsicht so eindeutige Vorgaben zu machen, dass die Rendering-Engines von Browsern HTML in Zukunft möglichst einheitlich verarbeiten. Aus diesem Grund ist man ja auch dazu übergegangen, HTML in Form von DOM-Strukturen statt in Form von Markup-Dokumenttyp-Definitionen zu spezifizieren. Eine unklare und alles offen lassende Regelung bei den Elementen <audio> und <video> passt einfach nicht in dieses Konzept. Sie produziert nur zwei weitere nutzlose Elemente zusätzlich zu <embed> und <object>. Konsequenter wäre es eigentlich, wenn man <audio> und <video> angesichts der Situation komplett wieder aus dem entstehenden Standard entfernt, solange es noch früh genug ist.
Wie gesagt, Adobe wirds freuen.
Das klingt missverständlich, als ob Quicktime ein Konkurrenz-Angebot von Ogg sei. Ogg Vorbis und Theora passen gar wunderbar, problemfrei und nahtlos in Quicktime, wenn man sich die entsprechenden Plugins installiert (Ich hab hier keinerlei Probleme mit Theora in <video>). Quicktime ist in der Hinsicht an Codecs ziemlich agnostisch; es ist nur ein Framework für Medien, kein Codec selber.
Apple will jedoch wirklich nicht Ogg unter die Default-Installation von Quicktime integrieren. Zwei Gründe sprechen aus Apples Sicht dagegen: Dass Theora bislang unbekannten Submarine-Patenten unterlegen sei und irgendein Wald- und Wiesen-Patenttroll-Klitsche dann verklagen könnte. Der Mangel einer Patentpoolgruppe wie die MPEG-LA wird hier von Apples Juristen als Liability empfunden. Der andere Grund ist, dass Hardwarebeschleunigung (z.B. mittels Codec-Chip) im Theora-Standard nicht enthalten sei; relevant bei kleinen Geräten wie z.B. dem iPhone. Sprich, Apple ist tatsächlich der Ogg-Bremser, die Argumente sind jedoch andere als die Konkurenz-Situation zu Quicktime.
Nebenbei gibt es ein sehr wichtiges Element, bei dem das Offenlassen des Medienformats keine großen Probleme gemacht hat: img. ;)
Hallo Tim,
Ist das wirklich nicht der Fall, aller Mac-Liebe zum Trotz? Sieht man mal von dem ganzen Codec-Background ab, gibt es Videos als .ogg-Dateien und .mov-Dateien, so wie es Videos auch als .mpg, als .avi, .wmv und was weiß ich noch gibt. Und letztlich geht es darum, ob HTML-Autoren künftig <video src="datei.ogg"> oder <video src="datei.mov"> oder <video src="datei.???"> notieren sollen. Als Autor ist man mit Werkzeugen wie avidemux flexibel. Aber man müsste halt wissen, was die Browser benötigen …
Ja, nur genau das Installieren von Plugins soll ja nicht mehr vorausgesetzt müssen. <audio> und <video> sollen ja im Gegensatz zu <embed> nicht generisch sein, sondern "unkompliziert".
Das halte ich ehrlich gesagt für ein vorgeschobenes Argument. Zumal andere Browser-Anbieter, die Theora einsetzen würden, offenbar keine solche problematischen Regelungen sehen.
Ist das denn Aufgabe von Dateiformaten? Doch eher eine Apple-spezifische Problematik, wo Hard- und Software aus einem Haus kommen.
viele Grüße
Stefan Münz
Es geht ja gar nicht um das ältere Mov-Containerformat. Apple puscht doch als Gegenpart zu Theora H.264 im MP4-Container. (Übrigens ist das auch deren präferiertes Format in anderen Bereichen)
In diesem Fall ging es übrigens um Quicktime-Plugins, nicht um Browser-Plugins. Aber ja, Plugin-Suche ist immer nervig.
Ich halte es nicht für unklug, bei den begrenzten Möglichkeiten von mobiler Hardware. Ich finde die Quelle derzeit nicht mehr, aber das war meines Wissens auch ein Grund, dass Nokia sich gegen Theora aussprach.
Hi Stefan!
Ja, die Situation ist ziemlich blöd. Jetzt habe ich gehofft dass das Web einen Schritt voran kommt im Bestreben, das Flash Plugin ins Nirvana zu schicken. Ein einheitlicher Codec für <audio> und <video> wäre hier sehr hilfreich gewesen. Aber vielleicht haben wir ja auch Glück, und mit der Zeit setzen sich - ähnlich dem <img>-Element - bestimmte Formate durch. Eventuell arbeiten die Mitarbeiter von Google selbst bereits an neuen offenen Codecs, um diese Situation zu entschärfen.
Meiner Meinung nach wäre es allerdings eine elegante Zwischenlösung, Plugins zu entwickeln, die viele Codecs unterstützen. Ein sehr vielversprechender Kandidat wäre der VideoLAN Client. Dieser bietet bereits heute alle Codecs die man sich wünschen würde. Natürlich können die Browser-Hersteller diesen nicht direkt einbinden - die Patentlage würde viele schlafende Anwälte wecken. Aber es spricht doch nichts dagegen, Schnittstellen für spezielle Plugins anzubieten, die dann die Browser mit <audio> und <video> befüllen können.
Vielleicht wird dann eine Zeit anbrechen, wo man meinen EMFF nicht mehr braucht.
Freundliche Grüße
Marc
Hallo Marc,
Wie du ja selber schreibst, würde es am Ende aber doch wieder auf eine Plugin-Lösung hinauslaufen. Und da komm mal gegen satte 95% Verbreitung des Flash-Player-Plugins an (weiß nicht, wie viel es genau sind, aber in dieser Größenordnung jedenfalls). Halte ich für unrealistisch.
So schnell wirst du den sicher nicht zu Grabe tragen können/müssen *g*
viele Grüße
Stefan Münz
Posting-Vorschau:
Vorschau schließen