The latest version of Google Chrome (48) now includes official support for the VP9 codec. If you are building a WebRTC application, should you rush out to adopt it or wait?
VP9 is the next-generation open source video codec created by the WebM project and designed for use by the Alliance for Open Media. Since Amazon, Cisco, Google, Intel, Microsoft, Mozilla and Netflix are participants in the alliance, VP9 should turn up in a lot of places in the months and years to come.
A key advantage to VP9 is its ability to deliver the same video quality as the current generation VP8 codec, but with much lower bandwidth. Google says connections currently able to deliver 720p without packet loss or delay will be able to support a 1080p video call at the same bandwidth. In a best case scenario, VP9 can reduce bit rates for bandwidth constrained users to only 40 percent of what VP8 uses.
Developers should note that VP9 is not the preferred codec by default in Chrome 48 at this time, but it is a supported option. At some point in the future, VP9 will be set as the default, but Google hasn’t floated a time when it might flip the switch.
TestRTC (www.testrtc.com) says everyone needs to start looking at VP9 today, if you haven’t already. Services running peer-to-peer and not using any backend media processing will get an immediate media quality lift by switching from VP8 to VP9, so it is worth trying out as soon as possible. Similarly, if a WebRTC service is routing media through a backend server, but doesn’t do any other processing, it is worth trying out. Some fine tuning may be required, but otherwise it should be a straightforward process.
Where things get tricky is if the WebRTC service is encoding or decoding video on the backend, then there’s some legwork to do, since you’ll have to have the appropriate tools media processing for the new video format, most likely including transcoding support.
Testing of VP8 vs. VP9 in a videoconferencing app by TestRTC showed a bandwidth reduction of about 36 percent in using VP9, but Chrome 48 and/or the current implementation of VP9 might need more tuning. Chrome 47 with VP8 takes only about 10 seconds or so to average out its bandwidth usage to 2.5 Mbps, while Chrome 48 and VP9 take 30 seconds to settle down. In most cases, the extra time probably won’t make much of a difference, but for live broadcast events, the startup surge could cause some initial hiccups at the network and user level.
And if you are looking at a historical perspective on what to worry about next, you have a couple of years. VP9 development started in 2011 and wasn’t finalized until 2013, so figure that the “official” support for VP9 didn’t happen until last week — call it 2 years between usable code and the push for wider adoption. Code for VP10,supporting 4K quality broadcast video, was released in November 2015, so it should be around 2017 before you need to start worrying about the next video codec upgrade.
