WebRTC promises to transform how we engage with one another by embedding voice, video, and data communications capabilities directly into the browser. While the technology is still a work in progress, I have amassed a list of over 130 companies who have WebRTC-based products and services, and it grows by several companies every week. If you use the Chrome or Firefox browsers on your computer, you already have access to WebRTC technology.
The standards bodies are working hard to create version 1.0 of the WebRTC standard.
However, a significant problem has arisen in the standard approval process: no agreement has been reached on which video codec or codecs to include in version 1.0 of the WebRTC standard. Google has open-sourced the VP8 codec while Cisco has committed to pay the H.264 licensing fees. Thus either codec could be adopted.
Which leads to a political problem in selecting a video codec for WebRTC: some working on the standard want VP8 and some want H.264, and the Internet Engineering Task Force (IETF) working group on WebRTC has been unable to get a consensus on which codec to include.
How the IETF Standards Process Operates
The IETF process to develop standards centers around the loose concept of consensus. Furthermore, anyone can be part of the IETF standard-making process, not just people from large or small companies. In fact, those working on the standards must join the IETF as individuals, not as company representatives.
The usual way a standard is adopted or modified is that those who are attending a standards meeting indicate their opinion by "humming". The workgroup chairpersons read the proposals to the group, and those in favor of a proposal "hum" their approval. Next, those opposed to a proposal are given the opportunity to "hum" their opposition. If there is a clear consensus for or against a proposal based on the volume of the humming, then the proposal passes or fails. However, if the workgroup chairs cannot determine a clear consensus, then no action is taken.
Such is the case with the video codecs for WebRTC: there was no clear "humming majority" for either VP8 or H.264.
Which leads the real possibility that WebRTC V1.0 may be approved with no video codec at all, leaving it up to the browser manufacturer as to which video codecs, if any, to support. In my mind, this would be a disaster for the entire WebRTC initiative, leading to chaos!
Figure 1. Like a tractor without a front tire, WebRTC without a mandatory video codec will highly unstable.
What You Can Do To Help
When humming is not sufficient to reach consensus within the IETF, there are alternatives the workgroup can use to make a decision. Any alternative method can only be used with the consensus of the group, however.
The WebRTC workgroup chairs have proposed that the decision on selecting a video codec be put to an actual vote. In order to move to this method, however, the workgroup chairs must have the consensus of the group. It is highly unlikely that 100% of the group will want anything, but if significant majority do reach consensus, that is sufficient.
If you want to see resolution on the video codec issue, you can help by doing the following:
1. Subscribe to the IETF RTCWeb working group at https://www.ietf.org/mailman/listinfo/rtcweb
2. Send an email to the working group at [email protected] indicating that you want the group to take an actual vote.
By doing these two steps, you effectively become part of the standards-making process.
I have been assured by one of the workgroup chairs that every opinion in an email sent to the working group will be tabulated. If consensus is reached on taking an actual vote, the working group chairs will then arrange a vote. Consensus will then have to be reached on who can vote, but at least the process will move forward.
The following codec alternatives have been proposed:
1. All entities MUST support H.264
2. All entities MUST support VP8
3. All entities MUST support both H.264 and VP8
4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
5. All entities MUST support at least one of H.264 and VP8
6. All entities MUST support H.261
7. There is no Mandatory To Implement video codec
8. Option #5 + #6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
9. All entities MUST support Theora
10. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261.
11. MUST implement at least two of {VP8, H.264 CBP, H.263}
Anyone can suggest an alternative codec proposal, and any serious proposal will be added to this list. You will notice that one of the alternatives is to have no mandatory to implement codec. The updated list of alternatives can be found at http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart#VideoCodecSelection.
My own preference would be to see both H.264 and VP8 as mandatory to implement in WebRTC and then let the market decide on which, if either, is ultimately more widely adopted by application developers.
This is a call to action! If you have interest in seeing this video codec issue in WebRTC resolved, may I encourage you to get involved!
