WebRTC Video Codec Decision is… NO DECISION

As we discussed in previous posts, the IETF is meeting this week in Vancouver. Lots of interesting discussing including two sessions for the RTCWeb WG; the agenda for the two sessions can be found here. The first session, which was held on Monday, was mainly about updates on the JSEP (Javascript Session Establishment Protocol) specification, DataChannel, and RTP Usage with some interesting discussion on simulcast. During Monday’s session the security drafts [1][2] were also covered, but those unfortunately have not been updated since July and do yet not reflect discussions held during the last IETF meeting. Some preliminary notes from Monday can be found here.

Video Codec Discussion Recap

The second session, which just finished a few hours ago, it’s been all about Video Codecs. Specifically, it’s been about selecting THE Mandatory To Implement (MTI) Video Codec for WebRTC. As mentioned in other articles, the goal of having a mandatory to implement codec is to prevent negotiation failure, not to preempt or prevent negotiation. In other words, the MTI codec can be used always as last-resort if no other options are available. It’s been a very intensive discussion especially after Cisco’s announcement on H.264 and Google’s Nexus 5 with hardware-based VP8 video encoding and decoding. We tried to to represent the different positions on the topic in the following infographic. If you missed it, Erik Lagerway was doing live blogging during the event and recordings from the meeting can be found here.

The session started with the traditional IETF welcome note and agenda review from the chairs, followed by Harald’s Alvestrand (Google) presentation on VP8. Harald started by making some comments on quality of VP8 vs H.264 but immediately agreeing the issue discussed was not the technology but who owns it. He reused some slides he already presented in the past claiming that Cisco’s announcement did not really change the situation much; well, as you can see in the presentation some of the issues claimed in the past have now disappeared. His presentation did not take more than five minutes and questions were asked to be placed at the end. In my opinion Google could have made done a better use of their time.

Next were Jonathan Rosenberg (former Cisco, then Skype, then Microsoft, then recently moved back to Cisco) and Bo Burman. Jonathan started the H.264 pitch by first explaining what Cisco’s announcement was really about. According to his presentation, the binary module is not restricted to WebRTC and Cisco will push the first version of source into public repository before the end of the current year. He said that the binary version will be available starting on Jan 1st due to MPEG-LA cap. Jonathan also mentioned they will provide mechanisms to verify the binary code is the one resulting from the source one, so we can all make sure the NSA is not recording all our conversations via Cisco 😉

As you can see in his presentation, Jonathan mentioned a number of factors in favor of H.264 of which interoperability was the most important one. He basically said that we need to consider the internet as it is today and not as we’re wishing it to be. The internet today is using H.264.  He agreed H.264 is not a perfect solution but the goal for the meeting was to find a solution that works for most people. Other factors he mentioned are availability of experts and tools, multiple software code bases. The fact that H.264 is from a standards development organization, it has already had to go through a IPR evelaution — VP8 has not. This has helped H.264 make its way into hardware for  acceleration. Cisco claims most mobile chipsets support H.264 while only 4 support VP8 (we would love to hear how many of them really provide an API to enable H.264 HW encoding/decoding to third parties). Then Bo Burman of Ericsson presented some performance evaluation analysis based results already presented in the past.

Jonathan then went back to the stage and continued his arguments, now saying that MTI does not mean everyone should use it, just that it would be minimum bar necessary for usability. He also elaborated on the distribution model. This was followed by a patent risk analysis where basically he said that while there is still patent risk exist for both H.264 and VP8, H.264 has been there for 10 years while VP8 only for two. This gives VP8 more implicit risks since it has yet to be fully vetted by the market (e.g. Nokia distribution or even new patent holders demanding unreasonable fees once VP8 is already MTI). There was some discussion on Nokia’s plans and whether it they were a risk to VP8 — a couple of times it was asked to Nokia for clarification but no one answered to that. During the discussion it was mentioned that Skype is no longer using VP8. He then elaborated on the financial risks of VP8 vs H.264.

Jonathan concluded his presentation with the following:

• Selecting VP8  could cause WebRTC to fail to reach critical mass – it will turn away the existing players due to its  interoperability issues and it will introduce too much financial risk for the smaller players who cannot afford it
• Selecting H.264 will enable the existing players which is objectively the lower risk option for WebRTC’s success
• Work is active on achieving royalty free status for H.264 on two fronts – MPEG WebVC (CBP) and MPEG-LA revisit

After the two presentations, there was open discussion on some of the issues presented. During the discussion some folks claimed they didn’t have sufficient information to select MTI; some other complained on suggestions to use a plugin-based proposals and it seems adopting an older codec whose IPR has expired could prevent end-user adoption because of bad quality issues. Someone also mentioned that if VP8 was adopted, Microsoft and Apple would ship it if they did WebRTC at all; I guess the second part of the sentence is the relevant one (note that this statement did not come from anyone from Microsoft or Apple). Firefox expressed they intend to ship both VP8 and H.264 on every platform. VP8 built-in and H.264 via OpenH264 or platform built-ins depending on the platform situation.

It should also be noted that the option of selecting both VP8 & H.264 as MTI was ruled out early in the process because that was not in the list of options agreed upon in the mailing list months ago. However, there has been recently some discussion on this.

The Consensus Call

Once the time for discussion was consumed, it was the turn for the consensus call. It started with a test for objections with the following question:

“If you have a reason you cannot live with one of these codecs that has not already been discussed, can you explain it now?”

No one commented on this. So the chairs proceeded with the following consensus questions:

“You may indicate support on both questions and we encourage you to do so if you can live with either, even if you have a preference for one over the other.”

“If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now”

“If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now”

The Result

The result was something like 30/50 in favour of H.264 for the attendees in the meeting room and 75/25 in favour of VP8 for remote participants which represented a minority of participants compared with people in the room.  This was clearly not consensus (note this distribution is just a guess as the IETF process does not count votes but tries to verify whether there’s consensus).

In summary, it was declared that no clear consensus had been reached so no decision could be taken.

Now, according to the process, RFC 3929‘s Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (which is Experimental!) ‘External review team method’ should be followed as consensus is needed for this topic but cannot be reached. This is already being discussed on the mailing list. Now new proposals beyond VP8 and H.264 only could potentially be included as well.

{“editor”, “chad“}