Kein Audio, kein Video

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.

Kommentare

Neuen Kommentar hinzufügen
oder Anmelden als Wikidot User
(wird nicht veröffentlicht)
- +
Sofern nicht anders angegeben, steht der Inhalt dieser Seite unter Lizenz Creative Commons Attribution-ShareAlike 3.0 License