Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
10 Questions for John Gruber Regarding H.264, WebM (osnews.com)
165 points by DavidAdams on Jan 12, 2011 | hide | past | favorite | 104 comments


First, these aren't 10 questions for John Gruber; it's 5 questions, with one of them phrased slightly differently 5 times, and another phrased two different ways.

Second, virtually all of these questions take as an axiom that H.264 is IP-encumbered and WebM/VP8 isn't. Technical analyses (by people who have actually implemented H.264 and are familiar with the patents) suggests that that simply isn't the case. That the author of this article thinks that VP3's release prior to H.264 might invalidate any part of the H.264 patent pool suggests that he may not be at all familiar with the patents in play.

Similarly, support for a "known patent troll" isn't germane to the debate if that patent troll is in the mix one way or the other, which appears to be the case.

Third, the fact that the H.264 patent pool hasn't been brought to bear on On2 tells us nothing at all about how successful H.264 would be against WebM; it's not at all unlikely that MPEG-LA sees nothing worth suing in Xiph/On2, and if that's the case, it is surely a different situation once Google pushes adoption.

Fourth, an "open pledge of support" for WebM from chip manufacturers is worth exactly nothing to the people who have spent many many hundreds of millions of dollars on mobile devices with hardware-accelerated H.264. One can reasonably argue that those people don't matter, but they can't with a straight face suggest that a "pledge of support" in any way mitigates the problem.

There's nothing wrong with this post as a contribution to the WebM/H.264 Apple/Google debate. But one gets the sense that the author sees it as some sort of devastating argument. I'm not sure he realizes that handwaving around "known patent trolls" and "decades of threats by MPEG-LA" and "is it because said codec isn't promoted by Apple", he's actually making a fairly weak sounding argument. He sounds emotional.

I'm gonna go with the analysis of the guy who said his B-frame implementation gave x264 the project's single greatest encoding quality improvement over the guy who thinks the release date of VP3 determines which patents encumber VP8, thanks.


By "people who have actually implemented h.264 and are familiar with patents", I assume you mean Jason Garrett-Glaser from his x264dev blog ( http://x264dev.multimedia.cx/archives/377 ). There aren't any patents explicitly mentioned, just that vp8 "feels" a lot like h.264. In that post, there was only one reference to a specific feature, the intra prediction, which was updated with "Update: spatial intra prediction apparently dates back to Nokia’s MVC H.26L proposal, from around ~2000. It’s possible that Google believes that this is sufficient prior art to invalidate existing patents — which is not at all unreasonable!".

The idea that VP3's prior release making AVC infringing is pretty stupid.


You make a valid point that I should have acknowledged. That said, what I'm doing is comparing this post, which seems deeply uninformed, to Garret-Glaser's post, which isn't.

I'm not expert on video patents either. The overarching issue is, this post seems to think the IP situation with WebM is virtually cut-and-dry, and we have every reason to believe it isn't.


I don't think "it probably infringes software patents in the US" is a reasonable argument against using a specific piece of software. Aside from the arguments against the legitimacy of software patents, it's practically tautological to say that non-trivial software infringes on patents, somewhere.


Here's the problem with that line of argument: while it may hold true for software patents, when it comes to online video one of the fastest growing categories of end-users are people viewing video on mobile and embedded devices. These devices use dedicated hardware to decode video without killing the available power budget. If there is anything behind the claims that WebM infringes upon MPEG-LA patents then you are not going to see the lawsuits drop until real devices are shipping with dedicated hardware decoders. Such devices are easier to nab at borders and by getting an injunction against the importation of these devices the MPEG-LA would also start the process with an action that will directly hurt the bottom-line of the alleged infringing party.


If I understand correctly, the h264 license would protect these device makers from lawsuits since the devices probably decodes both h264 and WebM. Thus they already have a license to the patents and the MPEG-LA can't do anything about them.


I don't think that's the argument being used. I think the argument is that there is no reason to believe that you are less likely to get sued for using WebM than if you use h.264. If you use WebM, there's just a bit more uncertainty about who will sue you.


To be fair, however, the OSNews post is questioning Gruber's post, which is at least equally if not more (and, IMO, it is more) misinformed, illogic, and ignorant.


> I'm gonna go with the analysis of the guy who said his B-frame implementation gave x264 the project's single greatest encoding quality improvement over the guy who thinks the release date of VP3 determines which patents encumber VP8, thanks.

Over both of those I think I'll take the implied legal opinion of the Google's legal team. In pushing WebM so strongly, Google obviously thinks it can withstand any attempted assault from the MPEG-LA. And unlike any of us or even Dark Shikari, they are lawyers who are qualified to make judgments about patent issues, and they know about exactly what hand Google is holding.


I'm sure Google's lawyers are good, but they aquired On2 in 2009. They've had barely a year to research On2's patents, prior art, and MPEG-LA's patents. As well as research the changes in VP8 (from VP6? the other allegedly unencumbered codecs) and compared them to H.264.


A year’s analysis from a legal team is probably preferable to a day’s analysis from a codec developer.


Exactly. And since Google has decided not to indemnify users of WebM, it would be logical to conclude Google's lawyers believe that MPEG-LA likely has a case. Otherwise, why not really get hardware developers on board with indemnity promises?


They’ve got hardware developers on board regardless of indemnification or not. It just takes time to develop silicon.


I'm aware of this. My point being is none of the other hardware vendors know if they're going to get sued until a potential patent submarine fires its torpedoes. Would you want to bet your business by being the first?


I think the assertion here is that Google would have researched their patents and prior art BEFORE actually buying the company (this is what the due diligence process is for). Google's only had a year go convert the VP8 code into open-source WebM code.


I'm absolutely certain that Google's legal team didn't begin studying On2's patents after the acquisition. There was probably at least another 6 to 12 months of analysis before the acquisition occurred.


Your hair-splitting over how many questions were actually asked draws the discussion away from some good questions.

Second, virtually all of these questions take as an axiom that H.264 is IP-encumbered and WebM/VP8 isn't. Technical analyses (by people who have actually implemented H.264 and are familiar with the patents) suggests that that simply isn't the case

Possible, but if the issue came down to 'an h264 developer with the technical chops' vs 'The due dilligence exercised by Google when acquiring WebM for millions and millions', I think I would lean slightly towards the latter.


On the B-Frame question, he actually missed the fact that VP8 has an analogue to the still patented B-Frame technique on the first go round. But he's since updated it after being corrected, so it seems a strange thing for you to pick up on.

Plus I think it was adaptive quantization that gave the greatest single improvement.


Sorry, was off the top of my head.


And since you've reminded me. I've seen Mr. Garret-Glaser argue several times that B-Frames aren't under patent any more and haven't been for a few years and that therefore the Theora devs are "retarded" not to use them. Clearly he's started listening to the people who were telling him otherwise since he notes it as a patented technique in that link but it's worth noting if you're holding him up as an expert in codec patents.


by people who have actually implemented H.264 and are familiar with the patents ... I'm gonna go with the analysis of the guy who said his B-frame implementation gave x264 the project's single greatest encoding quality improvement over the guy who thinks the release date of VP3 determines which patents encumber VP8, thanks.

I see this a lot. It purports that Jason Garrett-Glaser has done an expert analysis of all of MPEG-LAs patents and has proclaimed specific infringement by VP8.

Of course that's complete bullshit. His analysis was superficially that there are similarities, and thus there may be infringement. Not one actual patent claim was shown to be infringed upon, much less even referenced to show that there was any understanding of it.

His analysis was as a codec guy. Not as a patent guy.

The devil are in the details.

It turns out (ha ha!) that when people vying for standards lay their patent traps, they tend to be extremely specific, ensuring that they don't get caught by prior art (there is plenty), but that they trap anyone who implements the standard. See Microsoft ActiveSync patents as a perfect example of this.

Does WebM infringe patents? Almost without question, as is the nature of the ridiculously generous patent system. Just as h264 is almost certainly infringing on patents of other parties that just haven't come forward to make their claims yet (and for which a h264 license is zero protection).

But one gets the sense that the author sees it as some sort of devastating argument.

Just as Gruber's post was framed. Google supports Flash, therefore they can't possibly be open, therefore Google is closed, therefore Google is evil...or something like that. Preaching to the choir and all that so I don't think much critical thought is necessary.


Flash is demonstrably, prima facie closed. There's no argument to be had about it. Similarly, I'm not interested in litigating exactly how literate Garret-Glaser is about video IP if it's the case that this guy has absolutely no background in video. I can read press releases myself.

On the off chance that it's helpful, here's the author's bio:

My name is Thom Arvid Holwerda. I was born on the 1st of December in 1984, at the Medical Centre in Alkmaar, Noord-Holland, The Netherlands. Currently I live in Warmenhuizen, a small village a few miles north of Alkmaar (about 45 minutes by car north of Amsterdam). I've finished Latin/Greek school, and studied Psychology for two years at the Vrije Universiteit in Amsterdam (birthplace of MINIX); however, Psychology was not my thing, so I switched to something else. I'm now studying Information & Communication Sciences; a study which, other than the name might suggest, focuses mainly on language. About 50% of the study consists of studying a modern (to me) foreign language (Spanish, French, German, Italian or, in my case, English). My master will be Journalism.

You're right, Garret-Glaser isn't a patent attorney. On the other hand, he's an x264 developer intimately familiar with the standard.


> You're right, Garret-Glaser isn't a patent attorney. On the other hand, he's an x264 developer intimately familiar with the standard.

In other words, he's definitely qualified to comment how similar VP8 might be, which few people deny, and not very well qualified to comment how infringing VP8 might be.


MPEG LA was quoted last June as follows:

"MPEG LA doesn't favor one codec technology over another; we are like a convenience store that offers patent licenses for any number of codecs as a service to the market." (quoted in "Patent cloud looms over Google Web video plan," http://news.cnet.com/8301-30685_3-20006245-264.html?tag=mnco...)

Infringing or not, you may be like the local merchant who is forced to buy "insurance" to stay safe.


So, why didn't we see any action by the MPEG-LA and only ominous threats and some innuendo?

WebM is arguably the currently biggest threat to the goose that lays MPEG-LA's golden eggs. See also how they backtracked on royalties regarding web usage (even though you're still inviting a trojan codec into your home).

It reminds me at Microsoft's 250 or so patents over Linux, "but we won't tell you what they are, sucker"!

Put up, MPEG-LA, or shut up!


> So, why didn't we see any action by the MPEG-LA and only ominous threats and some innuendo?

Because if we did see action, we'd find out once for and for all whether their innuendo has anything solid behind it. It's the standard patent FUD process, aided by everyone who says "it's probably patent encumbered", "we don't know whether it's unencumbered".

It's much better to imply they can crush you rather than actually try to crush you and risk failure. And the best part is that by implying they can crush you but not actually doing so, they can appear to be exercising benevolent goodwill while the FUD does most of the crushing for them, risk-free.


Nobody thinks MPEG-LA is being benevolent. The world is not a comic book storyboard. MPEG-LA isn't going to invest in a patent suit that will cost both sides tens of millions of dollars until they're reasonably sure the investment will pay off. That isn't some Orwellian plot; it's simply good business sense.

The impression I get is that everyone who brings up the "but MPEG-LA hasn't sued anyone, just threatened, they're all talk!" objection also believes that lawsuits are straightforward and that any company with a couple mil in the bank can launch one at a moment's notice. It's true, companies can sue you at a moment's notice, because it doesn't much to sue you and there's little to lose. The situation is a lot different when it's MPEG-LA vs. a patent infringer plus the resources of everyone who would like to see the patent portfolio fail.


Let's elevate this conversation beyond the usual conventional wisdom and rhetoric: Flash is not "demonstrably, prima facie" closed. Really, `tptacek`, it takes almost no independent search to come to a murkier conclusion.

Interestingly, while the Flash IDE is most definitely closed, the SWF file format and the tools to create SWFs... it's not so cut and dry. Here's the (Flash 10 SWF Spec)[http://www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf...]

There's probably a bunch of stuff left out that'd make implementation difficult, but that hasn't stopped:

(GORDON)[https://github.com/tobeytailor/gordon] -- an open source Flash runtime written in pure JavaScript . It only supports up to Flash v. 2; almost useless, but interesting.

Here's the (Flex SDK)[http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK] which includes the Flex framework, and a partially open source SWF compiler.

Apparently, Flex compiler isn't totally open source because of patents concerning audio and video codecs (I'm recalling this off the top of my head; please verify).

Here's (Tamarin)[http://www.mozilla.org/projects/tamarin/]. It's a VM for EcmaScript. It's been rolled into SpiderMonkey, the JS engine for FireFox, I think. It includes support for packages, namespaces, classes, and optional strict typing of variables. Really useful stuff for interactive devs that, unfortunately, hasn't been widely adopted.

Adobe contributes to WebKit on behalf of Flash & Air; I don't know what their contributions have been/how useful they are, though.

I'm a professional interactive dev, and I specialize in Flash, so you might conclude that I'd be biased, and I wouldn't blame you at all. However, as a Flash dev, I'm familiar with the non-marketed vectors of the Flash environment. Take that as you will.

We're geeks: let's all invest a little time to investigate the rhetoric. If you really don't like Flash, pick another reason: there are many ;)


Isn't the "closed" vs. "open" status of Flash a total red herring? Flash is a browser plugin that any browser maker can choose to support or not to support. Google is arguing that a specified standard should use something more "open".

In other words, I have a hard time seeing how bundling a plugin and not supporting a proprietary codec that is vying to be part of a new standard is hypocritical at all.

And that above all seems to be the most important part of Gruber's "argument".

edit: minor grammatical correction


Give me a break. Flash is even less "open" than Microsoft Office. Both have published portions of their formats and semantics. But Microsoft Office at least has credible (if inferior) alternative implementations. What's the credible alternative to Adobe's Flash runtime?

And who gives a sh!t if Adobe makes contributions to open source? Contributions to open source don't make Flash open source.


Then by your definition Java is as closed as Microsoft Office?

ActionScript and Java are both published standards. Both have a canonical implementation which dominate distribution. Both are used as web plugins. Both standards are controlled by a single corporate entity.

Flash and Java are still free for end users and developers to use and distribute (alternative implementations are handled differently by Oracle & Adobe though).

The same can not be said for H.264. If i as a developer build an app that uses H.264 i have 0 confidence that i will not be sued in the future.


Sure ActionScript is an open standard, but Flash is not. The file format has been published, but has the actual swf format (including its streaming protocols) been ratified by an independent standards body? If so, which one?

Flash's file formats are well-documented, but Adobe decides how it evolves. I can write my own Flash player today, but Adobe might decide tomorrow that they're going to completely change Flash 11's format so that my player is suddenly useless for any new content. They might have even decided it already, and after a year of development, the first I find out about it is on release day. Anyone who's invested time and effort into implementing my player in their software is suddenly screwed until I support the new format (which, because of things like proprietary streaming protocols, I might never be able to do).

This is actually the same problem with WebM. The source code is open, but it's not a community project in the way that something like Apache or PHP is. Google is the one in control, and this is Google's standard. If they're interested in openness, are they going to be submitting WebM to a standards body? Because unless there's a published standard that everyone (including Google) has to adhere to, WebM is even worse than H.264 because there's no guarantee that the money you've spent today will bring you anything tomorrow.


OpenJDK? GCJ?


No Java implementation is unencumbered as Google is discovering with Dalvik (http://gigaom.com/2010/10/05/google-seeks-dismissal-of-oracl... ), and as the Apache foundation has finally resigned themselves to with the ironically named Harmony (https://blogs.apache.org/foundation/entry/the_asf_resigns_fr... ).


OpenJDK is the Sun (now Oracle) controlled distribution under open source terms. GCJ (which isn't really a "Java" as you'd normally think of it) was put on the backburner by RedHat once OpenJDK became available.


I would gladly accept an OpenFlash, even if the code is from Adobe, at least I would know what exactly I'm running on my machine.


I need a Flex developer to do some freelance work for me. Do you have any contact info? There isn't any listed in your profile. Sorry that this is off-topic, I just really need a Flex guy before the other lady gets a Flex guy and gets the Flex contract before me.


Well said.


Maybe I missed it, but I don't recall Gruber taking issue with the webM move, in and of itself. I read his posts as just being part of his continued critique of Google's pitching itself and its various business decisions as "open" and/or "good".

I mean that's been the recurring theme on that site re: corporate Google for years now. He's not throwing darts when Google does something in their own best interests. He's throwing darts when Google tries to spin those moves as being moves made in the interests of users, 'open development', free puppies and hugs for everyone, etc.


Yes and he also takes issue when Apple slightly improves a technology that's been available for years and markets it as "revolutionary."

Come on. It's marketing. Too many black kettles and pots to count.

edit: second paragraph of parent post has been slightly edited since I posted this. Originally it only mentioned "open" without users, puppies, and hugs.


Saying "We're the best" is qualitatively different than saying "We're the good guys".


And outside of poorly-written movies, the 'bad guys' never think they're bad guys. They always have reasons for what they do, and whether those reasons make sense to us or not, it's enough for them. Likewise, a lot of 'bad guys' lie because they think it's in everyone's best interests. For example, telling the public that there are WMDs in Iraq - it's a lie, but Saddam Hussein is dangerous so we need to lie to people so they'll support us, because otherwise they just won't understand.

I feel the same way about Google. They spend a lot of their time trying to convince people they're the good guys, except that, like any corporation, they're wholly self-serving. I find it less than difficult to imagine them having reasons that make them feel like the good guys, while those reasons would make us feel like they're the bad guys.

In this case, they're trying to cram WebM down everyone's throats, supposedly because it's better for us. They're doing so by removing support for de-facto standards in their browser, and talking up a lot of rhetoric about free and open standards, but what they're really doing is trying to move from a format that a consortium controls to a format that they control. Until they submit WebM to a standards body, I can't believe that this is all for our benefit.


I didn't intend to try and edit anything out from under you. My apologies if the difference in wording would have influenced your post.


No worries - I don't mind, but it made my post read somewhat different so I thought I'd mention it to explain.


To get clarity of thought on the debate, go back and read http://x264dev.multimedia.cx/archives/377

Everybody seems to be crying "but hardware support is coming soon!" without seeing it's difficult: "The unfortunate problem with this is that it’s a nightmare for hardware implementations, greatly increasing memory bandwidth requirements."

It comes down to WebM/VP8 being inferior (in specification and implementation) to an existing widely deployed (in bits and gates) codec.

Feel free to argue the fallacies of the osnews questions if your time is worth nothing.


Does anyone else feel it's weird that there's only one blog that everyone happens to link to whenever something related to vp8 springs up? It's been half a year, you would think there are independently arrived analyses by now.

Most people could probably agree that taking everything that John Gruber says as the truth without any other sources is a bad idea, but that's exactly the landscape of evidence presented for/against vp8. Thankfully, Dark Shikari's writeup is great, but there really needs to be more evidence.


It's strange everybody points to the same source, but it's not unusual there is only one source.

Break it down: How many codec developers do you know? How many of those people do open source implementation comparisons? How many of those write it up? How many of those write it up intelligently for public consumption?


Also, there are probably many people (myself included) who are familiar with implementation details of video codecs, but after reading Jason's articles decide that he basically said everything there was to be said.


It's been half a year, you would think there are independently arrived analyses by now.

I wouldn't think that. You can't swing a stick without hitting a run-of-the-mill CRUD application developer — and judging from the articles that come across the HN feed it looks like everybody and their dog has invented a programming language — but video codec developers don't grow on trees. Besides, 6 months isn't that long at the pace that field seems to move.


It is weird, in that I'd have expected the MPEG LA to produce or cause to be produced more FUD against VP8 by now.


There was no hardware support before H264 was widely used on the internet. Same for any other format in history. Mobile devices (which I guess you are hinting at) usually only support the Baseline profile which WebM does challenge. I don't see why there should not be hardware support everywhere in 1-2 years.


Mobile devices (which I guess you are hinting at) usually only support the Baseline profile

Is that true for smartphones? I know that the iPhone 4, iPod Touch, and iPad (at least) support "H.264 video up to 720p, 30 frames per second, Main Profile level 3.1"

I don't know about Android devices.


Gruber's post wasn't about being a proponent of H.264. It was asking why Google was being so hypocritical with (1) Flash still bundled in Chrome and (2-3) their flagship support of H.264 with Android and YouTube.

It's one thing to be a proponent of the open web. However, it is just amazing the length people will go to in this "debate" to justify Google's hypocrisy. This is a corporate strategy move aimed at controlling the market and jamming up Apple and it's hundreds of millions of devices that play H.264. Gimme a break.


These scenarios are just not analogous so there's no way to be hypocritical or not hypocritical.

On the one hand you have Flash, which has been around for ages and you can't just take it out without breaking a lot of the web. If someone found an open way to render Flash (like if Flash Gordon somehow got good enough to do it), I guarantee you that Google would remove Flash. They would much prefer this to having to bend over backwards to render it in a different process and blah blah blah. The only reason Apple was able to remove Flash was because they entered the mobile landscape, where having a browser that couldn't render Flash still rendered more of the "real web" than most competing mobile browsers at the time. However, you don't see them dropping support for it in Safari (and not including the plugin on some macs is not dropping support). If you couldn't run flash at all on a Mac, ever, it would be disastrous.

H.264 on the other hand is a brand new technology, there is still time to make the right move before we end up in the same position as we are with Flash today: everyone wanting it gone but it not being easy to remove it (similar to the GIF situation as well). On top of that Google controls the biggest video supplier of the web, thus they have the additional ability to make the transition less painful.


> On the one hand you have Flash, which has been around for ages and you can't just take it out without breaking a lot of the web.

Google does not need to bake Flash into Chrome. Somehow browsers have survived a decade without the need. Google's stance is bullshit corporate strategy. You bending over backwards to justify it is just comical.

> If you couldn't run flash at all on a Mac, ever, it would be disastrous.

For Adobe. It's not going to affect anyone's purchase of a Macbook just as it didn't affect anyone's purchase of an iPad.

> H.264 on the other hand is a brand new technology

Wrong. H.264 has been around for 7 years. It has hardware decoders in nearly every mobile device. It encodes 2/3 (and probably more now) of the web's video. It's used by almost every single major content provider.

It is WebM that is the new technology. Released 8 months ago to be precise. No hardware support yet (sorry, releasing VHDL designs doesn't count), almost zero content support, etc, etc. This isn't even close.

> there is still time to make the right move before we end up in the same position as we are with Flash today: everyone wanting it gone but it not being easy to remove it

Except no one wants H.264 gone. It's a high quality standard supported by devices everywhere.

> (similar to the GIF situation as well)

The GIF situation turned out fine. Thanks for the great counterexample to your logic.


> Google does not need to bake Flash into Chrome

Might I inquire where I can find Google Flash in Chrome? I only have Adobe Flash. Until you can show me a Google developed Flash, it's merely Google shipping an Adobe plugin, which is not the same as actively supporting H.264.


H.264 is not new. All those Flash videos? They're almost certainly encoded in H.264.


It's doubtful Gruber will address this, as it would be a bit like hammering a square (logic) into a circle (Apple).

My personal fav:

  If Apple were to switch to WebM and drop H.264 tomorrow,
  would you then herald it as a great move?
Most likely. PowerPC to Intel, anyone?


Apple moved away from PowerPC because it was increasingly becoming a vastly inferior technology. h.264 is not a vastly inferior technology.


Apple supported PowerPC for 2 years after the transition. Ignoring that fact, well said.


And PowerPC content (applications) worked fine on Intel Machines for years (and still does if you install Rosetta).

The same couldn't be said if Apple dropped support for H.264. Old content would cease to work immediately.


Well, you could use VLC or an application that does not rely on system codecs or quicktime, but you are exactly right.


"Are you aware of the fact that On2 released VP3 before H.264 was released (2000 vs. 2003), and that therefore, the MPEG-LA most likely infringes on On2 (now owned by Google) patents?"

That does not follow at all.

edit: I should say that it only follows if the patents in the patent pool apply exclusively/specifically to H.264.


I should say that it only follows if the patents in the patent pool apply exclusively/specifically to H.264.

And they don't. For example, "Method for processing decoded picture blocks in a block-based method of picture coding" was filed in '96 and granted in '99, and is part of the H264 patent pool.

There's a long list that goes like this.

MPEG-LA actually goes through great effort to show how each specific claim in the patent maps to a specific section in the spec: http://www.mpegla.com/main/programs/avc/Documents/avcCrossRe...


Your point is excellent.

The thing to remember is that when two systems each have patents, it's a false dichotomy to ask which set of patents trump the other. It's entirely possible that VP3 infringes on MPEG-LA patents _and_ H.264 infringes on On2/Google patents.

The chronology of the two is nearly irrelevant.


>The thing to remember is that when two systems each have patents, it's a false dichotomy to ask which set of patents trump the other.

Where is the false dichotomy?

The current talking point on the h264 versus WebM war is that WebM is a patent landmine, while your back is covered with h264. There is some sort of broad belief that h264 is a universal got-your-back patent defense, and that is simply ludicrous.


The false dichotomy is exactly as he said: that one or the other has to be infringing on the other.

As to your point, h264 has been on the market for a while now and is implemented by some seriously deep pockets. If you were the captain of the submarine patent ship, you would probably have fired the torpedos by now. If you're a new company, you'll feel pretty safe standing with Apple and all of the other MPEG licensees who have a vested interest in fighting. This is not the case with WebM.


The argument with the licensing fees for Mozilla to implement h.264 is probably a non-issue, and it doesn't do justice to frame it as such. The Mozilla Corporation does have a revenue stream (largely from Google) and MPEG-LA would probably be willing to allow Mozilla to license without paying the fees given their pivotal role in the fate of the de-facto standard. Operating systems often provide h.264 decoder APIs, like in QuickTime and Windows Media Player that they could use to circumvent the licensing fees.

Mozilla is doing it entirely out of ideology (and sticks to their ideology much more than Google usually does).


Mozilla has said [0] that they could pay the $5M/year but they won't because 1) it means content producers have to pay money to obtain licenses and more importantly 2) other people cannot create mozilla forks without licensing h264 themselves.

[0] http://shaver.off.net/diary/2010/01/23/html5-video-and-codec...


Ideology aside, what's the point? Like the article quotes, "if you are a company that gives away your product - how the hell are you supposed to justify paying for such a license when there is a perfectly good alternative that doesn't cost you money?"

Do you know how many engineers Mozilla can get for $5 million a year? Or how many ads they can buy for $5 million? Or how much beer? The point is- just because they have the money doesn't mean this is a good way to spend it.


Part of H.264 being a RAND standard (though not an "Open Standard" by the generally accepted definitions, since it's not royalty free) is that they can't cut special deals like that.

Don't get me wrong there's already special deals baked into the fee format (like maximum fee caps for the big insider companies that could move the market on their own if you pissed them off) but it is in some ways "non-discriminatory", which is the ND in RAND, which would stop them doing a deal.


Cool. How about licensing fees for Opera? For any other browser maker?


Why would Opera get a special deal? It's not like they make an open source browser. It seems misplaced to give handouts to a publicly traded company, with offices in ten countries, and who receive $80 million in revenues a year.


But that's exactly the point. You can give Mozilla special treatment, but that only underlines the fact browser makers will have to pay unless you specifically exempt them.


And for anyone, who will use Gecko/Xul-runner as a basis for their product?


"# 10 [...] If Apple were to switch to WebM and drop H.264 tomorrow, would you then herald it as a great move?"

I bet it would help, but I don't see Apple doing that anytime soon.

Currently, Apple uses PowerVR and nVidia chips for hardware decoding in iDevices and Macs, and those companies have already shown interest in building chips that offer WebM support. But Apple would have to find some way to support WebM hardware decoding on current devices, something like a Rosetta layer for video playback.

If Apple were to only include full support on new devices, it would feel the wrath of the entire tech press, not to mention organizations like Consumer Reports and Greenpeace. Apple only risks that kind of bad press when it's about a technology they've authored themselves.


I doubt Consumer Reports or the tech media would have much to gripe about WebM hardware decoding support being added to new iDevices, since there is no compelling WebM-exclusive content to which current device owners would be deprived access, (we'll leave Greenpeace out of this, as it's often difficult to rationalize their behavior). There is little risk to Apple's reputation with their customers by hedging their bets and including WebM support; only potential increased component costs, less optimal power consumption and patent litigation.

On the latter, I'd estimate the risk that the MPEG LA would go after an MPEG 4 licensee (and member of the MPEG organization) for violating the patents they have already licensed to be fairly slim; one might expect them to focus more on non-MPEG-licensed vendors distributing WebM decoders and encoders. So if the power usage and component costs are reasonable, there should be little obstacle for Apple.


The author's proposal is that Apple adopts WebM and drops all support for h.264.

That would mean that (amongst other things) all video content from the iTunes Store would have to be reencoded for WebM and the YouTube app on iOS would stream WebM instead of h.264. But that way, older Apple products won't have access to the majority of online video, or if Apple provides software decoding, battery life will suffer significantly.

I can't imagine Apple even considering such a move, but if they did, don't you think the press would have a field day?


The article's author was simply trying to make a point, not implying that Apple was in any way likely to actually drop support for h.264. The post I was responding to never addressed the possibility that Apple might do such a thing. Let's get real here.


I though that question was disingenuous. Gruber's big support was for Apple dropping Flash and supporting H.264. It's dangerous to argue about being "less" or "more" open, but I'm going out on a limb and saying that going from Flash to HTML5+H.264 is moving in the correct direction.

Moving from HTML5+H.264 to HTML5+WebM, or perhaps to supporting both, wouldn't be inconsistent with the switch from Flash to HTML5+H.264 they made with iOS.


If Apple were to only include full support on new devices, it would feel the wrath of the entire tech press, not to mention organizations like Consumer Reports and Greenpeace.

Not really, no. For example, h264 is hardware-accelerated on newer Macs (nVidia 320M / 330M), but not on the "old" nVidia 8600M-based Macs. The technical requirements are met (a 8600M is more powerful than a 320M), but Apple just won't release codecs.


I think he had the millions of iDevices in mind in that sentence.

A driver update isn't going to suddenly make iPads play WebM in hardware.


The point is that no one important is apparently objecting to lack of Apple back-support even when it's something something (relatively) simple like an x86 driver update for (relatively) expensive Mac hardware. There is no evidence they would take offense at lack of a firmware upgrade for comparatively cheaper iOS devices.


There's a world of difference between playing h.264 in software on an older mac and what playing WebM in software (or not at all) would do to iOS devices.


A firmware upgrade could conceivably allow iOS devices to play back WebM in 'hardware' just as they currently play back h.264 in 'hardware'.


No. Just no. Dedicated hardware is fast and efficient because it trades off flexibility for speed/power efficiency


h.264 and WebM are similar enough that it depends entirely on the implementation details of a "hardware decoder" as to whether it can handle one or both. Not all hardware decoders simply take in an h.264 bitstream and emit uncompressed a/v signals. Many "hardware" solutions are just a collection of execution units that handle the most time-consuming stages of decoding or encoding, and they are strung together with software and possibly use of GPU shaders to form a complete pipeline. For such devices, it may be possible to use them to accelerate WebM with most stages going through the fixed-function units and just a few things like entropy coding handled with compute shaders. Such a solution would be just as deserving of the "hardware accelerated" moniker as most of the decoding engines currently out there.


Yeah, I wasn't very clear in my first post. What I was getting at is that it is hardware that you can't reconfigure on the fly, which means you would have to choose between h.264 or WebM, you can't have both. For the next few years at least, the choice is clearly going to be for h.264, not webm


That dedicated hardware has no specific circuits with hardcoded decoding of specific formats. It is DSP with microcode and that microcode can be changed by updates.


Current PowerVR and NVidia chips support decoding VC-1 and WMA. Do you see this functionality enabled in Apple products? Why do you think they are going to enable WebM parts?

Similarly, Vorbis has been there for years. Why do you think Apple never supported it?


"Why do you think they are going to enable WebM parts?"

I don't. I think Apple will resist WebM for as long as they can. With h.264 support coming to Internet Explorer, I reckon Apple thinks h.264 is going to retain the majority of web users.

"Vorbis has been there for years. Why do you think Apple never supported it?"

Apple was the first to offer video on the desktop, I think they still consider themselves the authority. They have always preferred proprietary codecs (ALAC, AAC, h.264) over FOSS (FLAC, Vorbis, Theora), probably to keep control of their IP. I doubt that's going to change anytime soon.


The reason Apple "prefers" proprietary standard formats managed by standards bodies to open source codec projects is that the former actually have a chance at widespread industry device and software support, while the latter do not.


The author seems to want to frame Google's WebM move as a question of Good vs. Evil (as does Gruber btw.), which is not very helpful. As with most everything, there are both costs and benefits.

The main benefit is that Google's move may reduce the risk that the MPEG consortium goes crazy in the future, and starts to charge every possible user, causing havoc in the process.

The main cost is more certain: a huge inconvenience for content producers that were hoping to get away with going H.264 only, causing havoc in the process.

The interesting question is the usual one: is the benefit worth the cost?


I don't think Gruber is framing it as "good vs evil".

More - "why are you dropping support for H264 on grounds of openness but not dropping support for Flash (and MP3 and AAC) on those same grounds?"


The only problem I see is the iPhone and iPad.

All other browsers are open enough to get native support or have a plugin. Android phones will have support. Who knows or cares what happens on WP7...

Google is taking a stand. It is annoying that Google is removing existing support for h264. It will be annoying if Apple is completely against adding a software WebM decoder for current gen iOS devices, and ignore hardware solutions on next gen ones. But both companies are free to do whatever.

I also think this will have negligible impact in the real world. Youtube will always work on whatever. Content providers can just upload stuff there if they don't want to manage multiple formats themselves.


I may feel more sympathetic to the author of these questions, but they are ultimately just as rhetorical and passive-aggressive as Gruber's - i.e. not a particularly useful contribution to the debate.


With mobile being more important in the long run than desktops, and Android gaining ever more importance over the iPhone, we just need Google adopting their open codecs in both Android hardware and YouTube, and it's game over for h.264.


Yes, most definitely, I mean who would want to cater to a giant install base of people who you know actually buy software and are willing to pay a premium for UX.

Google cant put hardware into most Android devices because they don't make them. Heck, you can barely upgrade your Android software on most carriers/devices. Google should first figure out how to prevent carries/manufactures from installing crapware on their handsets.


Well, the upcoming generation of mobile chipsets supports VP8. Tegra 2, for example, supports both decoding and encoding of VP8.


I hadn't heard that (and thought I'd been paying attention), so if anyone else was doubting vetinari, here's a link:

http://www.nvidia.com/object/tegra-2.html

Claims decode for Theora, VP8 and Vorbis, as well as encode and videoconference for VP8.

Basically every Android tablet at CES was Tegra 2 (I think it's the reference platform for Honeycomb) as well as a few of the high-end phones e.g. Motorola Atrix


11. Why are you quoting random conspiracy theory Slashdot comments to support your take on H.264 vs. WebM?

http://daringfireball.net/linked/2011/01/12/slashdot-comment


Because they contain a nice argument? Duh!


Ugh, I'm so sick of seeing arguments to or from Gruber. He's like a constant Apple soap opear. Google is a business and they're allowed to make decisions. Switching to WebM saves them money, pushes their codec, and their users (Chrome) lose ZERO functionality. Google obviously feels that this switch is beneficial to them and their users in the long run. If you disagree, don't use Chrome.


Those who forced you to click the link have been sacked.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: