Having WebRTC VP8 on hardware is going to take time. Here’s why.
If I had to select an Achilles heel for WebRTC it would definitely be hardware support. There are those that will say I am making a fuss of a non-existent problem, but working for over a decade in the video conferencing market, I can tell you that hardware support simplifies things and improves the end result.
WebRTC decided to take the path of patent free (or more accurately royalty free) codecs. This reflects on the selection of codecs: Opus for voice and a clear preference of Google for VP8 over H.264. If Google has its way and VP8 will be selected as the mandatory codec, then we are headed into a world of hardware headache.
H.264 is the dominant video codec on the market today. I don’t think there’s a single multimedia chip that supports video codecs without supporting H.264 – it is simply unheard of. Chip manufacturers have taken H.264 to the extreme – the fact that you can encode and decode video in 1080p resolutions (=high definition) on a smartphone without taking too much toll on the running applications can be attributed to this.
Today, if you are into any serious video compression, then you do it with hardware – software just doesn’t cut it. A quad-code Intel CPU can probably run high definition video compression, but it won’t be able to do much else in parallel. If video communication is what we are looking for, then the ecosystem to support it must include hardware.
Google understands that – it is why it is offering the intellectual property of a hardware encoder and decoder for VP8 practically for free. But even having that as a head start still means a year or two of development – it requires adding it to the chipset roadmap, doing the design, development, testing and then manufacturing of such chipsets.
It will take time for VP8 to become commonplace in chipsets, while at the same time, H.264 is widely available.
I wonder how the fight over the video codec will end for WebRTC, and will we have licensing headaches or hardware headaches once a decision is made.
I tend to look at it from the bright side, you mention it takes two years to create a good hardware implementation.
They’ve been at it for about 2 years now, with hardware designs almost from the start, so I don’t think it will take much longer. 🙂
Perhaps even more concerning to me about VP8 is “why VP8?” I’ve not heard any claims that it is superior to H.264. People have said H.264 is patent encumbered, but VP8 is worse: we have no idea who owns the IPR on VP8. I’d venture to guess that many of the companies that own IPR on H.264 also have IPR that covers VP8. The decisions related to codec selection just do not make sense to me. It appears to be about the hope for royalty-free, but “there’s no such thing as a free lunch”.
Thanks for a great blog series!
Regarding hardware support for H.264, in a comment at http://blog.tmcnet.com/blog/tom-keating/webrtc/webrtc-challenges.asp you mention that there’s big difference between streaming and RTC use of H.264. Is it then that the advantage of H.264 regarding hardware support is just that it is closer to being RTC-capable, but it is not yet really available? That would mean that the current hardware chips in mobile devices are next to useless for RTC and in particular WebRTC, if H.264 is chosen.
It is not that you can’t use it for RTC – you can, but the end result is going to be less than satisfactory – especially when latencies and packet losses start degrading the network.