[TD-Linux]

It is currently quite a bit slower, but the goal is to make a codec fast enough for real time communication use.

VP9 is still about 9x slower than x264, but yields the same quality at half the bitrate. You can set VP9 to run a lot faster, but you'll lose some of the bitrate advantages. Still, VP9 is practical for a lot of applications, such as Youtube.

[mappu]

VP9 producing the same quality as x264 at half the bitrate is hard to believe. Do you have a citation? Which `--preset` for x264 are you basing this on?

[TD-Linux]

It's based on --best for VP9 1.4.0 and placebo for x264. Generally improvement tends to be from 30-50%, based on the quality target and content (the lower the bitrate, the greater the improvement). I have objective metrics which test this at http://arewecompressedyet.com/.

If you're more of a visual person, you can take a look at some images here, compressed to 60KB: https://people.xiph.org/~tdaede/pcs2015_vp9_vs_x264/0.25/

Certainly libvpx still has a lot of optimization and tuning work left to do. But there's only so much x264 can do with a 15 year old bitstream format.

[aw3c2]

Those example images are of really low quality video. Usually people who care about image quality do not care about that. Can you show some ~720p 5mb/s x264 versus 3-4mb/s VP9 samples?

[indolering]

Low resolution samples are the norm, I think it's because low resolution makes it so you can see how the compression algorithm works. If you a high resolution comparison, you would need to zoom in to see the difference anyway. There are, of course, compression artifacts that are readily apparent even in high-resolution (chain link fences, transparent wipes, etc) but I suspect that they are in the minority.

[bitmapbrother]

VP9 being 9x slower than x264 is hard to believe. Do you have a citation?

[mappu]

"VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. ... libvpx multithreading [encoding] performance is deplorable. It gains virtually nothing."[1]

1. https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes... n.b. x264 comparisons were taken with `--preset veryslow` which understates x264's potential performance by an order of magnitude. From the same link: "it can be fast, and it can beat x264, but it can’t do both at the same time."

[TD-Linux]

This is old. libvpx 1.4.0 is a lot faster now and has multithreading. On my i7-4900MQ laptop, I get about 3fps encoding 1080p content. Still very slow, but 24 minutes for a 3 minute clip, not days.

[Sir_Cmpwn]

I can anecdotally agree with him. I ran a service that did a lot of media encoding and VP9 is very, very slow to encode.

[DarkLinkXXXX]

Could that be due to lack of hardware support?

[TD-Linux]

No, generally encoding is done in software. It's just because VP9 is a much more complex format with many more different coding possibilities to search. It also hasn't been around as long as x264 to be hyper-optimized.

[astrange]

There are probably some issues with missing SIMD, but no further hardware support would be helpful.

It's purely an implementation issue - you don't get software as good as x264 just by paying for it.

[mappu]

Comparing x264 to hardware-accelerated encoders (QuickSync, NVENC, VCE), the speed/quality/bitrate tradeoff is massively in favour of the cpu-only x264. So i think hardware encoding could help VP9, but it's not a magic bullet (unless your CPU is busy with other work simultaneously).