Silvano Rebai - Fotolia


As Chrome adds VP9 codec support, enterprises must adapt

Google Chrome recently announced VP9 video codec support for WebRTC applications. Enterprises need to find the appropriate use cases to capitalize on the enhanced media quality.

In the last quarter of 2014, Google announced plans to add the VP9 video codec to its Chrome browser for WebRTC applications. Since then, we've seen progress of those plans, mainly through Google's roadmap announcements in WebRTC-related events, as well as behind runtime flags of its browser. But we hadn't seen the real deal -- VP9 in Chrome WebRTC.

The VP9 codec is the successor to Google's VP8 video codec. It is a royalty-free series of codecs vying to usurp the dominance of the royalty-bearing codecs H.264 and H.265.

Now, at the start of 2016, Google officially stated VP9 will be part of its upcoming Chrome 48 release. Chrome will still prioritize VP8, but developers can state their preference for VP9.

The VP9 codec offers better compression than VP8. In broad terms, this means VP9 offers better quality than VP8 for the same bitrate; or VP9 has a lower bitrate than VP8 for the same quality.

So, what does all of this mean for enterprise communications?

Simple, complex and mobile use cases for VP9

For most one-on-one video calling use cases, VP9 is a boon. With just a slight code modification, this new codec can be integrated instead of VP8 -- and end users can enjoy enhanced media quality. If your organization has this use case, be sure to add VP9 codec support soon.

In the future, VP8 support might not be 'good enough' for your needs. You will need to invest in VP9 support sooner or later.

When use cases require some server-side media processing for WebRTC, the integration is trickier. These use cases oftentimes rely on the ability to decode or encode the media, transcode it to other formats, or just require all participants to use the same codecs. In all such cases, integrating VP9 means added complexity and coding.

It took Google over a year to stabilize and optimize VP9 in order to add it into WebRTC in the Chrome browser. Expect the timeframe for media servers' adoption of VP9 to be just as slow.

Traditionally, mobile WebRTC support lagged behind PC browser WebRTC support. VP9 won't be any different. The moment Google launches VP9 in Chrome, it is immediately available to everyone. For mobile, developers will need to upgrade their WebRTC software developer's kit (SDK), taking into account VP9 portability to various mobile chipsets. This process takes time and resources.

If you are using mobile WebRTC SDK for your service, expect no solid VP9 support in it for the next six months -- at the very least. Codec adoption takes time.

Developers need to ensure compatibility with VP9 codec

For the most part, running a WebRTC service in Chrome 48 should not be affected by this change. The behavior is the same -- you should be getting VP8 by default.

That said, will Chrome always retain this preference of VP8 over VP9? This is highly unlikely. The past shows Google isn't afraid of ripping out old technology and replacing it with new technology through a gradual process.

Assuming VP9 adoption and feedback is positive, how long will it take Google to make it the preferred default codec for WebRTC in Chrome? Will it happen in Chrome 50? 52? 56? That day will surely arrive. A few years down the road, it is just as reasonable for Google to stop supporting VP8 in WebRTC altogether.

In the future, VP8 support might not be "good enough" for your needs. You will need to invest in VP9 codec support sooner or later, so you'll probably want to validate that it works in your service -- or have an action plan on adding support for it.

Where is H.264 in Chrome?

Google has promised support for H.264 as well. H.264 has been mandated as a video codec for WebRTC browser support alongside VP8. It seems that the process of adding H.264 is taking a bit more time than Google has planned.

Many developers are waiting for H.264 support for a few reasons:

  • Connectivity to legacy systems that use H.264
  • Adoption in live broadcast use cases
  • Better mobile performance by leveraging H.264 hardware acceleration

H.264 will probably be introduced to Chrome later in the first half of 2016, but will be made officially available to the masses only in the second half of 2016. It is a work in progress that will take time to mature and stabilize.

Video coding in WebRTC and as a whole is still a work in progress. We haven't reached the point of ubiquity. So, this means enterprises will need to continue researching and investing in WebRTC applications to stay on top of their game in 2016.

Next Steps

Which WebRTC video codec will prevail?

Preparing for mandated WebRTC video codecs

Predicting WebRTC technology trends for 2016

Dig Deeper on Unified Communications Architecture and Service Models