I've been trying to refrain from commenting on these stories the last few days, but oh well.
This whole debate is stupid and of course WebM exclusivity is the right way to go. Mozilla supports it, Chrome supports it, Opera supports it, Flash will be supporting it in the near future, meaning any of the other desktop browsers will support it.
The only reason people are complaining is that their iPhones have H.264 hardware acceleration. Well, dude, you'll just have to deal with software decode for some videos. The world does not revolve around iOS, no matter how much you want it to.
There is no good reason to support H.264 -- WebM provides roughly equivalent features and quality and MPEG-LA will be out for blood ever more as the clock ticks down on H.264 patents.
Everyone knows that there is no valid argument here for supporting H.264 other than "but... that'll decrease the battery life on my iPad or iPhone! :(". That's life, man; technology moves forward and old things get obsoleted, even mind-blowingly shiny things made by Apple.
I find the pointless hipster-fanboy whining to be pretty grating, personally.
> This whole debate is stupid and of course WebM exclusivity is the right way to go.
This whole debate is stupid and of course WebM exclusivity is the wrong way to go.
An "of course" is a really lame way to enter a debate, because it says that everyone take the debating so far seriously are idiots, which I don't believe the rest of HN are. The other alternative is that it's much more nuanced than "of course" allows, you just haven't understood the debate.
> The only reason people are complaining is that their iPhones have H.264 hardware acceleration
No, people are complaining for many other valid reasons. Like: the digital video world runs on H.264, it has deep, complicated, expensive internal toolchains to support it, legacy archives encoded in it, basically entire businesses built around it. The video production world is far larger and more complex than you're picturing it. A "script" isn't nearly enough to do what you're talking about; suggesting you just need to point ffmpeg at a hard drive of stuff has dramatically underestimated the scale of what's involved.
Or, reasons like: they want the video tag to succeed, and this decision essentially entrenches Flash for another five years at least.
In an h.264 world the video tag had the combined support of three major desktop browsers, iOS, Android, a tonne of shipping mobile and embedded hardware, a Flash fallback and crucially it was an easy implementation for all the video content producers, with no re-encoding required. That's plenty enough to give it a good beachhead and momentum away from all Flash all the time.
In a WebM world, you have the support of Firefox, Opera and Chrome. No shipping mobile support. No shipping embedded support. No shipping Flash implementation. No video producer support. No video toolchain support. And it's a small technological step backwards, to boot!
> I find the pointless hipster-fanboy whining to be pretty grating, personally.
I find underinformed freetard passive-aggression to have no place here, personally.
Your comment basically says "But, we already have all this expensive stuff for H.264! We spent a lot of time and money buying it and figuring out how to make it all work! I don't like this new thing."
While your expensive super-duper video authoring toolchain does not now support WebM, if Google has its way, it one day will and you'll encode WebM/VP8 just like you encode H.264 today.
The lack of scriptability seems to stem from using tools that are hard to script. ffmpeg is just fine for most people that are going to be using the <video> tag. If your tools are hard to script, you may want to ask the vendor for better tools.
You're right that support for WebM is not as wide as is support for H.264. The theory is that it soon will be.
Nobody is forcing you to convert your H.264 videos today. If you want to wait until support is more widespread, then that's just fine. Chrome is not some devastating loss for the <video> tag here, its userbase is relatively minor.
Also, do you have any merit behind your statement that VP8 is a step backward? I'm aware of Dark_Shikari's post on the matter. I don't think it definitively shows that VP8 < H.264. Do you have anything else? Some sources have claimed VP8 is much better.
> "But, we already have all this expensive stuff for H.264! We spent a lot of time and money buying it and figuring out how to make it all work!"
You cast this as if investment and legacy are irrelevant quibbles, when in fact they're commercial considerations of the kind that are pretty relevant when you want to do something like establish the video tag.
> While your expensive super-duper video authoring toolchain does not now support WebM, if Google has its way, it one day will and you'll encode WebM/VP8 just like you encode H.264 today.
This is a big assumption, and right now the only reason you would do it so you can serve ... well, virtually nothing. One day soon, three browsers in HTML5. You're certainly not reaching anyone new. By contrast, h.264 is well beyond the tipping point, lets you reach all-new mobile audiences, and has a huge installed base, and a toolchain that runs from home-level to corporation.
The drive for HTML5 video depends entirely on making it fit as closely as possible to the path of least resistance that is Flash Player. A decision like this makes HTML5 more expensive and more complicated for people to support, which simply means they won't.
So if you want to get better quality than VP8 out of H.264 on the web you need to either lose hardware acceleration or get different hardware (I'm not sure how much of this can be done with the existing hardware and different firmware, and how much actually needs new hardware; the parts of H.264 non-baseline that are not hardware accelerated are the more complicated ones, obviously).
Of course VP8 also requires changes to the decoding hardware/firmware; I also can't tell you whether those changes would be such that the result would be able to handle non-baseline H.264.
But the upshot is that current VP8 video on the web can easily be higher quality per bit than current H.264 video on the web, because the latter is self-constrained by hardware support and the former is not worrying about it for the moment, since it's not there anyway.
All of which is a far cry from "VP8 is much better". ;)
So this is a bad decision because one technology you like is already entrenched so there's no point fighting it, and also a bad decision because another technology you don't like is so entrenched that it'll be around for years because Google won't fight it (in one very particular way, which happens to benefit Apple most).
Many of your arguments are valid against WebM (basically lack of maturity, support) but the exact same arguments can be made about HTML5 video with any codec (not supported by the majority of bowsers, it's not a standard yet, where is the DRM, hardware acceleration is patchy, captioning support is still sketchy, easy switching between streams etc.)
The set of those who oppose Flash as a closed web technology yet don't believe in royalty-free web standards is much larger than I thought it would be. But it seems to be mostly the cultier end of the Mac fanbase. It's a bit of a shame that they can't just come out and say "this affects me because Apple supports neither the current defacto standard H.264 via Flash, nor the coming de jure standard WebM via HTML5 on my portable iOS devices". (Note that the more normal Apple users were already annoyed, at Apple, for the first half of that lack of support on their iPads.)
Flash is in no-way teetering on the brink, and this decision by Google has minimal impact compared with the fact that 99% of web video is served via Flash. The only thing likely to make a dent in that number is changes at Youtube. So if you really hate Flash that much, I'd stay on their good side.
That's such an uncharitable reading I don't really know where to start. It's a bad decision because its only real-world consequence is to entrench Flash even further.
It does that by ignoring the state of play of video content, which is what could have driven the change to HTML5. To those guys it's as though they removed support for JPEG, frankly.
What's more, there are real, sensible, pragmatic arguments against doing this, and they don't all boil down to "wah but I has iPad". If anything, the iOS users are going to be absolutely fine out of this, because they're already where people with video content need them to be.
The only losers are people who would like HTML5's video tag to replace Flash as widely as possible. That's why Adobe is delighted.
Is the current lack of support in WebM for mobile devices really an issue? I know the carriers would love you to burn through your monthly data allowance as fast as possible but my understanding is that generally (with the exception of South Korea and Japan) there was little interest in viewing video on mobile devices. I tihnk that is likely to change but it will not be hampered by the poor support in current generation hardware.
Codecs have come and gone all the time. Your best bet for the web as late as 2007 was transcoding to VP6. How could anyone invest in a toolchain that can't support any codec other than H.264, knowing such a poor design wouldn't have been viable just a few years before? Did they think the industry wouldn't agree on any improvements, ever?
It's not the actual codec that matters. It's that if you have one given codec end-to-end throughout your entire workflow and it lets you drive everything from broadcast to mobile phone, why would you then support an oddball outlier without any proven technical advantage and with no new audience?
Of course you can plug in another transcoder on the end of the output chain, but why not just serve the h264 holdouts yet more Flash and keep your existing archive and workflow untouched?
I wouldn't spend real effort keeping transcoding out of a pipeline. One codec end-to-end for all audiences is not the normal state of affairs but a convenient aberration. Sooner or later (I doubt it'll be more than a couple of years) somebody's going to achieve 95% of the quality with 50% of the power budget, or fully capitalize on the redundancy of 3D footage, or something like that.
Except for the fact that as a video site, all of my existing video is already in H.264. All of my encoding tools support H.264. Every other device I need to stream that video content too including mobile devices, tablets, Connected TV's, Blu-Ray players and Over the Top boxes (Roku, Boxee) support H.264 (generally at the hardware level).
The same argument applies to video sites. We shouldn't be held back and stuck on a proprietary format just because you don't want to write a script to go through and re-encode everything to WebM.
H.264 heretofore has been "the standard", so of course most existing devices will have better support for H.264 video than for the not-even-one-year-old WebM. Google and Mozilla are attempting to change that to avoid a repeat of GIF or even MP3.
The argument boils down to "I don't want to put in the effort to switch to the new stuff, and my old stuff likes the old stuff better anyway, so Google is a jerk for trying to make the old stuff less common." And that's just a silly argument that could easily be applied to any number of things in technology, which is a very fast moving field. Things change a lot in this space and it's just one of those things you have to accept.
Google has not obliterated or disabled your H.264 decoders. You are welcome to keep H.264 video around all you want (according, of course, to your license terms with the MPEG-LA). Removing native support from Chrom(e|ium) does not mean that all H.264 video is now magically broken or unplayable. If you are happy with H.264, you are free to continue to use it.
"I don't want to put in the effort to switch to the new stuff, and my old stuff likes the old stuff better anyway, so Google is a jerk for trying to make the old stuff less common."
- No the argument is that H.264 is still a much better supported format which works much better with an existing workflow, tools and media players (and a negligible licensing cost).
Re-encoding to WebM does me no good if a large section of my target devices don't support it. If they support H.264 but not WebM I'm sticking to H.264, and happily paying the relatively negligible licensing fees.
You also seem to be underestimating the complexity of re-encoding a video library. Its a massive and costly undertaking and hardly just taken care of with a shell script. You generally don't "re-encode" existing H.264 video to WebM. You re-encode baseline video at a higher bitrate down to WebM or H.264 at various bitrates. Frequently these source baseline videos are not stored as digital files - they are multi GB in size. We work with the UFC and re-encoding their content at one point required them re-sending digital tapes to the encoding house so they have high quality source video.
Let alone the actual process.
Even if you own your own encoding tools you generally need to re-encode, QA the resulting video, push it all out to your CDN and then change every link you've got point to the new video URL. If you're not encoding your own video but using an existing service you frequently have to pay for both bandwidth and encoding costs to redo your video you often pay per-minute of video. Its an extremely costly undertaking.
It's a script to run ffmpeg over your video directories, scp/ftp/whatever it out to your CDN, and update a database somewhere (or use permalinks that don't care if the extension changes, or just keep the old extension on the filename even if it's not accurate anymore -- your users aren't seeing it anyway). It's definitely a scriptable undertaking if your application has any sanity.
I recognize that there is an associated transitory cost, like the extra disk space and bandwidth used, but, again, such costs are inherent in working in a quickly developing field of technology. HTML5 is new, still only a draft, and most browsers' support is adequate but not really "mature". Things are going to be changing with regard to HTML5 video, canvas, etc. now and in the future -- you may want to stick with Flash video or links to video files until HTML5 stabilizes further.
As stated, if you don't think it's worth your while to transcode to WebM, no one here is forcing you. You are totally free to keep everything H.264 and give Chrome users a Flash fallback.
Encoding video is not an automatic process that can be sent to a batch process and forgotten about; encoding is art, meaning it has to be done by someone who masters their tools, visually checks the result and adjust the process accordingly, for each video (even for each scene!)
Otherwise the result is shit.
So, changing codecs is a lot of work for content producers; maybe it's for the better, but don't say "it's just a script", because it simply isn't.
So, does YouTube have someone sit there and manually check every video to see if quality would be a little better if the bitrate was tweaked before (or after, for that matter) they publish it? What about Facebook or Vimeo? I think these prove that you can have an automated encode produce acceptable results.
If you care enough to be picky about the parameters used to encode a given video, then you're probably not uploading that video to YouTube in the first place, which gives the end-user no control whatsoever of the encoding parameters.
If you publish several hundred videos on your own and you've carefully tweaked and created an encoding profile for each one and you want to use the same care when transitioning to WebM, then I recognize that that will be pretty time-consuming for you. However, I sincerely doubt that's a very common case, and, as above, you don't have to switch to WebM if you don't want to. H.264 decoders still work.
"So, does YouTube have someone sit there and manually check every video to see if quality would be a little better if the bitrate was tweaked"
Of course they don't and no one expects them too. Have you seen the videos on youtube? The quality is wildly variable, with the mean-quality being shit.
For many other content — music vids, doccos, tv-shows, movies — quality is important.
"If you publish several hundred videos on your own and you've carefully tweaked and created an encoding profile for each one and you want to use the same care when transitioning to WebM, then I recognize that that will be pretty time-consuming for you. "
Which is precisely why so many people aren't interested in WebM.
"However, I sincerely doubt that's a very common case,"
You’re making assumptions. It may be very few people or it may be a lot. How confident are you when you say it's not very common? How did you come to this conclusion?
"However, I sincerely doubt that's a very common case, and, as above, you don't have to switch to WebM if you don't want to. H.264 decoders still work."
And thus, your entire argument in favor of WebM falls flat on its face. H.264 decoders not just "still work" but they are also the only way to get video to mobile devices at this time. So unless you want to ignore all mobile devices, you’ll at least not want to drop H.264 altogether, and maintaining two entire video catalogues at the same time is so very much not an attractive proposition when the alternative is maintaining only a single video catalogue—likely what everyone is doing right now as it is.
Why is H.264 the only way to get video to mobile devices? Can your mobile computers not make the computations necessary to decode video encoded in a codec not natively decoded by hardware? Software decoding is not impossible or even rare -- it's the common case except for a handful of codecs on a handful of devices.
So, why is it not possible for an iPhone or Nexus S to decode WebM?
I have an iPhone and other H.264 rendering devices, too. It sucks to know that WebM might be a problem. But I'm not so sure worrying about my phone purchase warrants this baffling cry of nonsense about Google dropping H.264.
Flash is installed everywhere, providing video, interactive content and millions of web experiences - but Steve says its gotta go. Fine, I concede that a proprietary sandtrap that encapsulates 90% of the interactive content on the web is probably a crappy thing.
So why the hate on Google for dropping royalty-laden H.264? Isn't this the same proprietary lip-stick-on-a-pig bullshit argument that Adobe was shooting around about Flash when Steve Jobs declared it the enemy of battery life?
It would be different if every single browser supported H.264 and Google was pulling the carpet out from under everyone. But that isn't the case.
>The same argument applies to video sites. We shouldn't be held back and stuck on a proprietary format just because you don't want to write a script to go through and re-encode everything to WebM.
Here's a question: If it's no biggie to re-encode everything as WebM, can't we wait to see if this threat of unreasonable H.264 licensing terms becomes reality and switch to WebM then?
They are already unreasonable, hence the fact that they can't be mandated in a W3C standard, many governments have laws saying their communications shouldn't use such a codec, Mozilla can't ship it etc.
"Except for the fact that as a web site, all of my existing HTML already works in IE6. All of my HTML tools support IE6. Every other device I need to view web content content too including Windows mobile devices, Windows tablets, and Microsoft Web TVs support IE6."
These same arguments have been used before, imagine if they were successful at deterring open, royalty-free innovation --- where would we be now?
Ignoring the cost in ignoring the revenue from millions of iOS users, let me focus instead of the looming legal question of WebM. If Google were to indemnify WebM users (sites who encode in WebM, developers who release decoders, OEMs who release hardware decoders), I would be much more willing to embrace WebM. As is, there is a very cogent argument to be made that the MPEG-LA group has already suggested that some of their patents may be encapsulated in WebM and users could be opening themselves up to lawsuits as co-defendants with Google. H.264 isn't free, but it's a known cost and licensing from MPEG-LA indemnifies you from any legal costs that might be associated with patent trolls popping up to sue you to death.
This point has already been discussed a lot, but I'll just review it quickly for you.
Basically, if you use any software at all, you can't go around living your life in constant fear of patent threats. WebM is probably safer than most because you have a big entity to fight most of your battle for you, presuming such a battle ever materializes.
Of course it's possible that MPEG-LA will be angry to see their H.264 revenue stream run consistently drier and sue in hopes of retaliation and a declaration that all WebM users must pay MPEG-LA royalties anyway. There's no guarantee that this will happen, however, and that MPEG-LA hasn't made an attempt to "nip this in the bud" demonstrates that they may not be all that certain they have a case here.
Google released WebM explicitly to circumvent the restrictions with H.264 so I suspect they did their due diligence and deviated from the H.264 patents in the necessary ways, but as above, there's nothing you can do if you irritate a group that has money and lawyers and wants to try their hand at milking something out of you. That's a general fact of life whether you use WebM or not.
If you're really worried about the FUD MPEG-LA puts out to scare you into paying protection money, then I guess you are free to pay that, if it makes you feel happier. But "Google shouldn't promote free standards because it might make someone angry and then they might sue you" is just not a very solid argument -- we can't refuse to do anything because someone might sue us. There will always be vultures out there, and we can't stop progress because of them.
"WebM is probably safer than most because you have a big entity to fight most of your battle for you, presuming such a battle ever materializes."
You’re making the kind of assumption that a rational business owner won’t make, which is that Google will suddenly jump in at the last minute and protect you. Thus far, Google is suspiciously refraining from indemnifying anyone using WebM. As a business owner, what motive do I have to give Google my trust and risk my entire business for them/their ideology of “openness” (whatever that means) if they’re not willing to give me the slightest shred of reason to trust them? It’s not like their track record is a shining example, either.
"Google released WebM explicitly to circumvent the restrictions with H.264"
That's their claim, yes. No independent patent entity has verified this that I know of, and MPEG LA have released statements that they are almost certain that WebM violates some of their patents. Also, Google has no stake in H.264, so they're at risk of being forced to forever pay hefty licensing fees to MPEG LA for Youtube (and other properties) if H.264 wins. It's entirely in Google's interest to kill H.264 or at least make WebM popular enough that they can use that to offer video to users, but just because it's in Google's interest doesn't mean it is in the interest of the web at large, or of Google's users and customers themselves. If you think they did this just for the "openness of the web" you're being either ridiculously naïve or a poor business person.
as a ridiculously naive and poor business person, I'd like to say that if webm becomes popular enough that google can serve it and avoid h264 (and paying royalties to MPEG-LA), I'd consider it a step toward my vision of a more open web (royalty-free codec widely available) and a good development for my business (royalty-free codec widely available).
no one is pretending that this will be all rainbows (the post directly acknowledges the current stalemate), so feel free to assume that those of us in favor of this development aren't idiots.
Why would Google do their due diligence and not share it? MPEG-LA has detailed very clearly where each patent claim applies to the H264 spec.
Google owes it to its users to go through the MPEG-LA document and do at least one sentence explaining why WebM doesn't infringe each point. It would be a month exercise for a dev and product manager, but well worth it.
It ccurs to me that there's one possible motive for Google doing what it's doing that isn't purely cynical -- it may want the MPEG-LA to sue it now and reach some kind of settlement than wait a few years and ambush it.
The problem with that is that MPEG-LA's licensors can sue more than once.
In fact if I was MPEG-LA I'd do exactly that. I'd work with my licensors to ensure not everyone sue at once, but rather do it all in succession. Literally have WebM in courts everyday for a decade. And remember, only one licensor need win, and they don't have to grant WebM RAND terms. They could just come right out and say, "take it off the market". And since there's no indemnification, they could in theory even go after end-users of phones, although not likely.
Of course the same can be done against H264, but it appears far less likely.
But a "flush out the enemy" strategy doesn't seem likely given the raw number of patents and licensors associated with H264.
Except it's not true: you pay MPEG-LA to license known patents under their ownership. They don't indemnify you from patent lawsuits stemming from patents they don't own.
The big difference is MPEG-LA has gone through extensive public effort to document and find patents applicable to H264. On2 may have done the same, but they did so behind closed doors if they did. So far Google hasn't let us know either.
So oddly you have a royalty-based codec where work has been in the public. And a royalty-free based codec where everything has been done behind closed doors. Oh the irony. :-)
I think you can be sure that Google tripple-checked everything before exposing themselves to lawsuits and spending on On2 more than lifetime royalties to MPEG-LA (at current rate).
Another thing is that VP8 is very similar to H.264 without stepping on known H.264 patents. If any unexpected patent surfaces, both Google and MPEG-LA licensees will be screwed (but not MPEG-LA, as they're not giving protection nor guaranteeing that their license covers all required patents).
I think you can be sure that Google tripple-checked everything
They may have. If so, just show me the paperwork. MPEG-LA has given them a great paper trail to work from. The fact that I've seen nothing from Google gives me nothing to go on.
One thing I've learned in business is if one person gives you a docket full of easy to follow evidence and another says, "trust me" -- I tend to go with the hard evidence. In both cases the proof won't be complete, but I can sleep at night knowing that I made an informed choice.
But that's just me. At the end of the day, each org will have to make its own choice. I think a WebM + H264 world is perfectly fine. Let the better codec shine.
> As is, there is a very cogent argument to be made that the MPEG-LA group has already suggested that some of their patents may be encapsulated in WebM
They've been saying the same about Vorbis for the last 10 years and yet never sued anyone. By the way, Vorbis is being used a lot by the billion dollar video games industry.
> H.264 isn't free, but it's a known cost and licensing from MPEG-LA
Actually no, MPEG-LA and its users have been sued many times by patent trolls, read up the wikipedia article. H.264 is no safer, the MPEG-LA is just good at spreading FUD.
They've been saying the same about Vorbis for the last 10 years and yet never sued anyone.
No one uses Vorbis across applications (ie as an interchange format) so it doesn't matter. Its peanuts.
By the way, Vorbis is being used a lot by the billion dollar video games industry.
Yes, but not as an interchange format, which is key. They know that if they ever sued us for using Vorbis we'd go back to any number of proprietary formats that we used before we started using Vorbis. We can do that on-the-fly because we don't use it as an interchange format - there's no legacy, no compatibility issues, nothing. We can just change and then there's no long-term licensing scenario for them. It isn't worth suing. Add to that the razor-thin margins across the games biz and the fact that most studios would just go bankrupt and close up shop if they were sued for this rather than pay-out and...why would they sue us again?
Actually no, MPEG-LA and its users have been sued many times by patent trolls, read up the wikipedia article. H.264 is no safer, the MPEG-LA is just good at spreading FUD.
Yes, probably. I'd like to say that the MPEG-LA with their h.264, having been around longer, is at least a safer, friendlier bunch of crooks. Sadly, not even licensing h.264 from the MPEG-LA will guarantee you'll stay out of court.
Recently I've become quite worried about using Linux for the same reason. Microsoft has suggested several times that some of their patents may be encapsulated in Linux and users could be opening themselves up to lawsuits. Now, they haven't mentioned the actual infringed upon patents or where Linux has done so, but they could at any moment.
More seriously, MPEG-LA indemnifies you from nothing. However, like the webM license, you lose all right to associated patents if you sue a licensee, so there is some protection there (in both cases).
Microsoft did the same thing with respect to SPF, asserting that they had patents filed for that had claims that SPF and related sender control technologies could have infringed upon but wouldn't assert exactly what those patents were or exactly what claims would be targeted. It severely retarded the marketing, uptake and discussion around email sender control, and was a huge distraction.
As it happens, MPEG-LA doesn't indemnify you from anything. They even say so on their website, though it's carefully hidden. But people would really like to believe their licensing fee paid for that sort of thing, so don't bother to check what the actual licensing terms are.
This is a standard negotiating tactic. Google will back down once they prove that WebM is a real threat to MPEG-LA's business model. They'll do this because you'll find Google getting an exclusive sweet deal from MPEG-LA for streaming h.264 on YouTube (which is what they really care about). Once that happens, h.264 will be back in play on Chrome, leaving FireFox and Opera as the odd browsers out. Which, incidentally, is great for Google because users of those browsers will just switch over to Chrome.
By similar logic, Chrome is just a ploy to get Microsoft to make Google the default search in IE, and Android is just a ploy to keep Apple using Google Maps on the iPhone.
This could be true, or it could actually be that Google wants people to use a format that works on Linux, OS X, and Windows. Not everything is a conspiracy or a ploy, you know.
The other thing that bothers me is that people are screaming blue murder as if they had no alternative choice of browser. If you don't like Chrome's decision (or Firefox's, or Opera's), use another browser. You can still choose to use Safari or IE.
I've been trying to refrain from commenting, too, so that's one thing that we have... had in common.
> ...of course WebM exclusivity is the right way to go. Mozilla supports it, Chrome supports it, Opera supports it, Flash will be supporting it in the near future...
First of all, including Opera in the list of those in favor of WebM is a lot like including Iceland in the Coalition of the Willing. If you live in Iceland, you probably overestimate Iceland's importance, but it undermines the intent of making a list in the first place. The flip side of this is that, while Internet Explorer probably won't support WebM unless Google indemnifies adopters, IE is almost as irrelevant as Opera in the arenas of both web video and The Future. Here's where we really are:
* Apple likes H.264 for the following reasons:
* The licensing and liability is known, and Apple can afford to pay. They don't care if web video ends up being a high stakes poker table, because they're a high roller.
* H.264-encoded video looks better than WebM video and takes up slightly less space.
* Most current graphics silicon supports hardware decoding of H.264, which allows for video playback that is both gorgeous and economical.
* Mozilla liked Theora because they can't or won't pay to license H.264, and Theora was the only open source candidate they could find to run in the election. Free is more important than good.
* Google likes WebM for the following reasons:
* They can control its development.
* It is, so far as anyone knows, unencumbered by patents, so no licensing.
I say "so far as anyone knows" because that's what Google is saying by not indemnifying WebM adopters. If you're worried about a theoretical MPEG-LA licensing gotcha, then you have to be equally worried that, if/when WebM adoption is significant, patent trolls won't show up with claims of infringement. At least with H.264, the licensing terms have been stated. YOU personally may not be worried about either scenario, but you're probably not weighing whether you should produce graphics chips that decode WebM. Does anybody on this forum want to argue whether the chipmakers who've pledged to do WebM decoding aren't nervously watching to see if more Android hardware makers get sued? By not indemnifying adopters, Google is essentially picking an open source fight in a crowded bar and then ducking out the side door.
>The only reason people are complaining is that their iPhones have H.264 hardware acceleration. Well, dude, you'll just have to deal with software decode for some videos. The world does not revolve around iOS, no matter how much you want it to.
That is a very big component to the complaining: I can't watch your idealism on my iPad for the duration of a 6-hour flight. And you're right, the world does not revolve around iOS, but the video world does revolve around H.264 right now. If you're not shooting with actual film, then your video workflow literally starts and ends with H.264.
And maybe more to the point web video does revolve around iOS devices, because iOS users watch orders of magnitude more video than anybody else.
> WebM provides roughly equivalent features and quality
If by "features" you're excluding fast, economical encoding and decoding and by "quality" you're excluding picture quality. "Roughly equivalent" is just weaseling around admitting H.264 looks and works better. Someday... who knows? Someday GM might make a better car than Toyota, but for now, GM is stuck saying things like "[our] quality can't be beat by Toyota."
> I find the pointless hipster-fanboy whining to be pretty grating, personally.
And the hipster-fanboys doing the pointless whining harbor deep suspicions that people who are willing to trade their audio and video playback quality today for the open source promise of adequate video someday don't really care much about audio or video.
> I say "so far as anyone knows" because that's what Google is saying by not indemnifying WebM adopters. If you're worried about a theoretical MPEG-LA licensing gotcha, then you have to be equally worried that, if/when WebM adoption is significant, patent trolls won't show up with claims of infringement.
Does MPEG-LA indemnify its customers against patents by others (such as Google)?
Google and MPEG-LA both have a bunch of patents that apply to somewhat similar codecs. The only difference is that everyone knows Google's not going to be a jerk about it. Who knows, other patent trolls might turn up that attack MPEG-LA customers.
> By not indemnifying adopters, Google is essentially picking an open source fight in a crowded bar and then ducking out the side door.
Google's not "ducking out" of anywhere: it will be probably the biggest WebM publisher out there because of YouTube. Of any WebM publisher, they'll have the biggest target on their back. And by pushing WebM so hard, clearly Google thinks this is a battle they can win.
You're right that MPEG-LA does not indemnify licensees of H.264, no. Licensing doesn't eliminate the risk of adoption. It substantially reduces that risk. (Largely because patent licensing also function as a protection racket.) MPEG-LA will defend their patents, though.
See, it's not gonna be the content producers (like Google) that the patent trolls go after for WebM; it's gonna be the makers of the WebM-decoding graphics chips. I guess it remains to be seen where Google will be in that fight.
The flip side of this is that, while Internet Explorer probably won't support WebM unless Google indemnifies adopters, IE is almost as irrelevant as Opera in the arenas of both web video and The Future.
Internet Explorer still has a larger market share than Safari and iOS devices are barely a blip on the radar.
By your logic, only Firefox, IE and Chrome should matter.
I can't watch your idealism on my iPad for the duration of a 6-hour flight
Well, we're not talking about videos that you load and play and you're iOS device. We're talking about video that is embedded in web-pages. Are you watching those during your 6 hour flight?
And maybe more to the point web video does revolve around iOS devices, because iOS users watch orders of magnitude more video than anybody else.
I'm reasonably sure you're greatly overestimating how much web-based video iOS devices consume.
> We're talking about video that is embedded in web-pages. Are you watching those during your 6 hour flight?
Increasingly, yes, I am watching those during my 6-hour flights. But I'm not talking about video embedded in web pages exclusively; I'm talking about video delivered via the web.
> Internet Explorer still has a larger market share than Safari
No doubt. But if you re-read what I wrote, I was trying to refute the parent comment's statement that "of course WebM exclusivity is the right way to go" without playing the IE card. I think IE's relevance ("in the arenas of both web video and The Future") is extremely questionable, so I don't want argument built on it. But if you accept that IE is relevant, then "of course WebM exclusivity is the right way to go" sounds even more crazy.
Genuinely curious: What video are you talking about here that is delivered to your iOS device via the web? Are you referring to Netflix and iTunes? Or something else?
Maybe "web video" is too lazy of a term. What I'm talking about is video transferred via HTTP (or other protocol) from one computer to another. So, yes, that would be Netflix, iTunes, Hulu, YouTube, BitTorrent... Everything. I couldn't even guess what percentage of that whole is video embedded into HTML pages.
I make the distinction because, I think it's important to consider the problem in the larger context of digital media and connected devices, not just in the specific context of HTML rendered in a browser window. Right now we're talking about which video format is right for the HTML video tag, but the implications beyond that are huge. My response to the parent comment was not so much that I think "H.264 rulez," but that discussion of this subject was anything but "stupid" or "pointless whining." I'd like to see this discussion go on.
Late last year, my employer decided to walk away from a project that I had devoted 14 months of my life to because they were sued over SMS patents. This shouldn't be a debate about how much Apple fanboys love patents, when the debate is really about which compromises to make so that we can all make things with computers before we die. For example:
Is H.264 more of a threat to Internet video than fractured video support in web browsers? If you want to keep the debate to embedded video, that's a better question. H.264 made video finally good enough to watch on the Internet. Hardware-decoding made it possible to watch web video without melting your laptop battery. It solved real problems.
And the promise of HTML5 video reinvigorated a whole lot of beleaguered content producers and developers. People are understandably reluctant to trade those things back. If you want to persuade them, explain what they get in that trade.
I think that if we talked about it, rather than calling names, we'd find that not many people are great lovers of software patents as they exist now. But then we'd have to be honest about what we're really fighting about: which battles to pick and who's children (HTML5 video, in this case) get sacrificed on the battlefield.
<video> in fact can specify a non-free codec. This isn't about the types of codecs that should be allowed to be included in <video>, it's about the types of codecs a browser vendor will support out of the box.
Fonts are much smaller than video decoders so they can be sent over the wire, making the whole licensing and distribution thing the problem of the person using the font on his site. Fonts are all decoded by the same free code, whether that font is free or not.
There is no facility to transmit a decoder for the use of <video> tags on your page, and no one would do that anyone because it would be a huge nightmare to make sure you're sending one that can run on the user's platform, the browser would be forced to allow execution of an arbitrary binary block that could very well just be posing as a video decoder, and then all sites would have to pay for the rights to distribute the license. It just doesn't work. The browser has to include the decoder locally, so the browser vendor has to decide if he's going to pay for the license for a H.264 decoder or not.
What I find funny is that half the Internet was complaining when Google announced to support H.264 in the first place when, clearly, supporting nothing but open formats was the right way to go (see Mozilla's decision to only support theora)
And now that Google is removing H.264 support again, half the Internet is, again, up in arms about the decision, using the same arguments as before.
Well, I guess this time it's the half of the Internet that wasnt complaining last time :-)
There was no WebM back then. The only alternative was Ogg Theora (even before 1.1 improvements IIRC), which Google didn't consider as suitable alternative.
Google doesn't have RMS's consistency on the matter. They balance practicality with idealism.
If Google really wants to force WebM adoption they need to go "all-in". Set a deadline for pulling all h.264 videos from YouTube and force Apple and Microsoft to support the WebM standard.
I know that sounds worse than what they're doing but hear me out. Right now they're creating an environment where everyone will have to do twice the work to support HTML5. That's not good for anyone.
So if they're insistent on making WebM the standard they need to pull out the big guns and force Apple and Microsoft to capitulate. It'll be bitter and nasty but at the end we'll get a standard out of it and not a fragmented mess.
This "twice the work" argument was clearly addressed by the post. Firefox has a much larger market share than Chrome and has already clearly stated they will not support h.264. If anyone created a problem of having to do "twice the work" it was Firefox and Google has just decided to support them in it.
And using their position as owner of YouTube to force h.264 out before WebM is ready would just hurt YouTube and make everyone with a mobile device made prior to WebM decoders being included (assuming that gains momentum) unable to watch YouTube videos.
The twice the work wasn't really addressed. No one really cares about the desktop. You can get whatever codec you need whenever. It's mobile that people care about. That's where HTML5 will really make a difference. Firefox is nowhere in Mobile.
If this was just about the desktop I'd say just randomly encode every video. I'm going to have every codec installed anyways. But that's not the discussion.
Last time I checked desktop usage was still is 90-99% range, 3G bandwidth — even with H.264 — allowed only low-quality video streaming, and operators were tightening limits on their "Unlimited†" tariffs.
If you really care about mobiles today, you're encoding special mobile-only (low-res baseline profile) version anyway. Codec war on desktop doesn't really affect that yet.
No one cares about the desktop, not because of popularity today, but because of popularity tomorrow. And more importantly is the other point I made. On my desktop I have ever codec ever created. It doesn't matter what <video> uses. But it's all of my mobile (and embedded) devices that don't have support for every codec, and I generally can't install a new codec on them.
To put it another, if there were no mobile devices, this would be a complete non-issue.
So you care only about tomorrow's popularity, but are worried about today's hardware?
Tomorrow decoding of WebM on mobiles might not be a problem, even for battery life. Mutlicore SIMD and programmable GPUs are coming already, and their power efficiency steadily increases.
Google has got Qualcomm, Broadcom and few others on board with WebM. If WebM takes off, Apple will need to take all their chipset production in house in order to get chipset without WebM acceleration ;)
Did you miss where I say, "And more importantly..."?
And which chips are on the roadmap to have WebM support? I don't know of any announced QCOM or NVidia devices that have WebM support. The only I've seen is Broadcoms, and its certainly not on par with the existing H264 HW accelerators.
And if Intel doesn't add WebM support, which I don't believe they have commited to doing, this could be long haul. Because desktop isn't sufficient with respect to codecs, you do need desktop chipset support with respect to acceleration. No one will be happy if they can't watch 720P video on their high end computer.
Best case scenario is that we see WebM having the level of coverage as H264 has TODAY is probably 2013.
Like I've said, there will be those of that fight against WebM and you'll fight for it. Maybe we just end up with a fragmented world.
No one cares about H.264 via HTML5, not because of popularity today, but because of popularity tomorrow.
Devices with the fastest growing mobile OS and hardware WebM decode are shipping this month (they also support H.264 and legacy VP6 via Flash). The hardware churn rate in mobile will solve this problem rapidly and the gaps can be filled quite easily by software wherever there is a will.
Devices with the fastest growing mobile OS and hardware WebM decode are shipping this month
That doesn't make any sense. What you meant to say was that the fastest growing segment of mobile devices, prior to the iPhone/Verizon, is Android with devices that don't have WebM HW acceleration.
Again, I'm fine with a fragmented HTML5 world. There will be the Google WebM world. And the MS/Apple H264 world. I'm perfectly happy with that.
One was to build in explicit support for h.264 in Firefox and for Mozilla to pay the MPEG-LA ~$5million/year in licensing fees.
Another was to punt to the operating system and let gstreamer/directmedia/quicktime do the decode. Even though it would have been without cost to them, Mozilla chose not to do this as part of their moral stand against h.264. This was why they were so sharply criticized.
The third option was to let the Firefox Flash plugin do the decoding, which is what we have today.
Not really; by choosing H.264 they chose only one format to keep their videos in, and relied on Flash to offer it to the desktop browsers refusing to support H.264 natively.
If they were to force H.264 out they'd clearly have to make an exception for devices that were not capable of playing WebM. To think otherwise would be idiotic (and is an obnoxious straw man argument on your part). But that's not hard to do.
So that doesn't invalidate my point which is they should either REALLY force the issue or drop it. Right now they're making a half hearted effort that guarantees fragmentation.
(As for your first point I agree with the other reply)
Exactly. Removing support for h.264 + the VIDEO tag from Chrome will accomplish nothing more than what Firefox accomplished a year ago when they said that they wouldn't support h.264 in the first place. A year later and no one is serving Theora over the VIDEO tag - instead there are just a lot of Firefox users viewing h.264 in FLV containers in Flash. Chrome's stand against h.264 will convince precisely 0 (ZERO) video websites to double their CPU budget by double-encoding to h.264 AND VP8.
It's what Google does with Youtube that could really change something. If they stop serving h.264 from Youtube, then we'll all be switching to WebM/VP8.
Because the plugins in question are for the operating system's video infrastructure (Quicktime and DirectShow), not the browser.
<video> still acts as a standard platform API across browsers regardless of codec support. It's not like the bad old days where you would have your page manually loading opaque QT or WM or Real plugins through <object> and <embed>.
as mentioned in the post, since firefox is 25%+ of the market and will never budge, it was alway going to have to be webm or plugins.
no one (hopefully) wanted this situation, but the reality is that the different parties involved disagree strongly about what codec should be the defacto standard.
Because Apple and Microsoft are able to obsolete these plugins if they choose so (I'm not saying it's the best solution, but it's legally and technically feasible), and others don't require those plugins.
It's not that easy the other way, where you've got closed reference implementation of Flash (and you can't get it without plugin) and there are patent royalty payments for H.264 decoders.
Not sure why Google is getting so much hate. I would direct it at the following instead:
- MPEG-LA
- Firefox
- Opera
I'm not sure what everyone expected here. There was no way that h.264 would be the standard format for the video tag.
This is one of many moves to push WebM forward as the undisputed standard. It's been less than 1 year since public announcement of WebM, and Google IO is around the corner in May '11. Expect more positive news on the WebM front.
There are 3 major arguments left standing against WebM
1) h.264 is better than vp8
2) prevalent hardware support for WebM
3) iOS
Would anyone really be that surprised if 2 of the 3 are addressed within the year?
H.264 is just not going to work for web video, even as a defacto standard. Firefox will never support it and it prevents any small time player from entering the browser game down the road.
It's also a serious risk for big corps who don't have a license. Keep that in mind when you criticize Google. You're asking them to expose themselves to liability (or pay huge license fees).
If we're going to the trouble of phasing in a <video> tag that will take years to become viable, we might as well throw in a properly unencumbered codec that will also take years to become viable. Why bother with <video> if it's just going to go rotten as soon as it gains critical mass and the patent trolls pounce?
Nothing critical is breaking today, we're just going to have to wait a bit longer to play with the shiny new video tag, which is well worth it to have it done properly. Just be glad that one of the tech megacorps is pushing for standards and freedom as part of their business plan. Usually it's the other way around.
This seems to work under a bit of a hazy assumption that there needs to be a "baseline" video codec. The image tag has worked fine without a "baseline" image format since the dawn of the web.
If using a baseline format was their real argument they wouldn't be supporting a patent encumbered MP3 format for the audio tag, same as Firefox.
>The image tag has worked fine without a "baseline" image format since the dawn of the web.
IE's historically poor support for PNG is probably the main reason so many sites still use GIFs where PNGs would be better. (Edit: And for that matter, as others have pointed out here, PNG was invented because the owners of the GIF patents threatened to sue the entire Internet.) Browser support for TIFF is an inconsistent mess.
In the case of the img tag, the most common browsers all supported two common formats pretty well (JPEG and GIF), so those two formats became the de-facto baseline image formats organically.
I think the situation with video is similar. If Firefox, Chrome, and Opera (the influential browsers used mainly by the early-adopter, techie crowd) all support one specific codec for HTML5 video, that will become the de-facto baseline video format organically.
The img element has baseline formats. GIF/JPEG pretty much from the start and now also PNG. If these formats were not there the img element would never have worked.
If using a baseline format was their real argument they wouldn't be supporting a patent encumbered MP3 format for the audio tag, same as Firefox.
The "if you don't fight every battle at once, you have no morals to fight any battle" angle is bullshit. It's agenda-driven juvenile sophistry, and the real world doesn't work like that.
And while I find the WebM initiative questionable (h264 is technically superior and widely supported already), I find it unbelievably boring (and predictable) how it has become a proxy for the iPhone/Android fight. I doubt the Android team had any bearing whatsoever in this decision, and every Android handset out there is just as screwed by the lack of hardware decoding.
Suddenly boring zealots like Gruber and Siegler are experts on web standards and video codecs. What a depressing day. Seriously.
That's just petty nitpicking, the h264 patent threat in much more immediate and substantial so an alternative is needed specially since we are at the beginning of this shift and setting open standards now will save a lot of heartache in the future.
Its not petty nitpicking, its their entire argument. Including H.264 doesn't in any way prevent WebM from becoming the more mainstream standard. Except for the fact that likely more people would choose to use H.264 over WebM so they don't have to re-encode their video catalog using inferior tools in an inferior codec. The "Video Startups" he's defending aren't being stifled under H.264's licensing fees. The fees exist but they're pretty much negligible to a video provider compared to any other cost they are incurring. If they are really concerned for the poor video startup give them options to use the best tools for their need.
I'm not sure what Google's motivations are but they are taking a huge risk here. If WebM gets a strong patent challenge, or isn't widely adopted/supported for other reasons, then Google is going to demonstrate their ability to pick the wrong horse in a very high profile way. It will be interesting to see what type of fallout that creates. Imagine a new world where Google, with all of its power, cannot influence the future of the web? I think that would have some major ramifications.
I just don't get why my reaction should be different for WebM than it was from OpenXML. A "standard" controlled my one company is not something I think I can trust.
Never. Google is not actively attempting to promote Vorbis or non-MP3 technologies at the moment. It'd be silly to waste resources doing that as MP3 patents are nearing their end-of-life. MP3 is already a lost battle and the patents have so little life left in them that it's not worth trying to squeeze what can be gotten out of that.
The patent license is irrevocable unless you file a suit against VP8 users claiming that VP8 violates your own patents. (This is a common clause for open-source patent grants; basically it means that Google can still use its patents "defensively" as a deterrent against other patent suits, but it can't use them in an "offensive" first-strike.)
Just when I thought there was a chance that this topic would get a break on HN. I guess I appreciate the link, if Google hadn't tweeted about it (I'm assuming they will) I probably wouldn't have seen this link.
Their answers are right, but it's the answers that aren't present, that are more telling. They don't address why they're removing it, why they chose to do it now, or whether or not they'll be consistent across their platforms. In my opinion, those are the only questions worth asking.
Their answers about H.264 having little adoption with the <video> tag and about having to dually encode with the current HTML5 video scene anyway is spot on. WebM gets you native playback in every major browser but IE, with Flash fallback working in IE. There actually is a day, very soon that, Flash assisted, anything will play WebM.
Of course, hardware adoption is still a huge question mark which I noticed Google also failed to discuss further in this post.
"or whether or not they'll be consistent across their platforms"
Are you referring to other devices running Android? I don't think Google's stance is anti-h.264, it's anti anything that isn't royalty-free (forever) in the web stack. And I agree with that.
Android, YouTube, etc. I suppose the distinction of it being the "web stack" is one thing, but doesn't it seem that YouTube should fall in line with their WebM-friendly stance? I can certainly get behind it, and despite my cynicism in regards to timing, etc, I'm behind the 1000lb gorilla using their weight to bring attention and popularity to freedom.
"Of course, hardware adoption is still a huge question mark which I noticed Google also failed to discuss further in this post."
This has been discussed on the WebM blog:
"The WebM/VP8 hardware decoder implementation has already been licensed to over twenty partners and is proven in silicon. We expect the first commercial chips to integrate our VP8 decoder IP to be available in the first quarter of 2011."
Oh I saw that, I meant more that there are millions of mobile (and non-mobile) devices that have hardware decoding that won't be able to play WebM video anywhere near as well as H.264.
The smartphone market is also growing quickly itself, which is why Android managed to equal the installed base of iPhones only a few months after the marketshare (i.e. current sales) rose above Apple's.
WebM will work on all major browsers, IE9 by downloading and installing the VP8 codec on Windows, Safari by installing the codec for quicktime. Of course it will work on Opera, Firefox 4, and Chrome.
And lets be clear Safari on the desktop isn't the interesting one. Its the iOS devices. The iOS devices won't have Flash to fallback on either. So basically every iPhone, iPad, iPod Touch won't be able to watch your WebM videos AT ALL. There is no fallback, unless you encode to H264.
Now maybe you can say that in this new HTML5 web world mobile Apple devices are irrelevant. I personally think you'd be wrong.
H264 is the only codec that will generally be supported on every device, either directly or by Flash. From Chrome to Firefox to iOS to IE.
If Youtube goes WebM/flash only, iOS will support WebM, period. Not being able to watch youtube videos would be like the Flash noise of a year ago, but worse, as there's no reason not to support WebM.
Apple and Jobs aren't shy about saying, "Nope, not doing it". Especially with those they view as enemies and trust me, Google is their arch enemy now, much moreso than Microsoft.
A big reason they may not do it is backwards compat on HW accleration. They have a working solution on all devices today (H264). They're not likely to want to screw their old customers over a codec they aren't particularly fond of that was rammed down their throat by Google.
Here's what I'd do if I were Apple, host my own video service, that serves H264 or Flash. MS and Apple throw their marketing weight and services around that (their various products auto upload to this new service). Now all iOS devices can play this video AND so can everyone else. YouTube dies a MySpace like death.
If YouTube tries that I really think they may be sealing their own fate.
To put it another way, people are NOT going to give up their iOS devices. But they will use a different video service.
If YouTube and all online video is WebM, then iOS will have no way to play 99% of videos (no flash remember). Apple can't afford for ipad to be "the device that doesn't play videos"
iOS appliances have hardware support for H.264. If Apple can actually keep H.264 content available by refusing to support VP8/WebM, their captive users would benefit by longer battery life and maybe smoother playback.
Given that that it has 5-6% of market share, I think it is fair to leave it out of the major browsers. Not ignorable, but hardly major. It is iffy to even place Chrome as one, even though it seems like it will be in the future.
Sorta (I didn't realize how much higher their share was than Opera's). If they choose not to implement a free, open source, easily available codec because they're Apple... then they can get lumped in with Internet Explorer and enjoy the fallback to Flash. I know Jobs is a big fan.
let's all acknowledge this controversy for what it is: an apple vs. google popularity contest. and with that said: suck it apple. suck it long, and suck it hard.
This whole debate is stupid and of course WebM exclusivity is the right way to go. Mozilla supports it, Chrome supports it, Opera supports it, Flash will be supporting it in the near future, meaning any of the other desktop browsers will support it.
The only reason people are complaining is that their iPhones have H.264 hardware acceleration. Well, dude, you'll just have to deal with software decode for some videos. The world does not revolve around iOS, no matter how much you want it to.
There is no good reason to support H.264 -- WebM provides roughly equivalent features and quality and MPEG-LA will be out for blood ever more as the clock ticks down on H.264 patents.
Everyone knows that there is no valid argument here for supporting H.264 other than "but... that'll decrease the battery life on my iPad or iPhone! :(". That's life, man; technology moves forward and old things get obsoleted, even mind-blowingly shiny things made by Apple.
I find the pointless hipster-fanboy whining to be pretty grating, personally.