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 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.
Peter Dunkley says
The interesting thing to me (and this contains a bit of a sweeping generalisation) is that those in the room clearly favoured (without consensus) H.264 but that those online-only massively preferred VP8.
There has been mention in the past (both on the list and during yesterday’s meeting) that H.264 is preferred by the big players and they have an unfair advantage in that they can afford (the time and money) to send their representatives to an IETF meeting, while the smaller players (who often cannot attend) prefer VP8.
The vote yesterday appears to support this view, and I do wonder if this is something the IETF needs to consider carefully. While there is clearly no deliberate move to cut-out smaller players the costs of fully participating in the IETF process does have this effect.
The inability of the small players to fully participate has some interesting consequences. The recent article on this site that contained a table that indicated only Google supported VP8 and everyone else supported H.264 is a good example. Yesterday’s consensus call shows that this is clearly not the case but based on the views of those who has fully participated in the process it certainly looked that way at the time.
Victor Pascual says
Thanks for your comment, Peter. I tend to agree with you, with the following considerations:
– In the table you mention, we included companies authoring proposals submitted by Oct 6 2013 as requested by the WG chairs. Anyone was able to submit a draft saying “Codec ABC should be MTI because of XYZ”; no restriction here.
– I agree with you that big players can spend more cycles on IETF as some of them have full-time standards people. In our case, as small players, IETF is more like a side/evening activity.
– When it comes to the cost beyond time dedication, one can actually participate in the process without any travel/registration expense — meetings can be joined remotely and consensus calls are always confirmed on the mailing list. But yes, it’s true big players can do some room flooding but opinions/feedback from remote participants is always taken into account
Alan Quayle says
Hi Victor, remember back to Berlin and our workshop on WebRTC? Looks like the prediction was correct, agree to disagree and continue to let the market decide.
Victor Pascual says
Hi Alan, the IETF RTCWeb WG chairs have proposed to follow the ‘Alternative Decision Making Process – External review team method’ as described in RFC3929
They are taking proposals on what to do next. I think they said RFC3929 has never been used before as people didn’t want to either.
The choice was only between VP8 or H.264. Both or non wasn’t on the table at this time. I think we might end up with no MTI. Which is a short term win for H.264, but means that we are not stuck with H.264 forever as part of the specification.
Victor Pascual says
Video codec selection – the proposed alternatives http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
The deadline to propose additional alternatives is 27th of November 2013
Lorenzo Miniero says
Just as a note for people who couldn’t attend the session (in the room or remotely), we made recordings of it available here:
Victor Pascual says
Final list of Video Codec Alternatives http://www.ietf.org/mail-archive/web/rtcweb/current/msg10315.html
Victor Pascual says
Next Steps in Video Codec Selection Process
Straw Poll on Video Codec Alternatives
HI Muaz Khan,
I have problem to stored in server for video recording files in php ,
please advice to uploading video into server video (size increase)
how to configure to server in accessing for more users at a time.
Please explain and advice it.
Victor Pascual says
RFC 7742 on WebRTC Video Processing and Codec Requirements https://www.rfc-editor.org/info/rfc7742