Schon lange träumen Linux-Anwender von einem lizenzfreien Video-Codec. Mit VP8 erfüllen Google und On2 nun diesen Wunsch – allerdings gilt es kleine Abstriche zu machen.

Bei VP8 handelt es sich um eine Weiterentwicklung des von On2 entwickelten und ebenfalls frei verfügbaren VP3, der die Video-Basis für das freie Videoformat Ogg Theora stellte. Google hatte den Codec-Spezialisten Anfang 2010 übernommen und Mitte Mai auf seiner Entwicklerkonferenz Google I/O die Freigabe des lange in der Entwicklung befindlichen, deutlich verbesserten VP8 bekanntgegeben [1]. Im ebenfalls von Google freigegebenen WebM-Container, der auf dem offenen Containerformat Matroska basiert, soll VP8 zusammen mit Ogg Vorbis als Audiocodec Verbreitung im Web finden.

Google hat es geschafft, WebM in den HTML5-Video-Standards einzubringen – jeder Browser, der vollständig HTML5-kompatibel sein will, muss es also unterstützen. Kurz nach WebM stellte Google das ebenfalls freie WebP vor, ein neues Bildformat, das auf VP8-Technik basiert (siehe Kasten “WebP: Googles neues Bildformat”).

WebP: Googles neues Bildformat

“Wir möchten das Web schneller machen” – mit dieser Ankündigung stellte Google am 30. September 2010 das neue Bildformat WebP [7] (gesprochen “Weppy”) in Chromium-Blog [8] vor. Laut Google bestehen im Schnitt fast zwei Drittel des Datenvolumens einer Webseite aus Bildern, speziell bei schmalbandigen Verbindungen verzögere das die Anzeige. Abhilfe soll das neue Bildformat machen. Es nutzt RIFF als Container, das auch Metadaten von Bildern speichert. Als Kodierungsalgorithmen verwendet es Techniken, die für VP8 entwickelt wurden.

Das Lizenzmodell entspricht etwa dem von Adobes freiem DNG [9]. Es besagt, dass jeder WebP uneingeschränkt und zeitlich unbegrenzt verwenden darf, Google sich jedoch alle Rechte vorbehält. Da Google auch den Quellcode veröffentlicht, kann jeder Entwickler diesen für seine eigenen Produkte anpassen. Als Binary existiert derzeit lediglich eine native Linux-Version für 64-Bit-Systeme. Die Entwickler arbeiten bereits an einer Implementierung des Bildformats in die Browser-Engine Webkit, die unter anderem Google Chrome und Safari verwenden.

Mangels Bildbetrachtern, die das Format unterstützen, lässt sich dessen Qualität im Moment nur beurteilen, indem man die Bilder in ein anderes, verlustfreies Format wie TIFF oder PNG konvertiert. Diese Möglichkeit bietet das Kommandozeilenprogramm webpconv, das auch das Konvertieren ins WebP-Format übernimmt.

In der Praxis zeigt sich das Format von seiner besten Seite. Gegenüber JPEG fallen die Bilder bei gleicher Komprimierungsrate im Schnitt 50 Prozent kleiner aus, weisen aber dennoch wesentlich weniger Bildfehler auf. Die Klötzchenbildung als JPEG-typisches Kompressionsartefakt fehlt weitgehend, dafür stellt WebP Farbübergänge nicht so sauber dar (siehe Abbildung).

JPEG (oben) neigt stärker zu Artefakten, WebP (unten) stellt Farbübergänge nicht sauber dar (Kompressionsstufe jeweils 40).

Auch bei strukturierten Flächen wie Rasen oder Stoff verschluckt das neue Bildformat speziell bei höheren Kompressionsraten durchaus Details, die JPEG noch zeigt – allerdings zum Preis höherer anderweitiger Bildstörungen.

Soft- und Hardware

Als erster Browser unterstützte Google Chrome das WebM-Format, und auf der Google-I/O-Konferenz gaben Mozilla und Opera bekannt, dass ihre Browser den Codec ebenfalls bald nativ abspielen – Firefox ab Version 4, Opera ab 10.60. Nur Microsoft und Apple zieren sich noch, WebM-Unterstützung direkt in ihre Browser und Mediaplayer zu integrieren, obwohl es für ihre Media-Frameworks Windows Media und Quicktime bereits installierbare VP8-Codecs gibt. Adobe hat die Integration von VP8 in Flash angekündigt, ebenso will Google noch Ende 2010 Android mit WebM-Unterstützung versehen. Youtube hat schon lange begonnen, sämtliche HD-Videos auch als VP8 zu encoden – mit dem langfristigen Ziel, den gesamten Videopool auch als VP8 anzubieten.

Auf der Linux-Seite dauerte es nicht lange, bis alle nötigen Frameworks und Player VP8 und WebM unterstützten: Ffmpeg 0.6, Gstreamer (Gst-plugins-bad 0.10.19 für VP8, Gst-plugins-good 0.10.23 für WebM), VLC 1.1.1, Arista 0.9.5, Fluendo Moovida 2.0.0.10, Mplayer 1.0rc4, Transmageddon 0.16, MKVtoolnix 4.0.0 und Totem 2.30.2 verstehen sich ab den genannten Versionen alle auf das freie Videoformat. Inzwischen haben die Ffmpeg-Programmierer sogar einen eigenen, nativen Decoder namens Ffvp8 entwickelt und integriert, der effizienter arbeitet als Googles VP8-Bibliothek Libvpx.

AMD/ATI, ARM, Broadcom, Qualcomm und Texas Instruments haben bereits Hardware-Unterstützung für VP8 angekündigt. Sogar Intel will das Format in seinem Atom für Settop-Boxen unterstützen, falls es breitere Akzeptanz findet. Lediglich Nvidia sagte auf Anfrage, dass keine Pläne für VP8-Hardware-Unterstützung bestünden.

Patentfragen

Frei im Quellcode verfügbar bedeutet nicht notwendigerweise patentfrei: Gerade die Video-Codec-Entwicklung entpuppt sich immer wieder als Minenfeld aus Patenten.

Der x264-Entwickler Jason Garrett-Glaser, besser bekannt als Dark Shikari, ist maßgeblich für den Feature-Umfang, den hohen Optimierungsgrad und die Effizienz des freien H.264-Encoders verantwortlich. Er hat VP8 ausführlich unter die Lupe genommen und kommentiert Patent- und Implementierungsprobleme sowie Performance und Effizienz, alles in Relation zu H.264 [2]. Hinsichtlich der Patentfragen kommt Garrett-Glaser zu dem Schluss, VP8 sei H.264 viel zu ähnlich, als dass man Patentprobleme ausschließen könne.

Diese Aussage sorgte für viel Aufsehen und energischen Widerspruch [3]: Die in Garrett-Glasers Analyse getroffene Feststellung, VP8 arbeite ineffizienter als H.264 (etwa durch den Verzicht auf B-Frames), rühre eben genau daher, dass On2 bewusst entsprechende Patente umgehen wollte. Die Patentverletzungen, die der H.264-Entwickler bei VP8 sieht, scheinen sich hingegen hauptsächlich auf alte MPEG-1/2-Patente zu beziehen, die inzwischen ausgelaufen sind.

Natürlich kann man Patentklagen nie vollkommen ausschließen, aber On2 hat sich offensichtlich bemüht, VP8 so patentfrei wie möglich zu machen. Chris DiBona, Googles Open-Source-Chef und Organisator des beliebten Google Summer of Code, erklärte uns auf dem Linuxtag, die einzige Garantie, die Google den Anwendern diesbezüglich geben könne, sei die, niemals selbst Patentansprüche gegen VP8-Nutzer zu erheben.

Nachdem die Open Source Initiative den Status der ursprünglichen WebM/VP8-Lizenz als freie Lizenz anzweifelte, hat Google die seinerseits zusammen mit VP8 freigegebenen Patente vom Quellcode getrennt. Die VP8-Sourcen stellte es in der Folge unter eine Standard-BSD-Lizenz, die Patente unter einer eigene [4]. Damit haben WebM und VP8 nun den Segen der Free Software Foundation, welche die Lizenz als GPL-kompatibel ansieht [5].

WebM in der Praxis

Im Praxistest fällt als erstes auf, dass derzeit nur topaktuelle Software mit WebM klarkommt: In den Repositories älterer Systeme finden sich keine WebM-fähigen Anwendungen. Nur Ubuntu 10.10 bringt Versionen von VLC, Ffmpeg, Mplayer, Totem, Transmageddon, Arista und Gstreamer mit, die WebM beherrschen – oder das zumindest vorgeben. Der in Ubuntu 10.04 enthaltene VLC 1.1.0 soll laut Release-Notes WebM unterstützen, doch beim Abspielen zeigt sich nur eine Fehlermeldung (Abbildung 1).

Abbildung 1: Im Changelog von VLC 1.1.0 steht “Support for WebM decoding and encoding” – hätte man vor Release eventuell mal testen sollen.

Der Mplayer in Medibuntus Repos für “Lucid Lynx” stammt vom April 2009 – fast schon antik. Einen WebM-fähigen Gstreamer gibt es genausowenig wie Arista, nur Google Chrome 7 spielt die Dateien ab. Hier ist also viel Selbstkompilieren angesagt. Das WebM-fähige Ffmpeg 0.6, kurz nach Ubuntu 10.04 veröffentlicht, war der Wendepunkt, ab dem WebM-fähige Software breiteren Einzug in Linux hielt.

WebM selbst erstellt

Die einfachste Möglichkeit, WebM-Dateien selbst zu erstellen, bieten grafische Transcoding-Lösungen wie Arista (Abbildung 2). Das funktioniert für kleinere Videos recht gut; da jedoch keinerlei Einstellmöglichkeiten für Parameter existieren (noch nicht einmal für die Bitrate), fällt die Qualität bei HD-Videos sehr schlecht aus. Beim VLC-Stream-Export mit WebM-Profil kann man zwar die Bitrate wählen, dennoch bleibt die Qualität bei HD-Video weit hinter den Erwartungen zurück – darüberhinaus enkodiert VLC immer nur auf einem Kern, statt auf allen verfügbaren. Transmageddon soll zwar den WebM-Export beherrschen, im Test passiert allerdings nach einem Klick auf Start überhaupt nichts.

Abbildung 2: Arista erstellt mit einem Klick WebM-Dateien, erlaubt allerdings keinerlei Einstellungen.

Mit Ffmpeg klappt das Transcoding besser, hier lassen sich auch viele Parameter einstellen. Falls das von Ihnen verwendete Ffmpeg einen Codec aus patentrechtlichen Gründen nicht unterstützt, folgen Sie der Anleitung unter [6]: Sie lädt, kompiliert und installiert neben einem taufrischen Ffmpeg und x264 auch die neueste Libvpx, samt Unterstützung für alle nötigen Codecs. Zum Encoding einer WebM-Datei mit VP8-Video und OGG-Audio genügt dann schon das Kommando

$ ffmpeg -i Eingabedatei Output.webm

Besitzer eines Rechners mit Mehrkern-CPU sollten den Switch -threads Cores hinzufügen, wobei Cores der Anzahl der verfügbaren CPU-Kerne (virtuell oder real) entspricht. Mit -b Rate legen Sie die Bitrate fest, wobei 2M 2 Mbit/s entspricht, 1900K 1900 kbit/s. Doch die Grundeinstellungen liefern keine gute Qualität: An vielen Stellen bemerkt man immer wieder Ruckeln, sobald ein Keyframe kommt. Für deutlich bessere Qualität ohne Zuckelei bei kaum langsamerem Encoding sorgen einige von Google empfohlenen Parameter:

$ ffmpeg -i Eingabedatei -g 120 -level 216 -profile 0 -qmax 42 -qmin 10 -rc_buf_aggressivity 0.95 Output.webm

Auch 2-Pass-Encoding ist möglich: Mittels -pass 1 macht Ffmpeg einen schnellen ersten Durchgang, -pass 2 greift beim zweiten Durchlauf für das finale Encoding auf das erzeugte Logfile zu. Die Qualität verbessert allerdings nicht so deutlich wie bei x264 mit 2-Pass-Encoding oder dem Single-Pass-CRF-Modus (Constant Rate Factor).

Um nicht jedesmal alle Parameter eingeben zu müssen, empfiehlt es sich, ein Preset für die obigen Einstellungen unter /usr/local/share/ffmpeg/ anzulegen. Dazu geben Sie in einem Texteditor die Zeilen aus Listing 1 ein und speichern die Datei als libvpx-highq.ffpreset. Nun genügt der Aufruf

$ ffmpeg -i Eingabedatei -vcodec libvpx -vpre highq -b <Bitrate> -threads Cores Output.webm

um ein Encoding mit optimalen Voreinstellungen und bestmöglicher Ausnutzung der Hardware vorzunehmen.

g=120
level=216
profile=0
qmax=42
qmin=10
rc_buf_aggressivity=0.95

Qualität

Mit Test-Videoclips der Auflösungen 1080p und 720p zeigt sich im direkten Vergleich zu H.264 mit CABAC (Ffmpeg-Preset Libx264 slow) WebM qualitativ bei gleicher Bitrate unterlegen.

Dunkle Bereiche und sanfte Verläufe neigen schneller zur Blockbildung als bei H.264. Reines Rot, ein bekannter Problemkandidat bei MPEG und JPEG, zeigt unter VP8 deutlich stärkere Artefaktbildung als unter x264. Details gehen bei Reduktion der Bitrate schneller verloren, VP8 “vermatscht” das Bild mehr als H.264. Obendrein arbeitet der VP8-Encoder im qualitativ besseren Modus nur rund halb so schnell wie x264.

Beim Abspielen in Totem/Gstreamer hat WebM jedoch leicht die Nase vorn und erzeugt auf einem Core i7 870 mit 2,93 GHz nur 50 Prozent Last auf einem Kern, während die H.264-Version die CPU mit 57 Prozent beansprucht. Mit identischen Parametern, jedoch ohne CABAC, fällt die Qualität der x264-Kodierung immer noch etwas besser aus als bei VP8. Erst beim Verwenden des fast-Presets für Libx264 zeigt sich das Ergebnis zu Libvpx qualitativ ähnlich – allerdings dauert das Encoding dann auch nur halb so lang.

Dennoch liefert VP8 gute Qualität, die deutlich über der von Ogg Theora/VP3 liegt. Während Ogg Vorbis als Audio-Codec qualitativ bei identischer Bitrate auf Augenhöhe mit allen anderen unfreien Codecs wie MP3, WMA oder AAC liegt, kann der freie Videocodec VP8 nur mit H.264 Baseline Profile, DivX/Xvid oder WMV3/VC-1 konkurrieren. H.264 bleibt weiterhin ungeschlagener Qualitätskönig (Abbildung 3).

Abbildung 3: H.264, VP8, Xvid und Theora im Qualitätsvergleich bei 1900 kbit/s.

Der Verzicht auf patentierte Techniken trägt dazu sicherlich seinen Teil bei. Dass jedoch extrem viel vom Encoder abhängt, beweist das Beispiel Lame: Das schaffte es allein durch Encoder-Verbesserungen, das technisch eigentlich veraltete MP3 in Hörtests gleichauf mit moderneren und ausgefeilteren Konkurrenten wie AAC oder WMA9 zu bringen. Es steht zu hoffen, dass der VP8-Encoder schon bald auf ähnliche Weise nachlegt.