By Daniel Eran Dilger
Published: 06:00 PM EST (03:00 PM PST)
The VP8 specification 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.
return to previous page
