Microsoft: IE9 won't block VP8 video, won't build it in either
In a pair of blog posts released simultaneously this afternoon, Microsoft's Internet Explorer General Manager, Dean Hachamovitch, walked on eggshells in explaining why his group is staying the course with respect to its decision on the H.264 codec in IE9. This in the wake of Google's historic move today to release the VP8 video codec it acquired under a full open source license under the umbrella title WebM, even though it could mean legal action against Google down the road.
"The issue of potential patent liability is 'ultimately for the courts to decide,'" wrote Hachamovitch in one post, citing an Engadget article from earlier this month. Reaffirming his company's commitment to the ideals of HTML 5 -- whatever those may be today -- he stated at two points, "IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows."
When one parses the sentence for the fact that Hachamovitch did not mention the user needing to install an H.264 codec on Windows (although Silverlight does provide such a service), one may conclude that the way one enables Internet Explorer to play any VP8 video will actually remain unchanged from today. Microsoft may not be distributing the VP8 codec itself with either IE or Windows Media Player, so IE users (along with Apple Safari users, most likely) will find themselves downloading the codec separately. Though it's too early in the game to say for certain, Google could probably establish a portal for such distribution, maybe even through YouTube.
In a second blog post, gently but very deliberately, Hachamovitch addressed what he characterized as "the uncertainty" over H.264 and HTML 5 by explaining that IE9 will be open in its acceptance of third-party plug-ins that offer functionality above and beyond HTML 5. Notice how that casts VP8 in the "other" category.
"Of course, IE9 will continue to support Flash and other plug-ins," Hachamovitch wrote for IEBlog. "Developers who want to use the same markup today across different browsers rely on plug-ins. Plug-ins are also important for delivering innovation and functionality ahead of the standards process; mainstream video on the web today works primarily because of plug-ins. We're committed to plug-in support because developer choice and opportunity in authoring web pages are very important; ISVs on a platform are what make it great. We fully expect to support plug-ins (of all types, including video) along with HTML 5."
Hachamovitch noted that while Microsoft is a participant in the licensing group MPEG LA, which manages the portfolio for H.264, it actually loses money in the process, making back about half of what it puts in. "Microsoft pledged its patent rights to this neutral organization in order to make its rights broadly available under clear terms, not because it thought this might be a good revenue stream. We do not foresee this patent pool ever producing a material revenue stream, and revenue plays no part in our decision here," he wrote.
The general manager's comments came a few hours after the posting of a detailed technical analysis of the VP8 codec by Jason Garrett-Glaser, the principal developer of the competitive x264 codec -- an open source technology that produces video compatible with H.264. The long post shares valuable information that Garrett-Glaser may not have been able to share before today.
Though generally balanced throughout, Garrett-Glaser opens up his dissection of the VP8 specification (as opposed to the software itself) with a noise familiar to readers of the comic strip "Peanuts," usually found whenever Lucy yanks the football out from Charlie Brown's feet. Prior to several pages of extremely thorough explanation as to why, he suggests that merely open-sourcing the spec may not be enough: "The spec 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 points to areas where VP8's overall performance is at least competitive with, but sometimes less than competitive with, both H.264 Baseline Profile and VC-1, the standard previously advanced by Microsoft. In his closing, he makes one very ominous, though perhaps acutely accurate, statement: "With regard to patents, 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."
Betanews has been advised to await a forthcoming statement from MPEG LA, which may address precisely this point.