View from the Peak
I’ve been waiting a little to mull over Google’s announcement about dropping H.264 support in Chrome in favor of VP8. Although my partner Ben Mesander would take the other side of the argument, I think the world needs VP8 like a fish needs a bicycle.
A little background: The HTML5 standard specifies a new
<video> tag, which in theory can be used like the existing
<img> tag to embed a video into a web page without the need for any specific browser plugin. (Prior to HTML5, all web video is played in a browser plugin of one form or another, with Flash—despite Apple’s best efforts to kill it off—being by far the most prevalent.)
The problem with the
<video> tag is that HTML5 didn’t really go far enough; it didn’t specify a list of codecs that had to be supported, and it also didn’t specify a streaming format (meaning, among other things, that you can’t send live video to a client using the
<video> tag; you’d still need a plugin for that). The
<video> tag also didn’t support any form of digital rights management—and regardless of what you feel about this, it’s a necessary precondition for distribution of most of the video people actually want to watch.
Up until Google’s announcement earlier this month, however, it appeared that H.264 would emerge as the de-facto common codec supported across all browsers, much like JPEG is a common image format that is supported by all browsers using the
<img> tag. Now Google is pulling the rug out from under H.264 in order to push VP8.
First off, the importance of this announcement has been overblown. Even if we all agreed on the use of H.264, the
<video> tag was always going to be of limited use because of the other problems I listed.
Still, the Google announcement is a shame, because for both consumers and producers of content—i.e., most of us—the combination of H.264 and the
<video> tag would have been a step toward making it easier to distribute video content on the web. Now that there will be no standardized way to send video to all the common browsers, we’ll be continuing to use plugins (and, thus, more complex servers for video). I bet the guys at Adobe are happy!
There have been a few reasons given (by Google and others) for this decision, but none of them hold water:
- Supposedly VP8 is more “open” than H.264. Google’s four-paragraph announcement used the word “open” eight times (with the implication being that VP8 is somehow more open than H.264), which is a denial of reality worthy of an Iraqi information minister. H.264 was created in the very definition of an open committee process. It is a joint standard endorsed by two international standards bodies (the ITU and ISO/IEC). Both the specification and the patent licenses needed to implement it are available to anyone on the same terms, so the playing field is level.
Meanwhile, VP8 was not developed in an open committee, but by a small team at On2 before Google acquired them. Google has recently put out a specification, but the specification has the odd disclaimer that “If there are any conflicts between this document and the reference source code, the reference source code should be considered correct.” So really the specification is Google’s source code, but that has a bunch of x86 dependencies, so good luck porting it to another architecture or making an ASIC that you know is correct.
- Supposedly VP8 is “free, as in beer”. The slightly more interesting claim about VP8 is that Google is offering all the patents needed to implement it for free; whereas with H.264 there is no guarantee that the patent holders will continue to make it free for web video. The problem with this claim is that it would only work if Google could guarantee they owned all the necessary patents for VP8, and I would be very surprised if that’s true. The patents in the MPEG LA licensing pool are relatively general, and VP8 isn’t all that different from MPEG-2 and H.264; all are based at some level on the discrete cosine transform followed by a form of entropy coding. So I guess it’s theoretically possible that On2 could have devised their codec by looking at all the existing patent literature and somehow avoiding all the patent claims … but I’m really skeptical. (If Google really thinks VP8 doesn’t infringe any of the MPEG LA patents, they could indemnify everyone who uses VP8. Don’t hold your breath.)
- Supposedly VP8 is a more efficient codec than H.264. This claim, made initially in the original On2 press release announcing VP8, is just pure hogwash, debunked for instance here. VP8 fundamentally has fewer “tools” than H.264, as a quick glance at the relative length of the two specifications will tell you. Moreover, H.264 represents the fruition of many years of research, performed by a lot of smart guys at a lot of companies around the world. (Those patent royalties that the open-source zealots hate so much certainly can motivate a lot of R&D!)
I’m not saying we can’t eventually improve on the performance of H.264—far from it. But the low-hanging fruit is gone. I’ll lay my money that further improvement in compression efficiency will come in the form of a lot of small, incremental enhancements, from a lot of different sources.
- Supposedly VP8 is less compute-intensive to decode. This is probably the one claim that makes sense: VP8 is based on integer arithmetic and is specially designed so that a decoder can use the special SIMD instructions present in all x86 CPUs to decode the picture. Whereas H.264 decoding, if performed in software, can still stress a lot of CPUs. However, I doubt this particular benefit of VP8 is commercially relevant.
Ultimately I think this whole controversy is a case of Google starting to act like a big technology company. (Mark your calendar: They’ve jumped the shark.)
Here’s a simplistic analysis: Small technology companies focus all their energies on building a great product for their end users. They don’t have any strategy beyond “build a better mousetrap”. And if they succeed at that, they get to become big technology companies.
Big technology companies, on the other hand, have their fingers in a whole lot of different pies. They often make decisions where they compromise the quality of their product in one market segment in order to further some other strategic interest. Microsoft wrote the book on using dominance in one area to advance other goals. Apple did this same thing recently when they picked a fight with Adobe’s Flash. And now Google is reducing the usefulness of Chrome in order to push VP8. (Presumably the ultimate motivation is to force MPEG LA to keep H.264 basically free, in order to benefit YouTube?)
Now, Google Chrome is a great browser. It’s my main browser, and it is likewise popular in a completely unscientific straw poll of other propeller-heads I know. The thing is, it’s pretty easy to switch browsers; the only persistent data in most browsers is your bookmarks, and those transfer readily from one browser to another. And since your current browser choice is not very “sticky”, Chrome is a not a great stepping-stone for Google to launch its war for world codec domination: The instant that major websites stop working in Chrome, you’ll see a whole bunch of people switch to another alternative.
UPDATE (Feb. 2, 10:30 AM): It looks like Microsoft has taken up the pro-H.264 side of this debate.
One Response to “We Need VP8 Like a Fish Needs a Bicycle”
Post a Reply
Cardinal Peak offers fast, ultra-reliable engineering services for Digital Video & Audio, Embedded Devices, and Mobile & Set Top Apps. Focused on increasing our clients' engineering ROI, we complement their internal resources with project-based contract engineering, ongoing engineering services and onsite staffing.
Receive Cardinal Peak Updates
Sign up to receive periodic posts from our partners and senior engineering staff in email.
Why should my company outsource engineering services? What should we look for in a provider?
"Cardinal Peak was a natural choice for us. They were able to develop a high-quality product, based in part on open source, and in part on intellectual property they had already developed, all for a very effective price."
Bruce Webber, VP Engineering, VBrick