H.264 for WebRTC MTI Codec
I have been supporting VP8 as the MTI codec in the WebRTC / RTCWEB WG, for various reasons including…
- Royalty Free (drives innovation)
- Open Source (Source code is optimized for RTC and readily available)
- Supported by a rather large company (Google)
It seems some of us may be changing our minds (myself included), for various reasons, eg…
- H.264 is prolific in RTC today. If we are to have interoperability with other endpoints out there we need 264.
- Open Source. H.264 optimized source for ARM and X86 its coming, Cullen said so 🙂
- Supported by many rather large companies (MPEG-LA for starters)
- VP8 IPR is coming under heavy fire. Nokia being one firm that has boldly stated that they hold patents on VP8 and will enforce them, and apparently there is at least one more VP8 patent holder out there that is keeping rather quiet, which is rather disconcerting.
- Since H.264 utilizes hardware acceleration, battery consumption on mobile devices should be lower as well.
- Quality is arguably better in some cases, this can be somewhat subjective.
So where does this leave the innovators that need free software to create free software? Great question, and here are some potential answers…
- If there is Open Source H.264 software out there that has been optimized for Real-time Communication (encoding and decoding in real-time) there are no “software” fees (excluding MPEG-LA), that is one less, rather large, obstacle.
- MPEG-LA (last I looked) has stated that there are no patent fees associated with deployments under 100k endpoints. This is great for smaller deployments but larger deployments could still have a problem here?
Some are saying that the bulk of all mobile devices that could support video have a t least one license for H.264 already, so why then would there be another royalty for H.264 on that very same device? This is an interesting argument and one that may in fact provide the innovative developers with a leg up when it comes time to debate the issue with the MPEG-LA. That being said, most innovative developers I know want nothing to do with legal debates.
There is also another factor to consider, many of the MPEG-LA patent holders are behind WebRTC, so why then would they shoot themselves in the foot and hamper adoption of WebRTC by litigating those who adopt it? There has also been talk of creating a new H.264 license in the MPEG-LA related directly to WebRTC / RTCWEB, which would be free of royalties. Talk is cheap.
Those vendors who only run one codec today will have likely already chosen H.264 for their existing deployments and will likely vote 264 as the MTI codec. At the end of the day, the prudent vendors looking for the most coverage in WebRTC interoperability will support both H.264 and VP8, regardless of which codec is selected as MTI.
After weighing all the options it seems (to me at least) that H.264 is the better choice today, now we just need an open source (with a BSD or MTI license or the like) H.264 implementation that has been optimized for WebRTC.
I am interested in hearing what the developers out there think about this. What do you think? Should H.264 be the MTI (Mandatory to Implement) video codec for WebRTC?
WebRTC.is 
Erik,
I am not that convinced.
Most VoIP OTT players today rise to millions of users before they make a single dollar out of their solution – how can they live with H.264? The fact that the chipset has H.264 doesn’t help any of the apps – they usually use a different codec implementation of H.264, and if you look into the future, H.264/SVC and H.265 will only complicate things.
I am leaning towards Dave Michel’s analysis on NoJitter more than this one: http://www.nojitter.com/post/240153449/h265-may-never-happen
Great feedback Tsahi, so which way will you vote at the next IEFT meeting?
Erik,
I am not one to go and vote in IETF meetings – had my share of political votings at standards bodies in the past and as long as I can stay away from it I will.
I think I am better suited at staning in the sidelines and passing judgment on everyone else 🙂
Tsahi
That’s too bad, if you feel strongly about VP8 you should make your voice heard. Even remote participation is valuable and your vote / hum counts.
I believe that making VP8 the MTI codec would be a mistake. It would in one quick move discard any opportunity for interop with the many millions of existing devices and services already existing. It would in effect make WebRTC just about island in so far as video was concerned.
There are so many H.264 enabled devices already in the market and effectively no VP8 at all. I expect that only the tiniest fraction of existing devices would ever become VP8 enabled. Making VP8 MTI would merely define the functionality that gateways would be required to provide, and inhibit the use of WebRTC outside of the browser.
H.264 as MTI will choke innovation and basically chain everybody who believes in WebRTC as a chance to join a new market. An open source implementation means nothing, if you still need royalties to use the codec, and as some developers pointed out on the IETF RTCWEB mailing list, getting those royalties is at times not only difficult or very expensive, but also impossible sometimes. As we all know, it’s not only a matter of browsers: several individuals and startups are building very nice applications that interact with WebRTC endpoints, meaning that the involved codecs need to be supported on the server side as well. H.264 as MTI means nothing else than preserving the status quo: royalty fees that for Cisco, Nokia and others are just a rounding number on their coffee budget, are something totally different for realities trying to emerge and that look at WebRTC as a potential way to do so by innovating. If VP8 is really not an option (and I refuse to think it isn’t) I’d rather have an old codec as H.261 as MTI or no codec at all.