What could possibly go wrong?
The knee jerk reaction to Google's announcement was to ask whether Microsoft and Apple would immediately jump to support the new codec, given that the two companies offer the default choice in web browsers to nearly all desktop users, and given Apple's strong influence over mobile devices.
Speaking to journalists, Microsoft offered to "support" the new codec as long as users installed it themselves, leaving reporters to wonder aloud if Apple (which has not commented on the issue) would also allow its Mac users to install their own codecs, as it always has for the last twenty years. Mac users can already install Ogg Theora within QuickTime; it's just that Apple doesn't do this for them because doing so would open the company up to patent assault.
Ars even wondered in print if Google would take the "nuclear option" and cut off support for viewing H.264 videos in YouTube to force the world to use its new VP8, killing off all support for YouTube on existing mobile devices. The site also suggested that Apple was a major intellectual property holder in the MPEG H.264 patent pool, and therefore that it gets royalties from the use of H.264 that would prevent the company from being interested in free, open alternatives.
Apple is not a codec vendor
However, Apple has never been a major codec developer. While the ISO's MPEG-4 adopted Apple's QuickTime container file format as the basis for the standard MP4 container in 1998, that was a contribution by Apple, not something that could or has generated significant patent royalties.
If Apple had a bunch of proprietary codec technology to push, it wouldn't have made a splash about licensing the third party Sorenson codec for QuickTime 3.0 back in 1998, when that codec was among the world's most advanced. Apple continued to license subsequent Sorenson Video codecs through QuickTime 5 in 2001, in an effort to distinguish its media platform as the best way to present and view video.
But Apple then began to focus its resources on supporting the open development of the ISO's MPEG-4 codecs, leaving Sorenson to licenses its proprietary codecs to Macromedia's Flash. Macromedia also licensed On2's VP6, which became the preferred codec for Flash starting with version 8 in 2005. In contrast, Apple relegated the Sorenson codecs into a bin of legacy codecs within QuickTime, pushing MPEG-4's H.263 codec and later the more advanced H.264 in QuickTime 7.
The commercial development of video codecs was moving so quickly that Apple saw value in pooling the top technology company's video expertise together and licensing it all in one place from the ISO's MPEG LA, an independent entity with no bias toward any particular company.
With digital video playback standards having moved beyond the desktop computer and into embedded and mobile devices, video games, disc players and other applications, it was no longer in Apple's best interests to have an exclusive proprietary codec in QuickTime anymore. Instead, Apple prefers open standards in video codec technology, just as prefers open standards on the web, where proprietary encroachments like Adobe's Flash can only complicate its efforts to build its hardware products.
That means that while Apple is listed as a patent owner by the MPEG Licensing Authority, it is not primarily Apple's technology that is being licensed by any stretch of the imagination. The actual video technology comes from the hardware component and software makers that have always been part of MPEG, including Bosch, Dolby, Ericsson, Frauenhofer, Fujitsu, Hitachi, Philips, JVC, LG, Mitsubishi, Panasonic, Samsung, Sharp, Siemens, Sony, and Toshiba.
Even Microsoft, which has developed far more technology in the area of video encoding and decoding than Apple, says it earns about half as much from H.264 royalties compared to how much it pays to the MPEG LA in order to use the pool's technology. Apple is clearly not supporting H.264 because it is getting rich doing so. If there were some openly available, free alternative to the advanced video technology being collaboratively developed by all the world's advanced video experts, Apple would happily use that.
The problem is that the patents are already filed, and there isn't any acceptable, free technology that can be used that is not subject to respecting those patents. The only way to get the world's most advanced video technology is to pay for it.
Or you can steal it
After Apple began shifting its desktop computers and mobile devices toward the open (but not free) H.264 specification, it started to become apparent that alternative proprietary codecs were often simply open MPEG-4 specifications with some improvements made to them.
Sorenson Video 3 was revealed by an anonymous developer's reverse engineering to simply be a tweaked version of H.264, while Microsoft's competing Windows Media Codec, once published by the SMTPE under the name VC-1, was also revealed to be largely derived from MPEG standards, a revelation that limited Microsoft from substantially profiting from VC-1 royalties.
Now, Jason Garrett-Glaser (also known as Dark Shikari) an independent developer working on the x264 open source project (which encodes H.264 video) has discovered the same thing about Google's new VP8, branded as WebM. Garrett-Glaser says he "was able to acquire access to the VP8 spec, software, and source a good few days before the official release and so was able to perform a detailed technical analysis in time for the official release."
At issue are three points: how good is the VP8 specification (the published explanation how its technology is supposed to work), how good its its implementation (the code provided to actually do the work) and how likely is it that VP8 is really safe from patent issues.
On page 2 of 2: VP8 is a mess.
"The spec," Garrett-Glaser says, "consists largely of C code copy-pasted from the VP8 source code â up to and including TODOs, 'optimizations,' and even C-specific hacks, such as workarounds for the undefined behavior of signed right shift on negative numbers. In many places it is simply outright opaque. Copy-pasted C code is not a spec.
"I may have complained about the H.264 spec being overly verbose, but at least itâs precise. The VP8 spec, by comparison, is imprecise, unclear, and overly short, leaving many portions of the format very vaguely explained. Some parts even explicitly refuse to fully explain a particular feature, pointing to highly-optimized, nigh-impossible-to-understand reference code for an explanation. Thereâs no way in hell anyone could write a decoder solely with this spec alone."
Garrett-Glaser noted that "On2 claimed [its VP8 encoder was] 50% better than H.264, but On2 has always made absurd claims that they were never able to back up with results, so such a number is almost surely wrong. VP7, for example, was claimed to be 15% better than H.264 while being much faster, but was in reality neither faster nor higher quality."
The VP8 implementation is a mess
"Irrespective of how good the spec is, is the implementation good," Garrett-Glaser asked, "or is this going to be just like VP3, where On2 releases an unusably bad implementation with the hope that the community will fix it for them? Letâs hope not; it took 6 years to fix Theora!"
Other commentators have also noted that Google is largely just releasing code that it obtained without doing the work to actually make it high quality or easy to use, assuming that once the code is available, developers in the community will fix it. But that strategy has rarely worked. Mozilla's failure to fix and release anything functional other than portions of the Netscape web browser over the last decade is a notable example. The majority of Netscape's code, including Communicator, collapsed along with its big plans to deliver XUL as a platform and brand out into mail viewers and media players.
Garrett-Glaser launches into an in-depth technical analysis of VP8, describing the limitations in the design of VP8 while noting many similarities with H.264. Among his conclusions:
"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." (H.264 has multiple profiles, each acting as a a separate encoder, making the "standard" really a broad family of related encoding standards, each suited to a particular task. Baseline is for web or mobile applications, Main is targeted at standard definition TV, and High applies to high definition applications such as Blu-Ray.)
"VP8, as an encoder, is somewhere between Xvid and Microsoftâs VC-1 in terms of visual quality. This can definitely be improved a lot, but not via conventional means.
"VP8, as a decoder, decodes even slower than ffmpegâs H.264. This probably canât be improved that much.
"VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.
"VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoderâs interface is lacking in features and buggy. They arenât even ready to finalize the bitstream format, let alone switch the world over to VP8."
Outlook not so good
If Google can rapidly improve upon the VP8 codebase and specification, and can push chip makers to incorporate support for the new codec immediately, it is possible that Apple will eventually support the new codec in its products.
However, the similarities with H.264 suggest that the real technology licensees behind the world's advanced video processing technology aren't likely to give Google a free pass at erasing their revenue streams. While Apple is largely neutral in this issue as a minor player in the codec business, there are many major players who are going to test the new codec before anyone in the industry with deep pockets is likely to buy into Google's new plans.
That's why Microsoft isn't offering any voice of commitment supporting the free new codec, and why Apple is not likely to get involved unless Google can promise to take the heat by indemnifying all of its partners from patent attacks.