Last year, the IETF Working Group for WebRTC settled a crucial video codec debate that has paved the way for more WebRTC development. At question was whether VP8 or H.264 should be implemented as WebRTC's video codec of choice. Ultimately, the IETF reached a consensus that WebRTC browsers must incorporate both codecs in order for the browser to be fully WebRTC compliant.
Their full conclusions were:
- 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.
The ruling has potentially given developers more clarity and leeway when they work with WebRTC. But what exactly separates VP8 from H.264 in the first place? And what effect will this have on WebRTC development?
VP8: It's Priceless
Up until late 2014, VP8 was the only required video codec for WebRTC browsers or devices. VP8 is ideal for WebRTC's open source project, because Google offers the codec and its source code at no cost. The technology is powered by the open source library libvpx.
VP8 does not have a limit on frame or data rates. It utilizes 14 bits for both width and height, which makes the maximum resolution 16384x16384 pixels. A free RTL hardware encoder for VP8 was released by the WebM project for interested semiconductor manufacturers.
H.264 requires licenses from patent holders and royalties for hardware, but Google has entirely released all of the VP8 patents it owns under a royalty-free public license. According to a comparison of VP8 with H.264 conducted by StreamingMedia, it was concluded that H.264 may have a slight quality advantage, but the difference is not commercially relevant.
H.264: Mr. Popular
H.264 (or MPEG-4 AVC) is a video compression format that is widely used for recording, compression, and distribution of video content. The format is used by sources such as iTunes, YouTube, Silverlight (streaming services such as Netflix), HDTV broadcasts, and even Adobe Flash Player.
H.264 has a long and storied history, introducing standards such as Scalable Video Coding (SVC) and Multiview Video Coding (MVC), which enables features such as stereoscopic 3D. On first glance, the quality of VP8 and H.264 may be hard to distinguish. But underneath the hood, there's a clear difference. According to a study that used a MacBook Pro with GPU acceleration, VP8 took 38% of the total CPU to play a 720p file, compared to 24% for H.264.
H.264 is currently much more prevalent than VP8 encoded video sources. It's no wonder that developers who are used to implementing this popular codec want to see it incorporated in WebRTC browsers or devices. The main sticking point against H.264 is basically theoretical. Although H.264 is licensed for "free", MPEG-LA is still offering the service in a proprietary model, which some feel violates the open source principles of WebRTC.
Can't We All Just Get Along?
The decision to require compatibility for both VP8 and H.264 seems to come from a place of combination for the sake of inclusion and efficiency. But just how much will this conciliation affect actual WebRTC adoption? At the very least, it assures developers who use the H.264 codec that they can continue working with the standard they're used to implementing. It also offers developers more technical options when crafting their apps.
A bigger tent for WebRTC means room for more people, from game developers to business VoIP offerings. But how exactly does WebRTC attract these people in the first place? Even though the inclusion of H.264 seems to violate the pure open source ethos of WebRTC, it ultimately offers developers more options in crafting their applications. It's this sort of compromising that's making WebRTC seem more like a viable, accessible solution, than an insular technology that exists in its own ecosystem.
Right now, Firefox is the only browser that definitely supports both VP8 and H.264 codecs. But the latest conclusions of the IETF suggest that there is a point in the not-so-distant future where VP8 and H.264 might co-exist peacefully within the WebRTC universe.