Posts Tagged ‘standards’

How does interoperable video recover from Chrome dropping H.264?

I don’t know that it does.

It’s essentially inconceivable that the rest of the world — particularly once you move beyond the browser — is going to ever adopt WebM, so any dream of a universally interoperable video format is right out the window. The best possible outcome we can hope for now is that the major browser developers will all support WebM, and we’ll have one video standard for the web, and one for everything else. And that’s not a very good outcome at all, really, compared with the kind of ubiquitous video compatibility we could have achieved.

Even that limited victory seems pretty remote. It would require Apple to support support WebM in Safari and on its mobile devices, despite the fact that Google dropped H.264 in large part just to piss Apple off. And it would require Microsoft to support WebM, despite Google being an arch-rival. It was hard enough to get Microsoft to support H.264, a neutral open standard. What are the odds they’ll ever support WebM?

Google has just thrown away the last, best hope for truly interoperable video, and ruined web video for the foreseeable future. That might sound apocalyptic, but it’s hard to imagine how things could develop otherwise.

Why is Google dropping H.264 support?

Ditching H.264 serves two strategic purposes for Google. First, it advances a codec that’s de facto controlled by Google at the expense of a codec that is a legitimate open standard controlled by a multi-vendor governance process managed by reputable international standards bodies. (“Open source” isn’t the same thing as an “open standard”.) And second, it will slow the transition to HTML5 and away from Flash by creating more confusion about which codec to use for HTML5 video, which benefits Google by hurting Apple, since Apple doesn’t want to support Flash.

It also, of course, really sucks for consumers.

This move is, in other words, a thoroughly nasty bit of work. It’s not quite as bad as selling consumers down the river to Verizon on ‘net neutrality, but it’s close. And if Google is actually successful in making WebM, not H.264, the standard codec for web video, they’re literally going to render hundreds of billions of dollars worth of tablets, smartphones, set-top boxes, etc. with H.264 hardware support obsolete.

“But wait!”, the OSS fans are saying. “Isn’t Google really standing up for freedom and justice, because H.264 requires evil patent licensing?”

No. Expert opinion is that WebM infringes on numerous patents in the H.264 pool, and will need a licensing pool of its own to be set up, just like Microsoft’s VC-1 did. So the patents are a wash. This is Google manipulating the market entirely for selfish advantage here, and it’s all the worse because they’re pretending otherwise.

A recap of Google duplicity on H.264/WebM

Google has announced they’re dropping support for H.264 in Chrome because their own WebM is “more open”. This is, essentially, a lie. Let’s recap.

H.264 was developed by the Moving Picture Experts Group (MPEG) and the Video Coding Experts Group (VCEG), which are standards committees that draw members from industry and academia under the umbrella of the International Organization for Standardization (ISO) and International Telecommunication Union (ITU), which are (in practice) intergovernmental public/private partnerships. It is governed by a public, multi-party governance process representing many different stakeholders.

This is how a real open standard works.

Does H.264 require patent licensing? Yes. But that’s not because (as some people seem to believe) it was developed by some company that licenses it out to make money. Rather, it requires patent licensing because it turns out that a lot of the techniques you’d want to use in a modern video codec are patented, so the standard that MPEG/VCEG developed (basing their decisions largely on technical considerations) ended up infringing on a bunch of them — about 1000 patents in all, in fact. As is common with such things, a patent licensing pool was set up to make licensing all of those patents cheap and easy for implementors.

It is extremely unlikely that WebM does not infringe on some of those very same patents. It’s a very similar codec to H.264. Moreover, this has happened before. Microsoft’s VC-1 codec was supposed to be a patent-free alternative to H.264, and guess what? It ended up requiring a patent licensing pool as well.

So, with H.264 you get a codec that’s an actual open standard, with a formal multi-party governance process and with easy patent licensing. With WebM, you get a codec that’s not formally standardized, has no formal governance process (and is de facto controlled by Google, because they employ most of the developers), and that has huge ‘submarine’ patent risk.

Google, somehow, has the gall to claim that the latter is “more open”. And a lot of people seem to believe them.

What Google is up to with WebM/VP8

There are three reasons to introduce an alternative to H.264:

  • It’s technically better.
  • It doesn’t require patent licensing.
  • You want more control over web video than the multivendor H.264 standardization process provides.

VP8 isn’t technically better than H.264, and it will almost certainly have the sort of patent problems that will require a licensing pool to be set up, just as with Microsoft’s VC-1, another attempt at a patent-free H.264 alternative.

That means what Google is after is control.

Google has played the PR game masterfully here. The release of VP8 is being hailed as a victory for openness. Meanwhile, if VP8 were to actually displace H.264, then instead of a codec controlled through an ISO standardization process involving dozens of vendors, you would have a codec controlled almost entirely by Google.

Advocates of open computing need to think really, really hard about what’s going on here. A lot of them seem to have declared for Google (and against Apple) because of a couple of fairly trivial technical points with no long-term strategic relevance (Android runs apps that aren’t from its app store, etc.), and some clever rhetoric on Google’s part. But the paradigm that Google wants for the future of computing — cloud-based apps running on Google’s servers — is no more compatible with openness than Apple’s vision of appliance-like computing devices.

In fact, it’s less compatible. Apple’s devices can at least be jailbroken; the cloud can’t be. And Apple doesn’t seem interested in having access to all of your data, whereas Google’s cloud-based vision for computing would involve them having access to all of your data, and Google’s business model, based around targeted advertising, creates an incentive for them to know as much about you as possible.

Google’s release of VP8 codec changes little

I’ve previously discussed the dustup over Ogg Theora vs. H.264. Today Google announced it is releasing the VP8 codec as open source. VP8 is an ostensibly patent-free codec which, unlike Theora, is said to be as good, technically, as H.264. But it won’t change much.

Most of the case against Theora didn’t come down to its technical quality, but the fact that H.264 is a standard that extends far beyond just web video on desktop platforms, and there was no way Theora plausibly had a chance in that larger world. The same logic applies to VP8.

The Mozilla Foundation and Google can implement VP8 in Firefox or Chrome or whatever. But let’s look at, say, Netflix. Right now, they can serve the same H.264 streams up to desktop platforms via Silverlight, to iPads (soon iPhones and iPod Touches), to the PS3, to the Nintendo Wii (as of this month), to Roku boxes, to the Xbox, to various Blu-ray players….

Most of those devices implement H.264 decoding in hardware, and their vendors couldn’t add VP8 decoding to them if they wanted to. And they mostly don’t want to, because H.264 licensing is pretty cheap, and they don’t care about the ideological arguments against it. It uses the same kind of licensing regime used by MPEG-2 (DVD), Audio CD, ATSC digital broadcast… the industry is very comfortable with this model.

So, what is a company like Netflix supposed to do? Keep two copies of its entire library, one in VP8, for Firefox, and one in H.264, for every other client platform in the world? Because the Mozilla Foundation has some ideological objections to software patents, and so refuses to implement H.264?

Right. Good luck with all that.

Had VP8 been around (and open source) five or six years ago, things might have been very different. But H.264 has already achieved critical mass. It simply won’t be displaced by another current-generation codec. If people want a patent-free codec to eventually emerge on top, they should start thinking about how to build a patent-free next generation codec, and get it ready for prime time before H.264′s inevitable MPEG-LA-licensed successor is ready.

Ogg Theora Advocates: get over it already

So Google is planning to do a revamp of YouTube, and Slashdot is talking about it. The most-requested feature is, of course, the replacement of Flash with HTML5 video.

Slashdot being a rather popular destination for open source types, the discussion immediately breaks down into the controversy over whether HTML5 video should be delivered via H.264 or via the Ogg Theora codec.

Sorry, guys, but for anyone who isn’t obsessed with software licensing, the answer here is is obvious. Theora’s a substantially inferior codec, with a handful of implementations mostly in non-mainstream open source software. H.264 is an extremely good current-generation codec implemented by… the entire rest of the world, basically. Game consoles, phones (including both the iPhone and Android platforms), iTunes, set-top boxes, cameras, Blu-ray… H.264 is everywhere.

Despite the Mozilla foundation siding with Theora for Firefox, H.264 is the only remotely plausible choice here. Apple probably couldn’t support Theora on the iPhone if they wanted to, because the iPhone’s video decoding is handled by dedicated hardware, and as far as I’m aware there is no such hardware for Theora, and nobody plans to produce any. And Apple is far from being alone here; the same applies to most embedded devices.

H.264 implementations do require license fees to be paid under certain conditions, yes. But this puts it in the same boat as Audio CD, MPEG-2 (the standard codec on DVDs), MP3, AAC, and numerous other media standards. By demanding not only an open standard, but a codec that requires no patent licensing, open source advocates are holding web video to a standard that has essentially never been met, and are, in fact, effectively standing in the way of standards-based web video.

If the Mozilla foundation doesn’t want to license the relevant H.264 and AAC patents, they should at least let Firefox use QuickTime to handle HTML5 video content in those formats. Anything else puts abstract idealism over real-world interoperability.