VP9 Codec: Google’s Open-Source Technology Explained
This article provides a quick overview of the VP9 codec: what it is, how it performs, what it costs, and what it’s good for. We’ll conclude with a section on what you need to know to effectively deploy the VP9 codec using the Wowza Streaming Engine software.
What Is the VP9 Codec?
VP9 is a codec from Google that was developed from technology acquired when Google purchased On2 Technologies in February 2010 for an estimated $124.6 million. By way of background, On2 was the developer of the VPx line of codecs, including VP6, which was the predominant codec used in Adobe Flash until Adobe added support for H.264 to Flash in August 2007.
In May 2010, Google open-sourced VP8, as well as the Matroska-based WebM format (which works with the VP8 and VP9 video codecs, as well as the Vorbis and Opus audio codecs). Though Google asserted that VP8 was royalty-free, in February 2011, patent pool administrator MPEG LA announced a call for patents essential to the VP8 codec, the first step in the formation of a patent pool. Twelve parties responded but no pool was ever formed. In March 2013, Google licensed technology from MPEG LA that “may” be essential to VP8 and the next-generation VP9, though terms were never disclosed.
The development of VP9 began in late 2011 and VP9 was released in June 2013. VP9 is the last VP-designated codec as Google contributed all codec technology acquired from On2 and developed after the acquisition to the Alliance for Open Media. Like VP8, Google launched VP9 as open source. Also, like VP8, VP9’s open-source status has been challenged by a patent pool, discussed in more detail below.
In terms of usage, by far the largest distributor of VP9-encoded content was YouTube, though YouTube still encodes the vast bulk of its files with H.264. In 2016, Netflix announced that it was using VP9 for video downloads, while JW Player distributes on-demand video in its online video platform using H.264 and VP9.
As with all the codecs discussed in this series, VP9 is a specification that different developers can use to create their own implementations of that specification. The most widely known VP9 codec implementation is libvpx-vp9, which was developed by Google and is available as a standalone encoder or as a codec with FFmpeg. There are also VP9 codecs offered by Intel (SVT-VP9) and Two Orioles (Eve-VP9).
Compatibility: VP9 vs. H.264, HEVC, and AV1
| Codec Compatibility | Browser | Mobile | Smart TV/OTT |
| H.264 | Virtually all | All | All |
| VP9 | Virtually all | Android, iOS | Most |
| HEVC | Very little | Android, iOS | All |
| AV1 | Edge, Firefox, Chrome, Opera | Android | Nascent |
The website CanIUse lists VP9 browser compatibility for both desktop and mobile at 96.26%, which trails H.264 slightly, but is much greater than HEVC’s 18.08%, and AV1’s 74.25. On Android and iOS, the Chrome browser can play VP9, as can Safari with iOS 14 and later. Google has assembled an impressive list of devices with VP9 hardware support here, which includes TVs from Samsung, Sony, Sharp, LG, HiSense, Philips, and Westinghouse, as well as a Roku set-top box, and Nvidia game console. While coverage doesn’t appear to be as extensive as HEVC, the lure of 4K YouTube playback has attracted a lot of hardware support. This compatibility is one of VP9’s greatest strengths.
Performance
When gauging codec performance, you consider two aspects: (1) encoding complexity or speed, and (2) encoding quality. With most codecs, including the four discussed in this series, there’s an inverse relationship between the two. That is, the better the encoding quality the longer it takes to encode, which translates to higher encoding and transcoding costs. Since no codec can completely replace H.264 at this point, these encoding or transcoding costs are additive to existing H.264 encoding-related costs.
| Performance Compared to H.264 | Encoding Complexity (Speed) | Encoding Quality |
| H.264 | Baseline | Baseline |
| VP9 | 2–15x | ~35% |
| HEVC | 2–15x | ~35% |
| AV1 | 15–30x | ~50% |
When analyzing codec performance, remember that there are multiple VP9 implementations, each with their own performance characteristics. Most VP9 implementations also have presets that let you tradeoff encoding time for performance. With libvpx-vp9, for example, a speed setting of 4 encodes in about 16% of the time of speed 0, but delivers about 3.5% lower quality, which doesn’t sound like a lot, but is when comparing codecs and codec implementations. Of course, HEVC and AV1 also have multiple implementations with multiple presets, which complicates codec comparisons and is why the encoding speed column in table 2 shows such an extensive range.
When considering encoding quality, note that the figure represents the bitrate reduction you should expect when comparing a single full resolution encode from VP9, HEVC, or AV1, as compared to H.264. Obviously, this will vary based upon the codec and preset used.
In addition, any actual estimate of real-world savings from adopting a new codec has to consider before and after encoding ladders and the actual distribution of the streams to your viewers. If distribution is top-heavy, as most are in the US and Europe, you should be able to harvest a good bit of the number shown in Table 2. If you mostly distribute files in the middle or lower rungs of your encoding ladder, bandwidth savings will be much lower, though video quality should be significantly improved.
Suitability
Now let’s examine VP9’s suitability for a range of specific encoding applications. VP9 is not well suited for live origination because there are few (if any) hardware encoders available for live origination. While Xilinx does have an FPGA-based VP9 transcoding engine, it’s sold only to Twitch and isn’t available commercially. Intel’s implementation, SVT-VP9, performed poorly in a Moscow State University benchmark so doesn’t appear promising. Nvidia supports hardware-accelerated VP9 decoding, but doesn’t appear to support hardware-accelerated encoding or transcoding (see here and here).
| Codec Suitability | Live Origination | Live Transcode | Low Latency | 4K | HDR |
| H.264 | Excellent | Excellent | Excellent | Poor | Poor |
| VP9 | Poor | Poor | WebRTC | Excellent | Poor |
| HEVC | Good | Good | Nascent | Excellent | Excellent |
| AV1 | Nascent | Nascent | WebRTC | Excellent | Nascent |
I’ve experimented with software-based VP9 transcoding in FFmpeg and found it resource-intensive (4X x264 transcoding), that the outputs almost always exceeded the requested bitrates by significant amounts (like 70%+), and that the quality was similar to x264. In short, not a great value proposition. That said, the Wowza Streaming Engine does support transcoding to the VP9 format with specific instructions and recommendations in an article entitled Transcode live streams to WebM for MPEG-DASH playback with Wowza Streaming Engine.
Regarding low latency, VP9 is available for use in WebRTC and some advocate VP9 strongly over H.264 (see VP9 Codec: Is It Time to Adopt It in Your WebRTC Application?). Wowza Streaming Engine does support VP9 for WebRTC. With respect to low latency within MPEG-DASH or other HTTP protocols, the lack of efficient transcoding makes VP9 seem like a poor choice, and most of the efforts seem focused on H.264.
VP9 should work well with 4K video, which is why YouTube appears to encode all 4K videos using either VP9 (mostly) or AV1. For HDR, however, though VP9 is compatible with HDR10+ it’s not compatible with Dolby Vision. So, if you encode with VP9 and want to support both HDR10+ and Dolby Vision, you’ll have to also encode with HEVC. In contrast, HEVC supports both HDR formats. If you’re undeterred, Google has an extensive guide to HDR encoding with VP9 here.
Royalty Status
A patent pool administrator named Sisvel launched a patent pool for VP9 (and AV1) in March 2019 seeking royalties on consumer devices but not VP-encoded content. Google has announced that they are aware of the pool, but that they have “no plans to limit our use of VP9 or AV1 or change upcoming usage plans based on this announcement from Sisvel.” Since Sisvel isn’t seeking royalties on content, the pool should have minimal impact on streaming producers considering publishing with the VP9 codec.
| Codec Royalty Status | Encoder | Decoder | Paid Content | Free Internet Content |
| H.264 | Yes | Yes | Yes | No |
| VP9 | No | Consumer device | No | No |
| HEVC | Yes | Yes | Some | Unclear |
| AV1 | No | Consumer Device | No | No |
What You Need to Know to Produce VP9
VP9 has four profiles, which define the tools used during encoding (table 5). It appears that profile 0 is the default for most encodes, as Google’s recommended encoding parameters here only include a profile switch when encoding 10-bit HDR files with profile 2. All SDR sample command lines don’t include a profile switch.
VP9 also has 14 different levels that limit various encoding configuration options. If you’re distributing VP9 to a limited power device like a phone or SmartTV, check the specifications to understand any limits. For example, Google’s Android specs don’t specify a profile or level for VP9 playback, though Samsung’s Smart TV specs indicate support for VP9 profile 0/2 at up to 4K/60 and 80 Mbps.
Beyond these configuration options, there are multiple VP9 specific options detailed in Google’s documentation, FFmpeg’s documentation, and the FFmpeg Wiki. Google’s documentation contains detailed recommendations for live transcoding here. You can read about the options available for VP9 transcoding in Wowza Streaming Engine here.
Overall, for streaming to computers for browser-based playback, there’s a general feeling that AV1 delivers nearly the same compatibility profile with much better encoding efficiency, though encoding costs will be substantially higher. This perhaps makes AV1 a better solution for high-volume streamers than VP9. For 4K streaming to smart TVs, set-top boxes, and OTT devices, however, at this point, AV1 doesn’t offer anywhere near the same level of compatibility as either VP9 or HEVC.
In the next article, we’ll discuss the HEVC codec.