The WebRTC MTI Video Codec Doesn’t Really Matter

Video codecs come in pairs

The WebRTC Mandatory To Implement (MTI) video codec has been a battleground in WebRTC where each camp has its claims why VP8 or H.264 is the right one to go for.

This debate was going on in the IETF forever. Although the set is technical, the considerations behind the scenes are business, involve large companies and big money.

Based on the last IETF meeting held Nov 9-14, it seems like a consensus for a compromise starts to build up. Only time will tell if this proposal will become a definitive decision. The compromise is pretty much in line with what respondents to the Webinar Poll have answered as I described in an earlier blog post.

Here are the details of the compromise with a few edits I made to clarify:

• WebRTC User Agents MUST implement both VP8 and H.264 – simply put, this means browsers will have both following the footsteps
• WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis and that all IPR claims are withdrawn then IETF will mandate only that codec (this doesn’t apply to User-Agents). Since IPR rights and claims is not a normal thing for IETF to deal with (it is legal stuff) and companies will have different interests I believe we will be stuck with both for a long time.
• WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this can be any entity that can communicate with WebRTC end points but doesn’t comply with all WebRTC requirements).

What does this mean?

Even though this is considered a proposal and not a decision it looks like the IETF is leaning towards this compromise. Assuming so, what does this mean and what are the open questions

Browsers – starting with the clear and positive outcome of this, all browsers that will claim support for WebRTC will need to follow the footsteps of Firefox and support both VP8 and H.264.

For the browsers there will be no royalty issues as VP8 is solved (some disagree to this claim) and for H.264 a browser can use the Cisco binary downloaded from the Cisco servers.

PC applications – in some implementations developers use WebRTC as a media engine and compile it into their application. In case they want to be compatible with WebRTC (probably to fall under the definition of a WebRTC Device) they can take use WebRTC open source and for H.264 use the Cisco binary in the same way the browser use it.

Mobile and embedded devices will need to support both VP8 and H.264 and that’s where things start to get tricky.

For VP8 developers can take the open source and be covered from IPR perspective to the same extent as they are on PCs.

For H.264, the Cisco binary doesn’t help as it doesn’t support mobile.

Therefore, in the H.264 case, developers can bring their own codec only that this comes along with MPEG-LA royalties. The other option is to get it from the device or device OS.

The new versions of Android come along with WebView that has WebRTC built into it. Will that include H.264? Yet to be seen.

iOS is more complicated as WebView there doesn’t include WebRTC and there is no access to video codecs of the device.

The open questions on WebRTC MTI

• Will WebRTC code include H.264 and will that come along with patent claim protection (meaning some sort of indemnifications from a company with deep pockets and many lawyers)?
• Will developers comply with this compromise?
• What will happen with next generation video codecs. Will VP9 and H.265 be mandatory as well? Will there be a solution for patents also for H.265?

The important takeaways

There are were 2 open issues companies (mainly the big ones) use as an excuse why they need to wait with their WebRTC work:

• What will Microsoft do with IE
• How the video codec fragmentation will be solved

In the last few weeks we are seeing both of these issues moving towards a solution. That is great news.

The third issue, less dominant until now, is support for WebRTC in Safari. No good answer to that yet. Might be the next excuse though.

The important thing about the possible compromise coming from the last IETF meeting is less what the compromise is but rather the sheer fact there is a compromise underway.

The decision to make a decision is important by itself. In reality developers will continue to do what is best for their needs and business.

My guess is that those building closed systems will not go the extra mile and add H.264 to WebRTC Devices.

On the other hand, those that need to interoperate with existing video conferencing systems will add it in order to avoid the transcoding cost but they would have done that anyway.