Real Time Communications Featured Article

To VP9 or Not to VP9 with WebRTC?

February 22, 2016

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 ( 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 August 2015, so it should be around 2017 before you need to start worrying about the next video codec upgrade.

Edited by Stefania Viscusi

Article comments powered by Disqus


  Subscribe here for RTCW eNews   Upcoming Webinars

Featured Videos

Kandy Wrapper: Visual Attendant
Kandy Visual Attendant is ready for resale. The turnkey solution can be custom branded ...

NFV Made Easy
Moving to an NFV gives you An agile and lower cost network. With GENBAND's NFV Solutions ...
Kandy Bus 2016 Connected Experience
Kandy presents A Connected Experience, a three-part fire-starter where we build entire Kandy-enabled ...

View All