VP8 vs. VP9 im Vergleich

VP8 ist Googles Antwort auf H.264. Google hat den Codec von On2 gekauft und dann als Open Source veröffentlicht, vorrangig um einen lizenzkostenfreien Videocodec für das eigene WebM Format anbieten zu können, das einfach per Video-Tag in HTML5 eingebunden werden kann. Aktuell spielen Firefox, Opera, Chrome und Chromium sowie deren Mobile-Pendants Videos im WebM Format (VP8 & Vorbis) nativ ab.

VP9 ist nun der daraus entstehende Nachfolger, der sich aktuell noch in der Entwicklung befindet. Hier nun werde ich testen, in wie weit er eine Verbesserung gegenüber VP8 darstellt, da VP9 konkurrenzfähig zu H.265 werden soll, wo die Entwicklung derzeit auch noch in vollem Gange ist, gefühlt aber etwas schneller voranschreitet.

VP10 soll den Nachfolger von VP9 darstellen. Google kündigte VP10 im September 2014 an. Seit August 2015 wird auch schon Code für VP10 veröffentlicht, aber noch nicht in den Releases der libvpx integriert. Daher wird VP10 an dieser Stelle nicht getestet.

Testvorbereitungen

Für den Test nutze ich die aktuellste Release-Version der libvpx: 1.5.0. ffmpeg liegt in Version 2.8.3 vor.

Die verwendete Hardware ist mein Root-Server bei Hetzner, ein Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (Skylake) und 32 GB DDR4 RAM. Als Betriebssystem läuft dort Gentoo Linux*, komplett mit GCC 5.3.0* compiliert.

Als Video-Material nutze ich einfach die 1080p Einzelframe-PNGs von [Big Buck Bunny](http://www.bigbuckbunny.org). Außerdem beschränke ich das Encoding auf die ersten 60 Sekunden des Films. Das reicht aus, um repräsentative Werte zu erhalten. Angemerkt sei aber, dass gerade die ersten 40 Sekunden von Big Buck Bunny schwer zu kodieren sind, da braucht der Encoder länger als beim Rest des Films. Das geht x264 dort aber genauso, ist also kein Defekt des Encoders sondern einfach nur die Komplexität des Films an der Stelle.

Da ein CRF- oder CQ-Encoding keinen qualitativen Unterschied machen würde, lege ich für das Encoding eine fixe Bitrate von 1000 kbps fest. Die Bitrate setze ich absichtlich so niedrig an, um zu sehen, welcher der beiden Codecs weniger Artefakte bildet und wie genau sie die feste Bitrate einhalten.

Encoding

So, nun geht's an das Encoden des Films. Ich lasse jeden Codec in 3 Schritten durchlaufen, einmal mit nur 1 Thread, dann nochmal mit 2 und 4 Threads. Also nun folgende Befehle, die Ergebnisse fasse ich final in einer Tabelle zusammen.

Um noch bessere Qualität bzw. Kompression zu erreichen, kann man den Parameter "-quality best" noch hinzufügen, jedoch ist VP9 dann soo langsam, dass sich das glaub ich niemand mehr antun mag. VP8 hat dabei noch erträgliche Geschwindigkeit und es lohnt sich dort auch, den Parameter zu setzen, wenn man nicht gerade unter Zeitdruck steht, da man dadurch bei CRF- und CQ-Encoding die finale Dateigröße schon noch um ein paar Prozent verringern kann.

Bei mehr als 4 Threads steigert sich die Performance nicht mehr, weshalb ich auch nur maximal 4 Threads teste.

# VP8 - 1 Thread ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -b:v 1000k -c:v libvpx -threads 1 8.1.webm # VP8 - 2 Threads ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -b:v 1000k -c:v libvpx -threads 2 8.2.webm # VP8 - 3 Threads ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -b:v 1000k -c:v libvpx -threads 4 8.4.webm # VP8 best - 1 Thread ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -quality-best -b:v 1000k -c:v libvpx -threads 1 8b.1.webm # VP8 best - 2 Threads ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -quality-best -b:v 1000k -c:v libvpx -threads 2 8b.2.webm # VP8 best - 4 Threads ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -quality-best -b:v 1000k -c:v libvpx -threads 4 8b.4.webm # VP9 - 1 Thread ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -b:v 1000k -c:v libvpx-vp9 -threads 1 9.1.webm # VP9 - 2 Threads ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -b:v 1000k -c:v libvpx-vp9 -threads 2 9.2.webm # VP9 - 4 Threads ffmpeg -y -r 24 -i frames/big_buck_bunny_%05d.png -to 60 -pix_fmt yuv420p -b:v 1000k -c:v libvpx-vp9 -threads 4 9.4.webm

Ergebnis

Ich lasse hier in der rechten Spalte auch mal die Werte meines Tests vom August 2014 mit Version *1.3.0* stehen, zum Vergleich. Angemerkt sei hier, dass VP9 bei Version 1.3.0 noch kein Multithreading genutzt hatte.

CodecThreadsBitrate 1.5.0Speed 1.5.0Bitrate 1.3.0Speed 1.3.0
VP81978.7 kbps4.1 fps979.5 kbps2.9 fps
VP82989.1 kbps6.9 fps990.2 kbps5.1 fps
VP841001.0 kbps11 fps1003.9 kbps7.0 fps
VP8 best1979.7 kbps2.2 fps980.3 kbps1.1 fps
VP8 best21000.6 kbps4.8 fps1004.8 kbps2.6 fps
VP8 best41011.7 kbps6.2 fps1029.2 kbps4.0 fps
VP91841.5 kbps2.7 fps966.6 kbps0.7 fps
VP92841.5 kbps4.4 fps--
VP94841.5 kbps5.8 fps--

Geschwindigkeit

Wie man sehr schön sieht, hat sich die Encodiergeschwindigkeit etwas gesteigert, wobei man natürlich beachten muss, dass ich den Test im August 2014 mit Version 1.3.0 noch auf anderer Hardware durchgeführt habe. Aus dem i7 3. Generation ist nun ein i7 6. Generation geworden, statt 16 GB DDR3 RAM sind es nun 32 GB DDR4 RAM. Aber in anderen Bereichen habe ich mit der neuen Hardware ca. 10% mehr Leistung als mit der alten, somit hätte der Test auf der alten Hardware trotzdem eine Steigerung der Encodiergeschwindigkeit gezeigt. Ich hatte vor dem Wechsel auf die neue Hardware auch schon libvpx 1.5.0 im Einsatz und schnellere Werte gemessen.

Leider ist die Geschwindigkeit noch immer weit hinter x264, zumal x264 auch problemlos mehr als 4 Kerne voll nutzen kann.

Bitrate

Komischerweise nutzt VP9 nicht die volle Bitrate aus, sondern verschenkt knapp 160 kbps, womit sich die Bildqualität vermutlich noch ein kleines bisschen verbessern ließe. VP8 hingegen kommt sehr gut an den eingestellten Wert heran. VP9 hat dabei aber unabhängig von der Anzahl der Threads immer die gleiche Bitrate erzeugt.

Bildqualität

Ich habe nun 3 Stellen in dem Film herausgepickt und jeweils 1 Frame aus den einzelnen Encodes gezogen. Ich werde nun nicht alle hier zeigen, da die VP8 Encodes sich nur minimal in der Bildqualität unterscheiden. Ich vergleiche hier nun direkt VP9 sowie VP8 best mit 1 Thread an. Links ist immer VP9, rechts VP8. Erste Reihe das Gesamtbild, zweite Reihe dann ein Bildausschnitt, wo die Unterschiede am deutlichsten werden.

Position 00:15

Position 00:30

Position 00:55

Auswertung

Wie man ja auf so ziemlich allen Frames erkennt, schafft VP9 es tatsächlich, z.B. die Details des Grases wesentlich besser zu erhalten und wirkt weniger matschig. Die Probleme von *1.3.0* bei Position 00:55 - die schnelle Bewegung des Hasen - scheint VP9 überwunden zu haben. Ebenso ist die Qualität bei VP9 im Vergleich zur alten Version 1.3.0 schon wesentlich besser geworden, trotz dass VP9 ja nun nicht mal die vollen 1000 kbps genutzt hat.

Zur Erinnerung: Version 1.3.0 erzeugte an der dortigen Stelle bei VP9 noch ziemlichen Pixelbrei:

Alles in allem ist VP9 schon auf einem guten Weg, jedoch sollte die Geschwindigkeit beim Encoding noch erheblich gesteigert werden, damit der Codec auch attraktiver wird. Immerhin spielt ja auch fast jeder Browser mittlerweile H.264 ab.

Artikelversionen