Der x264-Entwickler Jason Garrett-Glaser, besser bekannt als Dark Shikari, hat VP8 unter die Lupe genommen und kommentiert Patent- und Implementierungsprobleme sowie Performance und Effizienz, alles in Relation zu H.264.

Jason Garrett-Glaser ist einer der Hauptverantwortlichen für die unglaubliche Effizienz des freien H.264-Encoders x264, der im Vergleich zu anderen, kommerziellen Encodern sowohl extrem schnell ist, als auch ungeschlagene Qualität liefert bei niedrigeren Bitraten. Dank seinen Assembler-Optimierungen, die immer die neuesten Befehlserweiterungen von Intel und AMD nutzen, ist x264 nun fast fünf mal schneller als mit dem reinen C-Code.

In seinem Blog hat sich Jason nun die Speztifikation von VP8 genauestens angesehen und gibt als Codec-Experte sein Urteil darüber ab. Der von der frisch adoptierten Google-Tochter On2 entwickelte, gerade als Opensource freigegebene Codec kommt dabei nicht gut weg.

Beim wichtigsten Thema Patente kommt Jason zu dem Urteil, dass VP8 viel zu ähnlich ist zu H.264, als dass Patentprobleme ausgeschlossen werden könnten — selbst Microsofts VC-1, so Shikari, sei viel unähnlicher zu H.264 als VP8. Einige der implementierten Techniken sind nahezu identisch zu den patentierten Techniken von H.264, wohingegen On2 andere, wichtige (wie etwa B-Frames, die etwa 10-20% bessere Qualität bringen) nicht implementiert hat — wohl aus Angst vor Patentklagen.

Qualität

Auf der Qualitäts-Seite sieht Dark Shikari VP8 als insgesamt unterlegen zu H.264 — obwohl H.264 viele Jahre älter ist. Seit der H.264-Spezifikation entwickelte neue Ansätze und Verbesserungen wurden größtenteils nicht umgesetzt. Das Fehlen einiger wichtiger Features wie B-Frames, adaptiver Quantisierung oder eines adaptiven Loop-Filters (genaue Erklärungen im Blogeintrag) wirkt sich negativ auf die Qualität aus. Jason schätzt die Qualität in etwa vergleichbar zu VC-1 oder H.264 Baseline-Profile ein — das Niveau des besseren Main- und High-Profile erreicht VP8 nicht. In seinen PSNR-Vergleichen, welche die visuelle Qualität eines encodeten Videostreams mit den originalen Rohdaten vergleicht, ist H.264 High Profile 28% besser als VP8 bei gleicher Bitrate, während VP8 8,5% besser ist als H.264 Baseline.

Sowohl On2s VP8-Encoder als auch der -Decoder sind obendrein deutlich langsamer als x264 beziehungsweise libavc in ffmpeg. Und das obwohl sie doch relativ effizient umgesetzt und programmiert wurden — mit Ausnahme der Assembler-Optimierungen, denen Garrett-Glaser kein gutes Zeugnis ausstellt. Beim Encoder sieht Shikari noch mögliches Optimierungspotential, insbesondere in der psychovisuellen Optimierung, beim Decoder gibt es ihm zufolge nicht mehr viele mögliche Verbesserungen.

Spezifizierungsprobleme

Auch für Hardware-Implementierungen sieht Jason einige Probleme kommen, da sich einige der integrierten Techniken nicht für Hardware-Decoding per DSP eignen. Auch Realtime-Streaming, wo es auf besonders niedrige Latenz ankommt, ist mit VP8 aufgrund einiger Teilaspekte wenn überhaupt nur sehr schwer möglich. Anstoß nimmt der Codec-Spezialist auch daran, dass die Spezifikation letztendlich nur der spärlich dokumentierte C-Quelltext von On2s En- und Decoder ist, und dass der Decoder in weiten Teilen identisch ist mit dem Encoder, da er aus diesem abgeleitet wurde. Dies ist problematisch, weil so Code-Fehler unbemerkt weitervererbt werden, die fehlerhaftes Verhalten zurfolge haben — was später nicht mehr behoben werden kann, wenn die Videostreams einmal in Umlauf sind. Der sinnvollere Ansatz ist eine unabhängige Implementierung zweier Parteien aufgrund einer detaillierten Spezifikation. Und seine Ängste sind berechtigt: Ein anderer Entwickler berichtet, dass sein VP8-Decoder-Bugfix für Motion-Vektor-Clamping abgewiesen wurde, da er dazu führen würde, dass die von Google schon encodeten bestehenden Dateien fehlerhaft aussehen würden. “This is just like Internet Explorer 6 all over again, bugs in the Software become part of the spec” kommentiert Jason.

Shikari hätte sich gewünscht, dass Google den Sourcecode zuerst als “draft” zur Verfügung gestellt hätte, um Feedback der Entwicklergemeinde abzuwarten und den Codec vor der Finalisierung noch zu verbessern.

Lobende Worte

Positiv findet der x264-Entwickler, dass Google auf OGG als Audiocodec und das offene und streamingfähige Matroska als Containerformat setzt — obwohl die Umbenennung als “WebM” Stirnrunzeln hervorruft. Auch die bessere Spezifikation und Implementierung im Vergleich zu VP3, was damals als Basis für Ogg Theora diente und was den Entwicklern viel Kopfzerbrechen bereitet hat, wird gelobt, ebenso wie die Code-Qualität und Optimierung. VP8 ist qualitativ ein großer Schritt vorwärts von VP3/Theora, dem Damokles-Schwert drohender Patentklagen sollte sich Google jedoch dringend annehmen.