WebRTC is one of the most exciting things to happen to the Web in years: it has the potential to bring instant voice and video calling to anyone with a browser, finally unshackling us from proprietary plugins and installed apps. Firefox, Chrome, and Opera already support WebRTC, and Microsoft recently announced future support.
Unfortunately, the full potential of the WebRTC ecosystem has been held back by a long-running disagreement about which video codec should be mandatory to implement. The mandatory to implement audio codecs were chosen over two years ago with relatively little contention: the legacy codec G.711 and Opus, an advanced codec co-designed by Mozilla engineers. The IETF RTCWEB Working Group has been deadlocked for years over whether to pick VP8 or H.264 for the video side.
Both codecs have merits. On the one hand, VP8 can be deployed without having to pay patent royalties. On the other hand, H.264 has a huge installed base in existing systems and hardware. That is why we worked with Cisco to develop their free OpenH264 plugin and as of October this year, Firefox supports both H.264 and VP8 for WebRTC.
At the last IETF meeting in Hawaii the RTCWEB working group reached strong consensus to follow in our footsteps and make support for both H.264 and VP8 mandatory for browsers. This compromises was put forward by Mozilla, Cisco and Google. The details are a little bit complicated, but here’s the executive summary:
- Browsers will be required to support both H.264 and VP8 for WebRTC.
- Non-browser WebRTC endpoints will be required to support both H.264 and VP8. However, if either codec becomes definitely royalty free (with no outstanding credible non-RF patent claims) then endpoints will only have to do that codec.
- “WebRTC-compatible” endpoints will be allowed to do either codec, both, or neither.
See the complete proposal by Mozilla Principal Engineer Adam Roach here. There are still a few procedural issues to resolve, but given the level of support in the room, things are looking good.
We believe that this compromise is the best thing for the Web at this time: It lets us move forward with confidence in WebRTC interoperability and allows people who for some reason or another really can’t do one of these two codecs to be “WebRTC-compatible” and know they can interoperate with any WebRTC endpoint. This is an unmitigated win for users and Web application developers, as it provides broad interoperability within the WebRTC ecosystem.
It also puts a stake in the ground that what the community really needs is a codec that everyone agrees is royalty-free, and provides a continuing incentive for proponents of each codec to work towards this target.
Mozilla has been working for some time on such a new video codec which tries to avoid the patent thickets around current codec designs while surpassing the quality of the latest royalty-bearing codecs. We hope to contribute this technology to an IETF standardization effort following the same successful pattern as with Opus.
Andreas Gal 
Reading the IEBlog, it sounds like Microsoft will support H.264 but won’t support VP8 in WebRTC. Does the compromise you discuss in your blog post mean that Microsoft will now also support VP8? And if Microsoft supports Opus and VP8, will that support also carry over to the audio and video tags (implying WebM and Vorbis support)? And what’s Apple’s position in all of this? Does Apple look likely to support Opus or VP8 any time soon?
I can’t speak for Microsoft but if the IETF consensus is ratified, Microsoft would have to support both H.264 and VP8 to be standards compliant. The consensus only applies to WebRTC. I would be surprised if Microsoft enables VP8 in the video tag since VP8 is basically unused for Web video in practice (sadly). Opus is a good question. That actually might make quite a bit sense even for Microsoft. We will see!
One good reason for Microsoft to enable VP8 in the video tag is to allow recording WebRTC sessions with the MediaRecorder API without transcoding, while still allowing them to be played back in the browser that recorded them. IE does not yet support this API, either, however. This another good reason for them to support Opus, too (since it’s what will be used for audio regardless of which video codec gets used).
How is an endpoint that supports neither codec “WebRTC-compatible”. It seems the complete opposite will be true and that is why the standards bodies have bad reputations.
For use cases that only need a data channel and no codecs at all?
Have Apple or Microsoft said anything, positive or negative, about their intent to implement this if ratified?
Both ship H.264 today so that part should be easy. You have to ask them about VP8 but in theory Google could offer a VP8 plugin the way Cisco offers a H.264 plugin. That might help Apple and Microsoft to come on board.
“Non-browser WebRTC endpoints will be required to support both H.264 and VP8. However, if either codec becomes definitely royalty free (with no outstanding credible non-RF patent claims) then endpoints will only have to do that codec.”
Can you elaborate on this? What is a credible non-RF patent claim? Obviously VP8 is royalty free already.
Amongst others Nokia has asserted patent claims against VP8 and this case is being litigated in Europe. Nokia has declared that they will not license that IP under any terms, let alone RF terms.
What is the patent status of VP9? Any particular reason that this discussion is focussed around VP8 instead of VP9?
VP9 is an iterative improvement over VP8, so many patents that hit VP8 likely also affect VP9. This is why we think its necessary to start from scratch with a new approach that is unrelated to H.264/H.265/VP8/VP9 to produce a truly royalty free codec.
I’m not trying to argue (I’m only partially educated in this realm), but wasn’t VP8 supposed to have the same goals. i.e. Be different enough from H.264 that patents would not be an issue?
In practice VP8 seems to be at the technical level very closely related to H.264, which has the risk of infringing on H.264 patents or other patents that were secured as part of the H.264 process but not accepted into the final standard. Our codec Daala avoids most of this by using completely different technology than existing codecs (we jokingly refer to Daala as alien technology from outer space to highlight how different it is in nature).
Awesome! I’m really looking forward to Daala, it sound amazing.