All posts tagged vp8

Editor Note: Fippo uses a lot of advanced WebRTC terms below – if you are a regular reader of this blog then don’t let that scare you. Wireshark is a great tool for diagnosing media issues and inspecting signaling packets even if you’re not building a media server. {“editor”, “chad hart“}

Stuff breaks all the time and then you need to debug it. My favorite tool for this remains Wireshark as we have seen previously. Its fairly useful for debugging all the ICE and DTLS stuff but recently I’ve had to debug the media traffic itself.

I had some questions; Fippo had some questions; so we asked Bernard if he could publicly respond here. It turned out Bernard and his teammate on the Edge Browser team, Shijun Sun, were building a running list of questions they wanted to address too. Here it is.

As WebRTC has matured to a state where it’s first implementations are ready for companies to launch real services around it, the readiness of various companies to adopt WebRTC has fanned out quite a bit. Some are already charging ahead as early adopters, while others are playing it conservative. Of those in the conservative camp, one of the common doubts that gives them pause is: “What about IE?”

When speaking to those interested in WebRTC, but concerned about Internet Explorer (IE), many times we’ve tried to assure them not to worry: our friends in Redmond won’t be too far behind. We often point to the undeniably significant contributions from Microsoft to WebRTC, especially considering that they bring to the table two titans of VoIP industry (Lync and Skype). We highlight some of their early IE WebRTC demos (using beta code) as signs of progress. We’ve rationalized the absence of a Microsoft equivalent to what Chrome and Firefox are shipping, by noting the slower release cycle for IE. However, we’ve come to realize that to some, IE support is a really big deal.

As detailed in previous posts on webrtcHacks, the Internet Engineering Task Force (IETF) has worked for the past few years to standardize the “on-the-wire” protocols that make up the WebRTC engine. It is coming up on 3 months since IETF 88 in Vancouver, where the IETF was to have settled the matter of a mandatory-to-implement (MTI) video codec. The process resulted in no consensus, and the task of finalizing WebRTC 1.0 drags on with MTI video codec(s) in question. A recent straw poll among IETF participants shows how divided the issue remains.

We had a lot of traffic to Victor’s post on the WebRTC mandatory video codec earlier this week. Given the news from Cisco yesterday we figured this warranted a quick follow-up post beyond what we could add to the comments area.

Quick debate recap

Engineers don’t like lawyers, and as Victor mentioned in his post earlier this week, much of the debate over assigning a mandatory video codec for WebRTC has been about avoiding the lawyers. While debate over the technical merits of H.264 vs. VP8 yielded no overwhelming winner (they are both great codecs), the debate has more recently revealed it’s true form as a mostly IPR related issue. The H.264 camp speculated that there could be legal issues with VP8 despite Google’s claims otherwise. There are certainly inherent issues with H.264. Which one has more risk? It would take lots of lawyers to sort through this and no one pays for lawyers to go to standards meetings. Even if they did, it wouldn’t matter – lawyers use arbitrators and the legal system, not technical standards procedures to work through disagreements.

In the WebRTC standardisation post I mentioned that one of the controversial discussions in the IETF context was the mandatory to implement (MTI) video codec battle for WebRTC. While there are some technical arguments on the topic (i.e this VP8 vs H.264 – subjective evaluation and this performance comparisons discussion), there is no dispute both are high quality and efficient video codecs. The issue here is all about IPR and licensing as described in this interesting and ongoing discussion: “VP8 vs H.264 – the core issue“.