VP9 is a new proposition. It isn’t being accepted by the market well enough. Does that matter to Google?[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]
There’s a codec war going on around WebRTC, focusing on the mandatory video codec – it can either be VP8 or H.264. While Google, Mozilla and developers are mostly in the VP8 camp (read: FREE), the rest of the industry and the ecosystem is barricading itself aound H.264 (read: ROYALTIES). While some say it is a technical debate, I beg to defer – it is a political and a business debate. At the end of the day, the end users are not going to feel the difference in quality.
I think that we’ve moved on to a much more interesting war – the one brewing around VP9 and H.265. VP8 may lose the VP8 round, but the real war is around VP9. Why is that? Because the main “concerns” people have about VP8 don’t matter in the case of VP9:
No Hardware Support
Hardware support is hard to deal with. H.264 has a huge footprint. I’d argue it is probably larger than the “1 billion potential WebRTC devices”.
Hardware support for a video codec isn’t easy. It usually takes 1-2 years to begin with – once you have the basic hardware in place, there’s the time it takes to develop the device (add 6-12 months) and then the actual application.
Going with VP8 from 0 to H.264 HW coverage is an impossible task.
Switching gears to VP9, the story resets. VP9 is compared against H.265 – they are on par. The beauty here is that there is no H.265 support in hardware yet, which places both codecs in a similar starting position.
The Need to Transcode
There’s a lot of H.264 equipment out there that people would love to be able to connect to WebRTC, so one of the other excuses not to use VP8 is usually around the fact that making it mandatory means there will be a need to transcode the video in all such interactions.
While true, we can argue about the percentage of the use cases that will actually need such capabilities. The problem with that, is that we will be fighting over details. Not a good tactic.
VP9, on the other hand, is again comparable to H.265. If the industry is indeed going to replace H.264 with another codec, then all legacy devices will require transcoding – be it to H.265 or VP9. Same starting position.
There’s no real ecosystem yet around H.265. Well… there is – the companies that have standardized it; but eventually the game is wide open, especially when a behemoth like Google is changing the rules of the game.
During Google I/O, two messages were crystal clear to me, and chipset vendors should take notice.
- NVIDIA showed off 1080p video call using WebRTC on a Tegra 4 based tablet. It uses hardware accelerated VP8. It is a beginning of a hardware ecosystem around VPx line of codecs, and there are move chipset vendors I know of that are headed towards that goal.
- Google is working on two separate advances that may soon collide:
- Compression tech for its mobile Chrome browser, which crunches HTML, CSS, JS and images up to save on bandwidth
- VP9 support in YouTube. With 100 hours of videos uploaded a minute and 1 billion unique monthly visitors, YouTube support for VP9 is hard to ignore
Connect the dots here, and we may soon see VP9 in our mobile browsers for anything that Google sees fit
The first is a nudge to other hardware vendors to get their act together and invest in VP9 to have it ready with/before/instead of H.265.
The second is an indication to developers that an ecosystem of an important browser and an important mobile platform are set on VP9.
Google has the technology and the digital footprint to try and force competitor’s hands from H.265 to VP9. And I think it is about to attempt just that.