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.

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.

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.

> Some sources have claimed VP8 is much better.

Cite.

If you read Dark Shikari's analysis carefully, he says that VP8 is better than H.264 Baseline Profile.

As it happens, H.264 Baseline Profile is all that the "hardware acceleration" in most mobile devices handles (see http://weblogs.mozillazine.org/roc/archives/2010/05/its_a_re... ).

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". ;)

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.

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.

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?

> ...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.

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.

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.

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.

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?

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.

What?

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).

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.

- 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.

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.

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.

(I agree with your last paragraph though).

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.

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?

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.

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.

Edit: seriously, the parent's explanation is reasonable, well stated and relevant to the discussion.

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?

"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?

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.

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.

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.

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.

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.

They say so explicitly on their website:

http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx Q: Are all AVC essential patents included? A: No assurance is or can be made that the License includes every essential patent.

So there's no different in that respect between WebM and h264.

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. :-)

And there's impressive list of companies that took the risk too: http://www.webmproject.org/about/supporters/

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).

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.

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.

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.

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).

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.

If font-family can designate a non-free/open font then video can designate a non-free/open codec.

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.