No double standards: supporting Google's push for WebM
fsf.org
fsf.org
The fact of the matter is that Flash is an entrenched, defacto standard and isn't going away any time soon. HTML5 isn't anywhere close to completely replacing Flash even if it were to disappear in a puff of logic right this moment.
HTML5 <video> is in its infancy, and isn't being perpetuated by sheer momentum like Flash. Further, H.264 was a complete non-starter for Mozilla, and Firefox holds nearly 20% of the market. Using H.264 for HTML5 <video> would have guaranteed market segmentation and hurt the chances of a truly open future.
This argument about dropping H.264 propagating Flash in the short term is just insanity to me. Flash is already here for the short term. We need to focus on our long-term options for moving to something more open, and the whining about this decision strikes me as totally myopic at best and blind fanboyism at worst.
I agree with your comment, and I find the Flash/H.264/Chrome argument to be childish at best.
However if we're talking "childish", then the "Plugins! I thought the point of HTML5 was to avoid plugins" argument wins by a mile. People, including Google, have been pushing HTML5 via various plugins, fallbacks and shims for a good while (e.g. Chrome Frame, Google Gears, Flash Vorbis decode, Java Theora decode etc.)
Which doesn't challenge anything I said. In fact, you can remove plugins from you browser, including Flash, right now.
So Much For Standards, Google Says WebM Plugins Coming Soon For Safari And IE9
Sorry for the confusion.
=)
The big distinction here is that it will be native to the browser because IE and safari use whatever codecs are in the OS instead of providing their own.
You just simply cannot deny the audacity of Gruber's comments about WebM/H.264/Flash. They are completely self-serving.
I think if Gruber allowed comments on his blog, or had to talk about WebM vs. H.264 in an engagement, he'd have trouble shoving the pro-H.264 side of this debate down people's throats.
While he occasionally makes some valid points, Gruber tends to pick and chose which articles to post that'll support his esoteric rhetoric.
My only wish is that we identify the difference between tribe-mentality and logical necessity.
cookiecaper said it best here: http://news.ycombinator.com/item?id=2105570
He hasn't recanted this complete acquiescence, so I am under the impression that he sincerely believes them - and only on the grounds of that single release.
Maybe he was biased, too cute for his own good, had a brain fart, or is too stubborn to accede. I really don't know, but this is one case where I can't really blame Gruber haters for framing his writing and philosophy in a certain way.
[1]: http://www.businesswire.com/news/home/20100825006629/en
[2]: http://daringfireball.net/linked/2010/08/26/h264
[3]: http://shaver.off.net/diary/2010/08/27/free-as-in-smokescree...
(Fixed a typo: "thought" to "thoughts". Don't read anything into it!)The last one I remember was when he spent weeks snarking about how Google was somehow being dishonest about not using private APIs in Android. The reality was Gruber hadn't spent 5 minutes looking at the intro to the Android SDK document, and fundamentally misunderstood how Android is architected. What really made it ridiculous is that he kept on with it after having been corrected on the matter, with one of those corrections coming from no less than Tim Bray.
Basically, Gruber is great when he sticks to Apple analysis; when he strays into discussing the competition he tends to enthusiastically dig himself a hole.
EDIT:
Here's that response from Tim Bray I was referring to:
http://www.tbray.org/ongoing/When/201x/2010/05/06/Private-AP...
Gruber was conflating internal datastores with private APIs. The official Android SMS app uses public APIs and then stores messages in its own internal datastore. Bray was cautioning app developers that they shouldn't access that store because the SMS app is not part of the core framework, can be replaced by other applications, and is not guaranteed to be there on all devices as a result.
Gruber managed to turn that into constant snarking about Google lying about only using public APIs.
The most irritating thing about the h264 rant is that there are some valid points in there: content producers would have to encode content twice, lack of hardware decoding, pushing video back to Flash, proprietary nature of VP8's development. But these all seem like short-term problems to me. Hardware decoding will happen and Flash will support WebM.
The biggest long-term sticking issue to me is Apple. They have a lot of weight to throw around with iPhones and iPads, and it seems h264 is unavoidable there. Google could throw its own weight around by switching all of YouTube to WebM, but that would take some time as hardware and software catch up. In the meanwhile, Apple is selling millions upon millions of h264-only iOS devices.
And there's the patent issue too. It'd be nice of Google indemnified WebM, but they also have enough patents that they could cause problems for MPEG-LA too.
http://www.quirksmode.org/blog/archives/2011/01/2010_mobile_...
Your argument turns on Gruber hating Flash for being closed. He doesn't: He hates Flash because he thinks it's crap. Gruber is not an open source advocate. He has no objection to open standards, free software, or open source software, but they aren't his passion.
You're right that Flash is an entrenched, defacto standard. It is, however, much less of one than it was three years ago, and that's pretty much entirely due to one factor: iOS doesn't support it. The HTML <video> element has traction entirely due to the fact that it's the only way to play video from a web page on an iOS device. You don't have a choice between <video> or Flash: It's <video> or nothing.
Chrome dropping H.264 support isn't going to push adoption of the <video> element, because Flash continues to be a perfectly valid alternative method of providing video to Chrome. If Chrome dropped H.264 and Flash, that'd be a different story.
Gruber's position is entirely consistent: He supports moves that reduce the usage of Flash, and doesn't support ones that increase it. Google's choice to drop H.264 in Chrome will, in the short term at least, result in the latter. Acknowledging this fact is neither myopic nor fanboyism.
So is this debate about what's best for the future of open standards on the web, or is it about what's best for iOS?
>short term >myopic
S: (adj) short, shortsighted, unforesightful, myopic (lacking foresight or scope) "a short view of the problem"; "shortsighted policies"; "shortsighted critics derided the plan"; "myopic thinking"
http://wordnetweb.princeton.edu/perl/webwn?s=myopic
Sounds like exactly what I meant. It's focusing on short term consequences at the expense of long-term benefit.
As I said, dropping H.264 may result in the already entrenched Flash being used more in the near-term; in the long term it could help HTML5 <video> see better overall adoption.
Who says it needs help?
Dropping support for h.264 means slower adoption of <video> How's that better for the open standards? The most infuriating part of this is, that FSF and Google are so busy with their own agenda, that they forget users.
20% of the browser market was never going to adopt H.264. That's a fifth of the market cut out from using <video> entirely.
How in the world is that possibly good for web standards?
>The most infuriating part of this is, that FSF and Google are so busy with their own agenda, that they forget users.
That majority of the market has the entrenched Flash until HTML5 <video> gets sorted out as a standard everyone can use.
20% and dropping... Should we also stop the <video> train in its tracks because IE6 does not support it?
Neither.
The debate is about what's best for the web, period. Some people consider open standards to be a priori superior. Others (like Gruber) do not. (I'm taking your usage of "open standard" to include freedom from patent encumbrance.)
Your last statement is a critical point in this debate: You assert that Chrome dropping H.264 support "could help HTML5 <video> see better adoption." This is not an uncontroversial statement, to put it mildly.
I frankly don't see how this move will aid adoption of the <video> element. Yesterday, sites could encode to H.264 and provide a <video> element to some browsers and a Flash container to others. Today, the same is true. Yesterday, sites could encode to both H.264 and WebM. Today, the same is true. The only thing that has changed is that the number of browsers that require a Flash wrapper to play H.264 content has increased.
Sites will potentially use the <video> element over a Flash container for several reasons:
* If they cannot use Flash. This is the case on iOS devices. iOS has done more to drive adoption of <video> than any other factor to date.
* For political reasons. Dropping H.264 support from Chrome will not change this; a site that avoids Flash because it is not free was presumably already encoding to WebM.
* Because the <video> element provides a better end-user experience.
For sites where this third case applies, dropping H.264 support may result in increased usage of WebM. However, note that this is not the same as increasing adoption of the <video> element--dropping H.264 may influence the codec choices of sites that have already chosen <video> over Flash, but it has no influence on sites that are willing to use Flash.
I would be interested to hear your arguments on how dropping H.264 could increase usage of the <video> element in the long term. I just don't see a case for it.
I do see a case that dropping H.264 might increase adoption of WebM. I am, however, dubious. So long as H.264 in a Flash wrapper is a viable fallback, I don't see any site choosing to encode to WebM as a result of this change. (Sites may choose to encode to WebM for other reasons--preference for freer standards or freedom from licensing fees--but in these cases, they would encode to WebM even if H.264 was available in Chrome.)
So, to summarize: You are trying to frame the debate in terms of freedom alone. It is entirely valid to prefer freer technologies and to make decisions based on freedom. This is not, however, the only possible debate, and it is not the debate John Gruber is engaging in. To accuse him of hypocrisy in supporting H.264 but not Flash is to misunderstand his argument.
It's very simple - a significant share of the browser market was never going to support <video> with H.264. In which case you end up with a fragmented market and everybody's using wrappers like Flash anyhow.
Of the available formats, WebM is the one most likely to eventually get everyone on the same page. Without that, <video> never really becomes a standard.
It's been posted elsewhere in the thread several times, but if you have a few minutes, this is probably the single best article I've seen on the whole mess:
http://antimatter15.com/wp/2011/01/the-ambiguity-of-open-and...
If MS jumps on board, which wouldn't shock me at all, you've got 90% of the browser market signed on.
What would aid adoption of <video> is if there was a single codec that all browsers supported. That requires that browsers add codec support, however, not remove it--either Firefox and Opera would need to add H.264 support (unlikely), or the various platforms that don't support WebM would need to add it (impossible in some cases, since the hardware support isn't there).
Because given a sufficient timescale, WebM support in <video> might become ubiquitous. I've made it very clear I'm talking long-term, not tomorrow.
>What would aid adoption of <video> is if there was a single codec that all browsers supported.
There is a chance for this to eventually happen with WebM. It was never going to happen on any timescale with H.264. My point is simply playing on probabilities.
> (impossible in some cases, since the hardware support isn't there).
People keep harping on this, and while it may be unfortunate that some devices get left behind, as I've posted elsewhere in the thread, mobile currently only represents 3% of web traffic. The mobile web is still very much in its infancy and there's still plenty of time for things to change, even fundamentally in some places.
I feel like we're talking in circles here. How does dropping support for H.264 make WebM support in other browsers more likely to become ubiquitous? How would retaining H.264 support make WebM support in other browsers less likely to be so?
WebM doesn't have the same problems that were keeping that last 20% from adopting H.264. With Google, Mozilla, and Opera, you've got about 30% of the market on board with WebM already. If Microsoft can be convinced to adopt WebM (and, honestly, I don't think that's too much of a stretch), that's around 90% of the market signed up.
If that happens, your only holdout is Apple, and I think even Apple is going to have a hard time stonewalling the change given the way they've spent the last year preaching the wonders of the open web.
So, basically, what I'm getting at is that with WebM, there's at least a chance everyone could end up settling on a ubiquitous codec. With H.264, we already know it would never happen. An unknown probability greater than zero is a better prospect than a p=0, in my book.
>How would retaining H.264 support make WebM support in other browsers less likely to be so?
Fragmentation. <video> isn't a useful standard unless you know it's going to work. Some browsers supporting one codec and others another makes that impossible.
If everyone supports WebM, then WebM wrapped in a <video> element is a viable choice.
Not everyone supports WebM at the moment.
How does Chrome dropping support for H.264 bring us closer to everyone supporting WebM? Support for the two codecs isn't mutually exclusive. Google is no more on board with WebM today than they were yesterday--they've removed support for H.264, not added it for WebM.
They've made it very clear the intention is to add it. I've said it's not happening overnight, and I really don't understand this attitude that if it hasn't happened instantly then everything is worse.
They've made it very clear the intention is to add [WebM]. I've said it's not happening overnight, and I really don't understand this attitude that if it hasn't happened instantly then everything is worse.
Chrome supports WebM right now.
Support for WebM and H.264 is not mutually exclusive. You can support one, you can support the other, or you can support both. That's what Chrome has done up until now: Support both. You could use either one, and it would play them back perfectly well.
Chrome is not adding support for WebM. They aren't adding support for it, because they already support it and have done so for as long as it existed.
Switching to a world in which everyone supports WebM in <video> tags does not require that a single browser drop support for any format--not H.264, not Theora, not anything.
The bottom line is that while a subpar technology, Flash is really not that crappy. It delivers rich content without any glitches to millions of desktops every day and while its implementation on phones is still not great, there is no technical reason why it won't improve to the same level we see on the desktops.
Here is why Flash is not going anywhere: the anger against it is not strong enough nor shared by enough users. Most web surfers are pretty happy about it, and as long as that doesn't change, Flash won't die.
This has nothing to do with Apple "crippling" Flash or anything like that either; if anything, Adobe has been improving the Mac version of Flash since before Apple started publicly ragging on it. They've still got quite a ways to go though.
Not entirely:
Let me be clear, though: there is nothing wrong with playing a video in Flash. I mean that seriously, no sarcasm. What there’s something wrong with is requiring Flash Player to play video. That’s the whole point of the HTML5 <video> element: to enable web video without requiring the use of proprietary plugins.
From http://daringfireball.net/2011/01/practical_vs_idealistic
Except Internet Explorer will continue to be the highest-marketshare browser for the foreseeable future, and IE9 won't ship with VP8 (though you can install a codec for it, I doubt regular people will). It does ship with H.264.
Maybe Microsoft can be convinced to ship VP8/WebM in IE.
I certainly wouldn't discount it. MS made the H.264 decision well before Google announced WebM. It wouldn't shock me to see them cut a deal with Google if for no other reason than to put Apple at a competitive disadvantage.
Which means, somewhat surprisingly, that IE could be 3rd globally in the relatively near future. In fact the IE drop/Chrome rise appears to be accelerating, so it could happen sooner.
http://gs.statcounter.com/#browser-ww-monthly-200812-201012
But that's all versions of IE, IE9 won't be available on XP, and historically it's taken years for new versions to penetrate, so it'll be a much weaker force than Chrome and Firefox which complete updates in a few weeks and months respectively.
Microsoft getting on board would be nice, but Adobe getting WebM into Flash would take care of the older versions of IE that are hanging around too.
The best possible outcome of this exercise (and to its credit perhaps this is Google's intention) is for MPEG-LA to make H264 royalty free in perpetuity, which would eliminate the need to switch to WebM. Otherwise we're forced to make a whole bunch of currently useful devices a whole lot less useful in the interest of one day making a (by then) obsolete codec into a universal standard.
We need: 1 - Google to publicly put out a strong message (has already happened) 2 - iOS to support WebM (yet to happen) 3 - IE, and others to support WebM. MS has pledged support in IE 9; Safari will follow iOS. Firefox will. 4 - YouTube to gradually switch content from Flash to WebM. Maybe HD content is only going to be available in WebM for starters. Google can do a gradual switch over a course of 5 years or something.
So: Yey, Google! Even big evil companies can get it right sometimes.
Note also that Google, as the owner of YouTube, can kind of strong-arm everyone into supporting WebM. And by everyone I mean Apple which has a traditionally high resistance to any technology it doesn't control (or at least has a say in).
I'm glad somebody finally figured out how to accurately describe webm. All this hand-waving talk of 'openness' and 'open standards' was debate poison.
http://www.webmproject.org/about/faq/ "One of the goals of having this code licensed as liberally as possible is to encourage adoption by as many users as possible. This includes both proprietary and free software. Using the GPL license would not be a good match for this goal."
The WebM issue is far from black and white. I still haven't figured out which side I agree with more. What I do know is that a lot of people are arguing tactics. This is a battle between corporations and everybody should be taking 100 steps back to try to figure out the strategies at work on both sides.
Edit: What I'm alluding to in my last point is a lot like Paul Graham's point in this essay from a while back: http://www.paulgraham.com/submarine.html
Stallman himself agreed that it was a good thing for Xiph to relicense their libraries from the LGPL to a permissive free software license (http://lists.xiph.org/pipermail/icecast-dev/2001-February/00...):
In response to the change of license, Richard Stallman of the Free Software Foundation says, "I agree. It is wise to make some of the Ogg Vorbis code available for use in proprietary software, so that commercial companies doing proprietary software will use it, and help Vorbis succeed in competition with other formats that would be restricted against our use."
If we switch to WebM, we have one less "patent encumbered" in there (maybe). I'm not impressed with the "free Web" argument.
The only thing that could achieve such a thing would be a device with iOS levels of popularity that a) doesn't support h.264 b) doesn't support Flash. Who is going to make such a device? A: Nobody, because it won't support any web video at all apart from maybe YouTube.
You can grouse about open principles all you want, but the big video producers don't care; they will not be a factor. Audience demand is the only thing that matters, and they won't demand WebM when h.264 is already working "fine".
When Google decides to take the internet TV business away from people like Netflix - remember they are an advertising company - they want their own codec to avoid any arguments.
Are they going to do that? No chance. Some day, maybe, but they're not going to lead the way.
And while YouTube is still additionally serving h.264, there's still no pressure for everybody else to change.
For example: make all h264 encoded clips on youtube become grayscale while mantainig the vp8 ones high quality and in color. People would not be prevented from watching youtube on iDevices, but watching it on those devices would be like watching an old black and white tv :)
And when people start flooding apple feedback and support channels with "why my youtube lost its colors on my ipad?" questions, then maybe Apple can add vp8 support on iOS.
Apple supporting both vp8 and h264 would continue to be the company with the best mobile devices, but if they don't embrace the open unemcumbered format that firefox, opera, chrome and youtube uses they will be giving an either/or kind of choice for mobile consumers, they would be making them choose between hollywood and youtube, stating that their costumers cant have both.
This is not an iOS vs Android argument (though many have tried to make it so), all of the current devices chose H.264 as their primary codec because when they were being designed and developed that was the only logical choice.
Someday it will be replaced, but it will take a technically better standard. WebM is not technically better. Take a time machine and send WebM back about 10 years, and it has a shot. Without a time machine, it is too late.
The problem Google and the FSF face is that very few really care about having everything be free in the FSF's sense of free. Heck, even among Linux users, who you'd expect would be the most receptive of wanting everything to be free, very few run the truly free distributions, with no non-free modules or drivers. The vast majority are not even on Linux. They are on Windows and Mac, and so have no qualms about using non-free stuff.
To convince people they need to switch to something that is technically inferior, they need to be shown a problem that actually affects them. H.264 being subject to patent licensing in those countries that recognize software or codec patents is not a problem that can be shown to affect most web users or most web video producers, at least in a way they care about. The royalty free license for distributing free video on the web, and the high thresholds before license fees kick in for video producers, ensure that the vast majority of us never do anything that requires coughing up any money, and that takes the problem off most people's radar.
So like it or not, those freedom freaks are entitled to have a say to how things should work. They are too big part of an ecosystem to be ignored.
To me, Google's move is an indication that Google will eventually drop and/or downgrade Flash support.
You encourage institutions to do the right thing by applauding when they do the right thing. Not by saying "you suck because you didn't take it far enough". You say "Good move doing X. And when you do Y you'll be doubly awesome."
> H.264 is a patent-encumbered codec; the MPEG LA organization requires developers who implement it to agree to a patent license. This license is fundamentally incompatible with software freedom. It requires developers to restrict how their software can be used, and to collect royalties in many situations.
While the wording is not perfect, this is actually about end user freedoms and convenience. There's the same situation is with parts of ffmpeg/libavformat or libmad - you just can't ship and use them completely legally. This is why "restricted formats" notion appeared, and why Ubuntu started shipping Fluendo's non-free encoder binary (http://www.fluendo.com/shop/product/fluendo-mp3-decoder/, previous-to-last paragraph).
It was always a problem (albeit, nowadays, minor one) to use proprietary codecs on GNU/Linux systems. Problem not on developers' side, but the for the actual end users. Killing H.264, thus actively encouraging WebM support helps WebM to win the formats battle. In a short term, both end users and developers will experience compatibility problems, but in the end - if WebM will win - both end users and developers will benefit.
And please remember that we have Firefox, which - due to various FLOSS reasons - just won't support H.264 anyway.
It's Adobe Flash, not Google Flash. It was Google implementing H.264 in the browser. You can still add a plugin to support H.264 in Chrome if you wish, just like you can remove the Flash plugin from Chrome. Essentially, the Google/H.264/Flash argument isn't logical. Essentially, it's like complaining that Apple doesn't ship Flash on iOS devices. It's a bad argument. Just because some ordinarily smart people are making the argument doesn't make it a good one. I cannot stress how bad of an argument it is.
> The practical result of playing H.264 to Chrome users via Flash instead of through a native open source implementation (Chromium) is surely a net negative for free standards supporters?
It's the status quo, but with a brighter outlook then before.
Google can, therefore, flip a switch and turn everything to WebM. They just need broad support in place first.
If Google says they will switch YouTube to WebM gradually, then all the browsers and devices will need to support it. End of story.
Then it's just up to Apple whether to turn it on. Google appears to be laying the groundwork it can now so that the answer is more likely to be yes.
This will take a few years to play out.
Chrome's support doesn't make an immediate difference to you or to content publishers. Firefox doesn't support H.264 <video> either and has larger market share. So rest assured that no soldering gun is suddenly needed, and you can continue to use H.264 on your iPhone 4.
Google's groundwork is supposed to come to fruition years from now, when you find an iPhone 5 or 6 already in your pocket.
True. But FSF calls to abandon support or h.264 altogether. I don't see how that helps me.
a) may be able to persuade your vendor (Apple) to support webm in your device,
b) for the time being, you are going to watch low-resolution, low-bitrate version of youtube. All higher quality streams will be webm and you can return to point a).
Any further questions?
After all, not needing a Flash wrapper is a hollow victory if your open source player can't legally decode the content. The content standard is the major battle. If that is won, getting rid of the Flash video wrapper is a trivial effort in comparison.
The scenario that everyone will just continue to use Flash with H.264 is assured only if nothing else changes. But Flash adopting WebM will change the support numbers dramatically, and being the odd ones out in not supporting WebM is the only way that Apple and MS would feel any pressure to follow suit.
Regular people don't care, nor do they need to. Browser makers (Apple, Google, Mozilla) and content publishers (YouTube, BBC) care intensely, and are driving the entire controversy. All have a significant financial stake. Sufficiently large content publishers like Google/YouTube and the BBC have been motivated enough to invest heavily in open source codecs themselves. Supporters and detractors of Flash are fanning the flames.
> We applaud Google for this change; it's a positive step for free software
Except that it further entrenches Flash in the short to medium term, possibly longer.
> Most of it is delivered with Flash, which is proprietary, nonstandard software.
Exactly. H.264 isn't going away anytime soon so having a Web browser without Flash gets that much harder. With no native support for H.264 in Firefox or (soon) Chrome, bizarrely the most Flash-unencumbered browsers are Safari and Internet Explorer.
Consider that for a moment: Internet Explorer.
> Free software alternatives like GNU Gnash are available, but the user experience isn't always as seamless as it ought to be.
This is a key point but not in the way the author intended and it's worth parsing this statement. The FSF is driven by philosophy here but most users aren't. If you want to attract a plurality of users a necessary precondition is to have the experience be as good if not better than what you're contesting.
There is a cost to switching: finding new tools, learning a new process and so on. Users need a reason to switch and ephemeral arguments about "openness" of video on the Web just don't cut it for the majority, at least not while such a choice comes with a subpar experience.
> In order to make sure the Web stays free for everyone, we need a free codec to prevail as the de facto standard with HTML5.
Like most future specters I believe this one is overblown too. Everyone points to the GIF fiasco. The net result? PNG was born. If the screws are ever put to us on H.264, you'll see exactly the same thing, only quicker. Computing power being what it is today, the effort of re-encoding every video that exists on the Web is actually not that hard of a problem, and is certainly in the realm of what Google can do today, let alone 5-10 years from now.
> WebM can be that codec: Google provides a patent license with the standard that is compatible with free software licenses
But it should be noted, there is no indemnity against H.264 patent infringement. I'm not saying WebM violates H.264 patents. The reverse may even be true (or both). But the point is that it is a risk.
> We can only be free if we reject data formats that are restricted by patents.
The elephant in the room here is that the fundamental problem is software patents. They need to be completely abolished.
> But the issue's not settled yet.
No but it's a bit like iPad vs the rest of the tablets. The issue isn't settled yet, but the iPad has a whopping lead and the smart money is on it for some time to come. H.264, like it or not, is more mature and has more hardware and software support than WebM, which is far less mature.
Only because Microsoft and Apple choose not to support WebM. Prior to Google's choice, Firefox (with rather significant browser usage stats) wasn't supporting H.264 either, which kept Flash on the web. Also, people keep referring to IE, but it still needs Flash. Sure, IE9 is coming, but we'll see what the adoption rates will be like.
Point is, Google throwing out H.264 didn't change the short or medium landscape much.
> Everyone points to the GIF fiasco. The net result? PNG was born.
You completely miss the point. GIF is a lesson, and we should learn from it. More importantly, PNG wasn't adopted over night. You can't just flip a switch and make everything alright.
> If the screws are ever put to us on H.264, you'll see exactly the same thing, only quicker.
Or, you can avoid the entire problem, put effort into free formats now. Don't repeat past mistakes.
> The elephant in the room here is that the fundamental problem is software patents. They need to be completely abolished.
Yes. Supporting them doesn't help matters.
When they made their choice WebM wasn't an option because it didn't even exist yet.
Microsoft might be a different issue, but Apple has now shipped almost 150M devices with hardware h.264 support and no webm support at all.
> You completely miss the point. GIF is a lesson, and we should learn from it.
GIF is completely irrelevant to the issue at hand (or, if you want to reach for it, WebM is actually more at risk of a GIF-type scenario than h.264)
IE9 is still in development. They can still choose to support WebM.
Apple could still choose to WebM support.
The point isn't that Apple and Microsoft can choose. Rather, you can't expect to ask Google to support H.264 and not ask Microsoft and Apple to support WebM. Apple and Microsoft don't want to support it. Fine. Google doesn't want to support it. Fine.
Neither H.264 and WebM are written into the standard. Fine.
Let the competition begin. The best technology that meets all the needs of the various groups will win.
> GIF is completely irrelevant to the issue at hand (or, if you want to reach for it, WebM is actually more at risk of a GIF-type scenario than h.264)
No, and no. I'd explain more, but I can't follow your logic. (Nor do I really want to try. Sorry, but you seem far too emotional about the topic. I'm probably wrong, but your comment comes off that way).
In fact, Imagination Technologies, the people who make the GPUs for the iPhone(and the iPad as well, I think), have already announced full vp8 support in their next-gen hardware decoders, so it would be really easy for Apple to include webm support in the next iPhone or the one after that. And they're safe from any patent threats as well, since they're already MPEG-LA licensees. It will be interesting to see if they do.
And Matroska support. Building container parsers that are resilient to fuzzing attacks is non-trivial. Can I assume you'd like trick play (ffw, rew, scrub), too?
Trick play is already implemented. If you have to do major rework of that area to support a new format, you're doing it wrong.
I was talking with a friend yesterday and mentioned how hilarious it'd be if Microsoft decided to adopt WebM on WP7 and then attack Apple for being too closed. :)
I just can't help think of the OOXML debacle.
Not in any meaningful way: as far as I know, there is no hardware decoding support for WebM in production. That leaves 150M iOS devices dead in the water, and a bunch of Macs having to decode HQ videos in software instead of relying on existing, well-supported and well-understood hardware.
> The point isn't that Apple and Microsoft can choose.
Apple and Microsoft also have been investing in h.264 for a long time. They're the least likely players to be able to change and (especially Microsoft) they're not very good at turning on a dime.
> you can't expect to ask Google to support H.264 and not ask Microsoft and Apple to support WebM
Why not? Google already had h.264 support, h.264 is the current leading video standard and enjoys wide support across the board, from hardware to software, from embedded to full-blown computers.
> No, and no. I'd explain more, but I can't follow your logic.
So you'd explain why I'm wrong even though you don't understand what I say? Original.
> No, and no. I'd explain more, but I can't follow your logic.
You'd explain why you disagree with what I say even though you don't even understand what I say?
Uh... right.
It's very simple:
And when WebMx is released, everybody will hound those who don't immediately change their product strategy to fit this. This is also a good reason for why Apple isn't using WebM: it's not a standard, it's as controlled by Google as Flash is controlled by Adobe.
They're essentially giving a bunch of control of their device to an outside company.
Their own site says "dedicated to developing a high-quality..." which, taken literally, means that the project is still underway. Also listed on the front page: "Submit patches and improvements" Yet again, saying that it's a work in progress.
For H.264/AVC, it was less than 4 years from the first draft to final ratification. It was a joint effort of ISO and ITU-T.
Still, if that's too slow, SMPTE seems to go faster when they start with an existing codec. VC-1 and VC-2 (a profile of Dirac) were both done there.
Realistically Google should not revoke your licenses unless you lose the lawsuit (not when filed), because if they have legitimately infringed your patent then it seems like blackmail to keep them from acting on it by such a method.
Could you imagine MS saying in their Windows license agreement saying that they can revoke your licenses if you sue them over a patent?
Google's position is literally... screw with us, and if WebM catches on, you can't do video on the internet.
I guess as long as Google is pushing the technology that "you" like they can do no evil.
Google did due diligence before buying On2 with VP8. They did patent search. If anyone appears now with some patent claim against VP8, suing left and right users of VP8, it does not show good faith on their part.
"This license is fundamentally incompatible with software freedom. It requires developers to restrict how their software can be used, and to collect royalties in many situations."
And that is what it is all about. H.264 imposes end-user licenses and if it gets entrenched, freely redistributable browsers would lose. The argument against dropping H.264 is basically "why switch formats when what we have works?". H.264 does not work for free software. It's as simple as that. If HTML5 video suffers in the short term, that's the price we'll pay - at least that's the FSF's position.
>Everyone points to the GIF fiasco. The net result? PNG was born. If the screws are ever put to us on H.264, you'll see exactly the same thing, only quicker.
Why wait until a fiasco?
> Computing power being what it is today, the effort of re-encoding every video that exists on the Web is actually not that hard of a problem, and is certainly in the realm of what Google can do today, let alone 5-10 years from now.
Seriously, you're arguing against yourself here. Besides, what of the omnipresent 'hardware decoders' we keep hearing about?
That's the market segment that the baseline profile was conceived for, but the phone in my pocket and the tablet on my nightstand both support the main profile. Sure, most content that I view on it is probably encoded in baseline, but there are 17 million iPads in the wild that support the main profile. Edit: it's not just iOS devices, either. The Playstation Portable supports the main profile too. There are around 62 million of them out there.
VP8 needs to skate to where the puck is going to be, as it were.
Seems strange that the iPhone 4 got better specs so shortly after (much like the 256MB memory). I'm sure they'll fix it in the next rev though, which just increases the chance that rev. 1 devices will be served Baseline.
edit: I just checked and the iPhone's only 720p Main Profile too? I'm confused now, I was sure iPhone 4 went to High Profile.
Interesting. Which mobile device(s) did that, and what decoder chip(s) did they use?
"VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”
I believe this was written before the update that acknowledges that VP8 has a partial analogue for B-Frames (which aren't present in Baseline H.264).
Another quote:
"The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264"
I guess it's arguable what he actually means because he's not explicit but I read both quotes together (and indeed the whole piece) as saying the VP8 spec is better than the H.264 Baseline spec. Whether that translates in the actual encoders, depends mostly on the particular H.264 encoder.
According to the FSF's definition of software freedom. The FSF has quite a radical view in this regard. A Microsoft exec once described the GPL as "viral' [1] and it's a fair point. Many view licenses like MIT and Apache as being more free simply because they're not as restrictive.
This ambiguity is more pronounced when you use words like "open" because it means different things to different people.
So it would be more accurate to say that H.264 is incompatible with the FSF's idea of software freedom.
> if it gets entrenched
What do you mean "if"? It already has.
> Why wait until a fiasco?
Because anyone who writes software knows that writing code to solve problems you may never have is a recipe for wasted effort if not outright disaster.
It's a bit like the standoff between the (former) Soviet Union and the USA: not a single shot was ever (directly) fired between the two but the threat of escalating conflict kept them in check (resulting in proxy conflicts in Korea, Vietnam, Afghanistan, etc but I digress).
Think about it this way: MPEG-LA could announce tomorrow that licenses now cost $1 trillion. The result? Obviously no one would pay and a new standard would arise pretty quickly. What if it was $1 billion? $100 million? The point here it is simply a question of degree.
So what keeps (and will keep) MPEG-LA in check is market forces, the limits of what people can and will pay and the threat of a free or cheaper alternative... much like any market. Switching formats is a process that can be automated so the transition cost isn't really that high.
[1]: http://en.wikipedia.org/wiki/GNU_General_Public_License#Vira...
> This ambiguity is more pronounced when you use words like "open" because it means different things to different people.
I never once used the word in my post.
>What do you mean "if"? It already has.
You're arguing for the status quo. Everything seems entrenched until an alternative comes along.
You seem to completely ignore that the H.264 license is directly opposed to free software. There's a reason Chromium never supported H.264, while only Chrome did. Nobody except the patent holders benefits from a de facto patent-encumbered codec.
The decision to only support bundled codecs and refuse to let the user use anything else was made by Mozilla, Google, and Opera. It is not a spec requirement or technical necessity. The idea that a browser would be forced to bundle h.264 is quite evidently mistaken, as the browsers that do support it don't bundle it.
On the other hand, if Mozilla/Opera/Chrome used third party decoder, that would be support nightmare ("It works on my computer, but not on friend's! Please fix it!").
I don't understand the significance. The same APIs are accessible to any other browser. If someone has evidence that Mozilla, et al. have been technically locked out of using the media APIs on Windows or Mac OS X, I'd be interested in the details, and if someone has evidence that they've been locked out of using the media APIs on Linux, I'll eat my hat.
they use their vendor's decoder and nothing else
I'm not sure what you mean. If you mean something like "Windows will only support h.264 and you can't use anything else", then that is exactly wrong.
Microsoft can always rely, that IE9 will supports whatever formats they want it to support. They know, that it will play H.264, because they ship H.264 with Vista and 7 and IE9 supports only Vista and 7.
Apple can also always rely, that Safari will display formats they want it to display. They know, that Safari will play H.264, because Quicktime ships with H.264 and Quicktime is bundled with OSX, or with Safari for Windows.
If Mozilla/Google/Opera outsource this to OS, they lose control. They will not know, what the browser will display (imagine handing off control about HTML/CSS/JS to Microsoft, when IE6 was going down and Firefox up. It would be like Firefox using IE HTML control to display HTML).
Another problem from the control perspective is inconsistent support among platforms. Platform A, it will play formats X and Y. On platform B, formats Y and Z. On C, X a Z. Do you see problem here?
That is not the case for browser vendor without their OS. They cannot achieve the same effect.
I'm not convinced that that is the case, but even if it were, the state of things with bundling codecs is being limited to what Google and Mozilla say is ok for them. You, the user, have no say in what you can view. This might be acceptable if you have supreme confidence in them (where is the next free codec going to come from, anyway?) but frankly I don't think they've earned it.
not to mention losing any semblance of uniformity
I find this extremely dubious. The incentive to publish in a format viewable by the widest audience applies regardless of what format that happens to be. Flash became ubiquitous for web video precisely because it was the most useful at achieving this aim, not because any browser decided to forbid other plug-ins. I see no reason to think that this incentive would dissolve if codec support was left open-ended.
changing the status quo in any meaningful way away from patent-encumbered codecs
This is is an ideological demand, not a spec requirement or a technical necessity. Which is my point: that is why these browser vendors are doing this. Not because they are forbidden from supporting h.264 (compare Epiphany) but because they're trying to push an ideology under which h.264 is heathen.
> bundling codecs is being limited to what Google and Mozilla say is ok for them
What you are suggesting merely takes the power out of the hands of browser vendors and puts it in the hands of the os vendors. I trust Mozilla, and to a far lesser extent Google, more than I ever will trust Microsoft.
Not true. e.g.: http://xiph.org/dshow/ http://xiph.org/quicktime/
Why am I not free to do this with h.264 in "open" browsers?
It depends on how you define "compatible", but H.264 is only sort of compatible with MIT-style licensing as well. It's compatible in the sense that, if you start with MIT-licensed software, you can slap on the required H.264 license and not violate any laws (MIT-licensed software can be relicensed under more restrictive terms). But it's incompatible in the sense that you can't actually choose to ship your software under the MIT license and the MIT license alone. In that sense, H.264's license is viral: any software that supports H.264 in any form must incorporate the the H.264 license.
It's not. Plain old copyright is viral. A derived work's copying can only be done with permission of original and deriving author. If you use a commercial library, the license you paid for is that permission. If someone then creates a new work from yours, permission is needed from all three authors unless the original library came with those particular redistribution rights.
This is short term thinking. Flash isn't going away in the short term anyway; why should we kneecap the future of HTML5 <video> before it gets off the ground because it might temporarily extend the life of an already entrenched format?
Because the way I see it, there's zero chance of replacing it when your alternative had nearly 20% of the market guaranteed to be segmented due to Mozilla's refusal to adopt H.264. Everybody would have kept using Flash+H.264 anyway.
I disagree completely. One of the things I love about my iDevices is that they don't support Flash. Some consider this a problem. I consider it a feature.
For me personally, very few times is this frustrating and most of those are when sites use Flash-wrapped video with no HTML5 fallback, which is still relatively common (but decreasingly so).
I wish I could use Chrome without Flash. But it's preinstalled, which I'm vehemently opposed to. What's worse, if you uninstall it almost every page bugs you about missing plugins. The only solution (which I use) is to use a Flashblock plugin, which is far from optimal (eg sites use a Flash overlay over the entire page to trigger all the Flash on the page).
And for the record, I don't hate Flash because it's closed. I hate it because it's buggy, creates extra security vulnerabilities, is used for some quite nefarious practices (eg zombie cookies) and, in the modern era of HTML/JS, is basically not needed anymore (where it once was) for RIAs.
> why should we kneecap the future of HTML5 <video> before it gets off the ground because it might temporarily extend the life of an already entrenched format?
Because in real terms this move does absolutely nothing to the future of H.264. Want to watch H.264 in Chrome? You use Flash. So the net result is now I have to use Flash where before I didn't.
> Mozilla's refusal to adopt H.264. Everybody would have kept using Flash+H.264 anyway.
If Firefox users choose to use Flash (by choosing Firefox) then that's their choice. I also understand why Mozilla doesn't support H.264. Beyond the political arguments a license would be a huge slice of their revenues.
So all this move does is force me, as a Chrome user, to use Flash, where before the browser supported the format of most relevance in the video market. Unlike Mozilla, who have valid financial reasons, Google already has a H.264 license so this move is purely philosophical/political.
I object to being drafted into a war that I have no interest in and (imho) is both premature (for WebM as a format), too late (considering H.264 entrenchment to date) and unnecessary (given the cost of changing later and that the FUDed Armageddon scenarios are at best overblown and at worst disingenuous).
You know, they make real computers that don't support flash too.
Then, frankly, you're not paying close enough attention. Video is only one part of why Flash is popular. One area that HTML5 isn't even close to replacing Flash is in webgames, and a big reason for that is something fundamental to HTML5: HTML5 behavior is at the mercy of the rendering and JavaScript engine the browser running it. Flash is the same everywhere.
All these fancy HTML5 demos you see everywhere? They pretty much universally have "Runs Best on [Browser X]" somewhere on the page. We're partying like it's 1999 all over again.
Like it our not, Flash is going to be around in the near-term regardless.
From my experience building a HTML5 video playback portfolio for a client, playing high quality webm/ogg is just not doable yet, even via Amazons CDN.
And what i don't get, on a very basic level, are these companies that own these file formats really ever going to cash in on all those files out there? I mean GIF, JPG, PNG are all patented formats, and they are everywhere.
Why doesn't Google announce for example that they will also stop supporting JPG/PNG/GI in favor of their open source WebP format? If they were really drawing bold lines they should be honest about it.
They simply sound so naive when they say "Today, we're also urging Web site operators to distribute videos in the WebM format, and abandon H.264". What they should be saying is "Prepare your web sites to transition to WebM".
Unless you actually get your hands dirty and start doing something, not just preparing, there won't be any significant results.
Sure, FSF is quite radical with "and abandon H.264" part, but "distribute videos in the WebM format" part is perfectly fine.