It’s not a clear-cut
Fippo got Tsahi Levent-Levi to write his post about H.264 wining over VP8 as the WebRTC video codec, which got me to write this post. Who said life isn’t interesting.
There are 2 main decision criteria for choosing a video codec – technical and business.
Tsahi touched the technical part in his post. While I’ll get a bit into the technical aspects as well, in this post I also want to cover some of the business considerations.
Some of the business considerations are impacted by technology as there is always a balance required between quality and user experience and cost.
Let’s put one thing behind us. The difference between H.264 and VP8 from quality perspective is more of a religion than anything else.
Royalties & patents
Video codes are hard to build (mainly the encoder part) so companies defend their intellectual property with patents and ask for royalties when being used.
H.264 royalties are being collected through the MPEG LA. Since many claim for essential patents in this codec there needs to be one organization to collect the money and split the royalties between them all. MPEG LA is the money machine that takes care of this, great business, isn’t it J. If your application has H.264 in it you must pay royalties for every download/installation of that application.
A partial solution for this problem was provided by Cisco through a binary package that can be downloaded from a Cisco server for which royalties have been settled with the MPEG LA. Cullen Jennings gives a detailed explanation how it works in this video.
BUT!!!
This deal Cisco closed with MPEG LA doesn’t cover cases where you don’t take the binary package from the cisco server in the method described in the video and therefore it doesn’t cover mobile. I gave a detailed analysis of this topic and the IETF compromise about the WebRTC video MTI codec.
VP8 is being promoted by Google and Google got you covered on the royalty front by clearing this issue and making VP8 (and VP9) royalty free. Some do claim this is not accurate but with Google’s backing for this I wouldn’t lose sleep on VP8 royalties, Google’s lawyers already did.
VP8 on mobile
Mobile devices have HW acceleration for video processing. H.264 is common among mobile devices while VP8 is less common. However we are starting to see SoCs (System on Chip) that do support VP8 HW encode and decode. Qualcomm Snapdragon 800 has it and there are many devices that use this SoC. Rock-Chip, a Chinese vendor used by many Chinese manufacturers, also included VP8 in some of its SoCs. VP9 is also making its way into SoC for mobile.
3 things to note regarding mobile:
- Not all mobile devices/OSs allow to access HW acceleration which means you are left with SW codecs and royalties in the case of H.264
- Legacy devices are still based on chipsets that have only H.264
As support for VP8 is getting common in SoCs for mobile and as WebView in Android includes WebRTC and iOS UIWebView will include it as well, the support for both H.264 and VP8 will become common on mobile devices.
Interoperability means business
Mitigating between clients supporting different codecs requires transcoding which ads delay, reduces quality and increases cost. Transcoding should be avoided whenever possible. But still, there are examples in which it makes sense to pay the transcoding penalty.
Here is one.
A system deployed in web scale (that means masses) that includes a web application (browser based) and a mobile application.
The mobile application was built using WebRTC as a media engine.
The common use cases are web to web and web to mobile but there are some less common use cases that require connecting with traditional video systems that support H.264 only.
Technically the right solution can be to always use H.264 but the business implication will be to pay royalties for all the mobile applications downloaded (this includes version updates).
In such case it might be better to pay the transcoding penalty for the less common use case and save the royalty cost.
Microsoft has more underway
In the April Microsoft announcement in which they mentioned their planed support for H.264/AVC, Microsoft also mentioned planned support for WebRTC 1.0 APIs (that’s non ORTC APIs) and VP8. There are no dates for these 2 but there was also no date for H.264/AVC so we should hope Microsoft would live to their promise.
It’s a moving target
The H.264 vs. VP8 is not a clear-cut decision. It requires analysis of the use cases and business implications. This decision may change over time due to change in support for video codecs in browsers and mobile devices.
Google is working hard on promoting VP8 and VP9. It is adding SVC to VP9 to allow it to better overcome network impairments and increase efficiency. Google did add H.264 to Chrome, not clear yet what will be their strategy with H.265. In any case, chrome is the leading browser when it comes to WebRTC communication and Google can control what gets into it in order to serve their video codec strategy.
Leave a Reply