Will your WebRTC service cope with VP9?

Chrome 48 has been out for a week now with some much needed features – some of them we plan on using in testRTC ourselves.

One thing that got added is official VP9 support. Sam Dutton, developer advocate @Google for everything WebRTC (and then some), wrote a useful piece on how to use VP9 with Chrome 48.

A few things interesting here:

  1. Chrome 48 now supports both VP8 and VP9 video codecs
  2. While VP9 is the superior codec, it is NOT the preferred codec by default

That second thing, of VP9 not being the preferred codec, means it won’t be used unless you explicitly request it. For now, you probably don’t have to do anything about it, but how many Chrome versions will pass until Google flips this preference?

When should you start looking at VP9?

  1. If your service runs peer-to-peer and uses no backend media processing, then you should care TODAY. Change that preference in your code and try it out. That’s free media quality you’re getting here
  2. If your service routes media through a backend server but doesn’t process it any further, then you should try it out and see how well it works. With a bit of fine tuning you should be good to go
  3. If your service needs to encode or decode video in the backend, then you’ve got work to do, and you should have started a couple of months ago to make this transition

In all cases, now would be a good time to start if you haven’t already.

Let’s take a look at AppRTC and VP9

You may have noticed I am a fan of using AppRTC for a baseline, so let’s look at it for VP9 as well. Google were kind enough to add support for VP9 to AppRTC, which means that our own baseline test for our testRTC users already supports VP9.

I took our AppRTC testRTC script for a spin. Decided to use a 720p resolution for the camera output and placed two users on it to see what happens. Here are screenshots of the results:

Chrome 48 AppRTC with VP9

What you see above is a drill down of one of the two test agents running in this test. The call was set to around 3 minutes and the interesting part here is in the bottom – the fact that we’re using VP9 for this call. You can also see that the average bitrate for the video channel is around 1.6Mbps. More about that later.

We could have done this when Chrome 48 was beta, but we didn’t have this blog then, so there wasn’t any point 🙂

When you look at the graphs for the video channels, this is what you see:

Chrome 48 AppRTC with VP9

From the above charts, there are 3 things I want to mention:

  1. It takes Chrome around 30 seconds to get to the average 1.6Mbps bitrate with VP9
  2. It is rather flaky, going up and down in bitrate quite a lot
  3. This also affects the audio bitrate (not seen here, but in another graph in the report that I didn’t put here)

How does this compare to VP8?

I took the same test and used Chrome 47 for it via testRTC. Here’s what I got:

Chrome 47 AppRTC with VP8

The main difference here from Chrome 48’s VP9 implementation? Average bitrate is around 2.5Mbps – around 0.9Mbps more (that’s 36% difference).

What’s telling though is the other part of the report:

201602-Chrome-47-VP8-2

Notice the differences?

  1. It takes Chrome 47 10 seconds or less to get VP8 to its 2.5Mbps average bit rate. A third the time that Chrome 48 needs for VP9. I didn’t further investigate if this is an issue of how Chrome works or the specific video codec implementation. Worth taking the time to look at though
  2. Chrome 47 is as stable as a rock once it reaches the available bitrate (or its limit)
  3. Audio (again, no screenshot) is just as predictable and straight in this case

How are you getting ready for VP9?

VP9 is now officially available in Chrome. There’s a lot way to go still to get it to the level of stability and network performance of VP8. That said, there are those that will enjoy this new feature immediately, so why wait?

We’re here for you. testRTC can help you test and analyze your WebRTC service with VP9 – contact us to learn more.

Leave a Reply 5 comments

Sergio Garcia Murillo - February 10, 2016 Reply

One more thing to take into consideration is that I am not sure that RTX support is available yet for VP9, which may have huge impact on packet loss environments: https://bugs.chromium.org/p/webrtc/issues/detail?id=4024

    Tsahi Levent-Levi - February 10, 2016 Reply

    Sergio – thanks.

    I guess this is a follow up post we’ll be doing once that gets added to Chrome 🙂

Justin Uberti - February 10, 2016 Reply

RTX support for VP9 is now present in canary. Might want to retest with canary and see if you see the same issues.

    Tsahi Levent-Levi - February 10, 2016 Reply

    Justin, I just tried it with Chrome 49.0.2623.39 and 50.0.2638.0 on our platform with the exact test script and network conditions – similar network behavior to Chrome 48.

    We can’t use Chrome Canary as our machines currently support only Linux (a thing we plan to remedy).

    I can publish screenshots of the results if that helps.

VP8 vs VP9 - Is this about Quality or Bitrate? • BlogGeek.me - May 9, 2016 Reply

[…] often missed. I used to know it about a decade ago and then forgot until recently, when I did the comparison between VP8 and VP9 in WebRTC on the […]

Leave a Reply: