Google’s untenable hubris on H.264
Google has announced on its Chromium blog that it will be dropping H.264 support in its Chrome web browser in favor of the VP8 compression technology used in the WebM standard. H.264 is the most popular and widely supported video compression standard in the world. It is used in all the major standards like Blu-Ray, Adobe flash, Apple products, and Microsoft Windows and enjoys a wide array of hardware support. By comparison, VP8 and the WebM standard is only getting started and lacks support in nearly half of the web browsers in the world while H.264 is currently supported by all the web browsers. If you use VP8 mode on Google’s YouTube, you’ll see your CPU consumption and battery life decline because graphics hardware isn’t optimized for VP8 but H.264 hardware acceleration is near universal.
From a strategic standpoint, Google’s hubris seems to be untenable. Even though Chrome will be removing support for H.264 which means H.264 is no longer universally supported, Chrome presently only accounts for 10% of the web browser market and they are in no position to strong arm the market the way Apple strong armed Adobe Flash with its iPad product. If push comes to shove in the choice between compression standards, web developers can simply ask their visitors to switch to an “H.264 compliant web browser” like the default Microsoft Internet Explorer or Apple Safari already installed, or use something like Mozilla Firefox for best quality viewing. For those who insist on using Chrome, they’ll simply have to view the video using the older VP6 compression standard implemented in Adobe Flash. It’s a tough sell getting developers to support a third video encoding standard.
VP8 was originally marketed to be a superior video compression technology to H.264, but real world performance and quality has shown to be worse than H.264. Even if Google optimizes VP8 to be on the same level of H.264, that’s not a compelling reason to abandon all the hardware and software support for H.264. A video compression developer noted:
“Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.
VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.”
Google also argues that its Vp8 technology is an “open standard” not encumbered by intellectual property, but a patent pool has already formed against Vp8 which means VP8 will likely be violating dozens of existing pattents. One developer noted that there were many similarities between VP8 and H.264 and stated:
“VP8′s intra prediction is basically ripped off wholesale from H.264: the “subblock” prediction modes are almost exactly identical (they even have the same names!) to H.264′s i4x4 mode, and the whole block prediction mode is basically identical to i16x16. Chroma prediction modes are practically identical as well. i8x8, from H.264 High Profile, is not present. An additional difference is that the planar prediction mode has been replaced with TM_PRED, a very vaguely similar analogue. The specific prediction modes are internally slightly different, but have the same names as in H.264.”
This is alarming to anyone looking to implement VP8 because Google does not indemnify anyone from patent lawsuits. That means anyone using VP8 could be held liable for any patent damages. H.264 on the other hand is already paid for and H.264 for free streaming was made permanently free. That means the choice for me will be simple and the day Google Chrome dumps H.264 is the day I will uninstall Chrome.