Wow, my VP9 vs H.264 takeaways are:<p>- for encoding: libvpx always matches or surpasses the quality of x264 (at a given bitrate or at a given CPU budget), because the red line (libvpx) is always on or above the blue line (x264) here: <a href="https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-encoding-speed-1024x752.png" rel="nofollow">https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-...</a> (Except there is no libvpx data for CPU budget under ~0.2 SPF —which is a bit annoying, I know for one I do most of my encodings spending around 0.05-0.15 seconds per frame.)<p>- for single-threaded decoding: ffvp9 is faster than ffh264<p>- for multi-threaded decoding: ffvp9 is a bit slower than ffh264<p>On top of that, the VP9 implementations are bound to become faster (whereas not much more improvement can be made to already-mature H.264 implementations), so VP9 is bound to become even more preferable over H.264 over time.<p>I think the author's first concluding bullet point ("next-gen codecs provide 50% bitrate improvements over x264, but are 10-20x as slow") is poorly worded. Sure, you can make the next-gen codecs ultra slow by using the highest quality settings, but for libvpx you should choose less agressive settings, and you will still beat the quality of x264 at the same CPU cost.<p>Edit: in addition, these benchmarks show that as of today out of all these implementations, VP9 even matches or beats HEVC on all aspects (encoding at a given bitrate, encoding at a given CPU budget, single- and multi-threaded decoding). But I expect this to change as HEVC implementations are all quite still immature.
The worrying part is "x265 is still too slow to be useful in most practical scenarios" and "if your CPU usage target for x264 is anything faster than veryslow, you basically want to keep using x264, since at that same CPU usage target, x265 will give worse quality for the same bitrate than x264."<p>That can mean that there's a real danger that we'll get a lot of worse content in the future, as those who encode may go to use a bigger-number codec because it's assumed to be better (hey, it's newer!) Most of people never encode with different codecs every material just to compare the actual quality.
Another HEVC encoder comparison (which also includes x264 and VP9) is due to be released in a couple of days:<p><a href="http://compression.ru/video/codec_comparison/call_for_codecs_15.html" rel="nofollow">http://compression.ru/video/codec_comparison/call_for_codecs...</a><p>One of the results that's already leaked shows VP9 ahead of all the HEVC encoders except for x265, which it trails by a couple of percentage points.
Encoding speed is a real concern for some applications.<p>Think about Chromoting (Chrome Remote Desktop). They send VP9 video. If they cannot encode it at 60Hz (15ms per frame), it will look choppy.<p>(I quickly looked into it yesterday: <a href="https://twitter.com/espadrine/status/648158704420941825" rel="nofollow">https://twitter.com/espadrine/status/648158704420941825</a>)
It's good to see that libvpx and x265 are moving forward.<p>However, not mentioned is that a higher bitrate doesn't necessarily correlate with higher perceptual quality.<p>Additionally, part of H.264's appeal is its widespread hardware support, which enables features like smartphones with 4K video recording.