The Great UHD Codec Debate: Google's VP9 Vs. HEVC/H.265
So despite the results shown in Table 1, it appears that if and when MainConcept implements dual-pass encoding, overall quality should be very close to x265. So let’s move to the next factor, encoding time.
Encoding Time
To test encoding time, I encoded all clips on my 12/24-core Z800 workstation configured with two 3.33 GHz X5680 Intel Xeon CPUs and Windows 7 running on 24GB of RAM. I encoded all three resolutions of the New Test clip, which is 1 minute, 36 seconds in length, with X.265, MainConcept, and VP9.
To test x265, I used the command script used by MulticoreWare, which used the Slower x265 preset. To put this in perspective, in tests performed for a how-to article on encoding HEVC in the Streaming Media Sourcebook, I ran some comparison encodes between the Slower preset and Placebo, the highest-quality preset. Though Placebo took about 73 percent longer than Slower, the quality was only 2.44 percent higher, so we didn’t leave a lot of quality on the table using Slower.
With MainConcept, I used 27 for the P/Q value, which controls the quality/encoding time trade-off. According to tests performed for the aforementioned article, encoding at the highest setting, 30, would have taken 230 percent longer and only would have delivered an extra 1.39 percent improvement in quality.
With VP9, I encoded using presets supplied by Google, which used the Good preset and a speed of 1, which is designed to supply a good balance between encoding quality and speed. I also enabled multiple columns and multiple threads to use more of the cores on my HP Z800. After encoding, I confirmed that the quality of both the x.265 files and VP9 files were consistent with what I had been provided. The results can be found in Table 2, with all times shown as minutes:seconds.
Times with the green background are the fastest, and as you can see, VP9 won two of three trials, despite using two passes, while MainConcept only used one. Obviously, when it comes to encoding, time is money. It looks like VP9 will be the cheapest to encode of all three, particularly once MainConcept implements two-pass encoding.
Playback CPU
The third leg of the performance triple crown is the CPU required to play back the streams. Obviously, lower CPU requirements translate to greater reach among older and less powerful computers, along with reduced battery consumption. To measure this, I played the video on the noted computers with Performance Monitor (Windows) or Activity Monitor (Mac) open, while recording the CPU utilized during playback for the first 60 seconds of playback. Since there was no single player that played all videos on the Mac and Windows platforms, I used a variety of players.
Let’s start with the Mac playback results shown in Table 3, with the best results highlighted in green. Here, I tested on a 3.06GHz Core 2 Duo MacBook Pro running OS 10.6.2 on 8GB RAM, playing back VP9 in Chrome and HEVC in the DivX player. As you can see, VP9 required slightly lower CPU horsepower than HEVC with the 1280x800 file and was able to play the 1920x1080 VP9 file, while the 1920x1080 HEVC file stopped playing after a few moments. On this relatively old MacBook Pro, VP9 is more playback-friendly.
Next stop were tests on my venerable Dell Precision 390 workstation, which runs a 2.93GHz Core 2 Extreme CPU with Windows XP and 3GB of RAM. On this computer I tested two players for both technologies, just to learn if there would be substantial differences between them. I show the results in Table 4, with the best results highlighted in green.
Starting with VP9 on the left, Firefox was more efficient than Chome at both resolutions. With HEVC, DivX was far and away more efficient than VLC Player. If you average playback of the two codecs over the two videos files and players, HEVC was slightly more efficient; that’s the 49 number in green compared to VP9’s 54.
The Mac is from around 2009, while the Dell is from 2007, so both computers are long in the tooth. I ran the last series of tests on a much more recent HP Elitebook 8760W notebook with a 2.3GHz i7 CPU running Windows 7 with 16GB of RAM. (See Table 5 for results.) With VP9, the situation reversed and Chrome was slightly more efficient than Firefox. For HEVC, the DivX Player was slightly more efficient than Vanguard Video’s Visual Comparison Tool (shown in Figure 1) playing both files, though to be fair, the Vanguard tool is an analysis tool, not a highly optimized player.
Overall, VP9 was slightly more efficient, though the results are very positive for both UHD codecs playing on a high-performance, but reasonable platform. On the serious Mac and Windows workstations I use for encoding, the required CPU horsepower would be negligible.
The conclusion: If you were hoping that the UHD debate would be decided by a distinct qualitative or performance advantage one way or the other, you’re out of luck. From a quality perspective, the two codecs are very close, as they are in playback CPU, though VP9 does seem to have clear advantage in encoding efficiency. Overall, as with H.264 and VP8, it appears that the winner or loser between HEVC and VP9 will be selected by the politics of the situation, not based upon pure codec quality and performance.
This article appears in the April 2015 issue of Streaming Media as "The Great UHD Codec Debate."
Related Articles
VP9 is the open-source codec from Google, and provides a royalty-free alternative to HEVC. It's more efficient than H.264, and while it's less efficient than HEVC, it compares well on quality.
26 May 2016
For compressionists who want to see the image quality differences a tool measures, SSIMWave can feel incomplete. An upcoming update may change that.
13 Oct 2015
While it's fun to be on the cutting-edge of new video codecs and formats, H.264 should be every publishers' primary focus for the time being.
04 Jun 2015
Why did Google purchase On2 Technologies back in 2010? Because encoding and streaming VP9 video is saving it tens of millions each year.
29 Apr 2015
Why would set-top box makers bother supporting UHD video when home bandwidth connections aren't nearly robust enough to carry it?
24 Apr 2015
Last week, HEVC Advance announced it is forming a new patent pool in addition to the one offered by MPEG LA. While the new group—which will likely include Dolby, GE, Mitsubishi Electric, Philips, and Technicolor—did not announce licensing terms, past precedent indicates that the royalties won't likely be onerous for most encoding and decoding vendors, though how it will affect content publishers is less clear.
01 Apr 2015
H.264 still accounts for most video encoding today, but HEVC/H.265 and VP9 are beginning to make noise. What will 2015 bring?
19 Mar 2015
Companies and Suppliers Mentioned