Libvpx 1.8 Released With VP9 Encode Performance Improvements

[phoronix]

Phoronix: Libvpx 1.8 Released With VP9 Encode Performance Improvements

It's been just over a year since the debut of libvpx 1.7 while today a major new release is available for this library providing VP8/VP9 video encode/decode capabilities...

http://www.phoronix.com/scan.php?page=news_item&px=Libvpx-1.8-Released

[jacob]

I'm looking forward to a Handbrake release that takes advantage of this.

[veikk0]

I'd recommend anyone doing VP9 encoding to try out two-pass constant quality encoding if they haven't already. I had heard in various places that you shouldn't do 1-pass with libvpx since some quality features (to my knowledge -auto-alt-ref but there may be others) are only enabled in 2-pass mode, but I had always assumed that two-pass only means targeting a certain bitrate. Turns out this is not the case with libvpx and there's actually a two-pass CRF mode, but it's really mentioned anywhere.

To do it you just do a regular first pass like so: ffmpeg -i input.mp4 -c:v libvpx-vp9 -an -pass 1 -row-mt 1 -f webm -y /dev/null

The resulting log file is actually re-usable for both average bitrate and CRF encodes and even for different resolutions (useful for doing multi-resolution encodes like streaming sites do), though the latter does reduce quality slightly. Anyway, then you just run the second pass as CRF:

ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 0 -crf 30 -speed 2 -pass 2 -row-mt 1 output.webm

The quality is noticeably better than doing a 1-pass CRF of similar file size and well worth doing the first pass IMO. This 2-pass CRF does result in a larger file size than 1-pass but you can fix that by incrementing your normal 1-pass CRF by one. And you can increase your CRF even a bit further to retain similar quality to your old 1-pass setup.

I've also found -speed 2 to be the sweet spot setting, it pretty much doubles the encoding speed over the default value of 1 and doesn't dramatically impact quality.

[uid313]

I would love to see VP9 and AV1 decoders written in Rust.

[quikee]

i would love to see vp9 and av1 decoders written in rust.

3...2...1... Start!

[Brisse]

I've also found -speed 2 to be the sweet spot setting, it pretty much doubles the encoding speed over the default value of 1 and doesn't dramatically impact quality.

Agree. I always use -speed 2.

[Gusar]

I would love to see VP9 and AV1 decoders written in Rust.

Any software decoder worth anything will have all hotpaths written in assembly. Whatever the rest is written in, is practically inconsequential. This is even more true for encoders. There is a rust AV1 encoder, rav1e, but once it reaches usable state (both in terms of quality and encoding speed), you'll be running mostly assembly code anyway.

[wswartzendruber]

I would love to see VP9 and AV1 decoders written in Rust.

Why? dav1d is written in C and seems to be incredible.

[brad0]

I would love to see VP9 and AV1 decoders written in Rust.

Rust is the new Java. What a joke.

[Guest]

Rust is the new Java. What a joke.

There are languages that fit this analogy WAY better, Go (and D) are the new Java.