Hello there VP9. We've been waiting for you (but you're already making trouble).

Philipp "Fippo" Hancke

Last week, Google Chrome started to support the next generation video codec VP9 for WebRTC (which is highly experimental in the developer version and you need to enable it, so the ETA for this is probably going to be mid-2015). That is good news because VP9 is going to offer better video quality at the same bandwidth (another way to look at it is that VP9 gives you the same quality at lower bandwidth, although at the expense of computational power, i.e. your mobile device gets warmer).

I immediately wanted to implement and test the feature, if only so I could add Chrome 41 to the long list of versions that I managed to crash. However, this turned out to be harder than it initially seemed.

Let me try to explain the issue with an example of a videochat that has three participants, two of which support VP9: Suppose that those clients use an XMPP MUC for having the conference, supported by an SFU like the Jitsi videobridge (which is what we do in the next version of Talky). The browsers announce their capabilities ("I implement VP8," "I implement VP9," a Firefox browser might even do H.264 and VP8) through Entity Capabilites when joining the MUC.

So the first two browsers know they both implement VP8 and VP9 and use that list of codecs when calling the RtpSenders .send method for the first time. That RtpSender object is another improvement that came from ORTC. If everything goes well, they will enjoy the superior quality of VP9.

Now the third client joins, announcing only VP8 in the presence. That is a relatively compact thing which we can do like this using stanza.io:

client.sendPresence({
    caps: {
        hash: 'sha-1',
        node: 'http://talky.io/web',
        ver: 'QgayPKawpkPSDYmwT/WM94uAlu0='
    }
});

Based on the short hash in the 'ver' attribute, the clients that are already in the room (and the conference focus, which controls the video bridge) can determine that the new client does not support VP9 and can therefore switch the codec they are currently sending. To do that, they call the .send method again, removing VP9 from the list of codecs. No additional signaling is required.

The same is true for the WebRTC PeerConnection API actually. Here, this would require an SDP renegotiation operation (all in the client, nothing goes over the wire) that removes VP9 from the list of supported codecs (by mangling the remote description and removing five lines -- or by just removing a single element in the JSON format we use for this). Still, it is much harder (at least for me) to come up with this conceptually and the ORTC description is easier to understand. I'll report further once we've had a chance to play with VP9 more extensively.

Oh codecs. Say! You want to learn more stuff about things? So do we! Like for instance how to send you our email newsletter! Sign up below.

You might also enjoy reading:

Blog Archives: