There has been a lot of arguing on the Internet in the past few days over Google’s decision to drop H.264 video support from Chrome. I was really surprised to see the majority of posts (I read) were negative towards Google. I thought the Internet had more sense. I think this move just might save us from twelve years of patent hell so I absolutely applaud Google for doing it.
So here is a rebuttal to pretty much every negative comment on the Chromium blog (linked above), as well as this Ars Technica opinion. If there are any negative arguments I’ve missed, yell in the comments and I’ll either add a rebuttal, or acknowledge it as a fair point. Now on the exact licensing terms of the MPEG-LA, I refer to this document and this additional press release. Firstly, from what I understand it, here are the terms of the license, divided up (simplified) into three use cases:
- For manufacturers of encoders (that is, programs which create H.264 video), there is a license fee with a maximum of $6.5 million per year.
- For manufacturers of decoders (that is, programs which view H.264 video, such as web browsers), there is also a license fee with a maximum of $6.5 million per year.
- For distributors of content (that is, websites which serve H.264 video), there is a license fee with a maximum of $6.5 million per year (with a maximum of $100,000 per video). However, for distributors of content where the end user does not pay, there are no royalties for the life of the patent.
H.264 supporters are quick to jump on that last point, claiming that this makes H.264 free. But it doesn’t, because you still need to pay if you are serving video behind a firewall. It is still illegal to make a web browser without paying the fee (assuming H.264 becomes a mandatory feature of all web browsers), and it is illegal to make software for encoding video without paying the fee. Importantly, these fees still apply even if you are giving away your software for free. This means the end of open source web browsers and video encoders.
Now basically every comment boils down to one of the following complaints:
- It’s not like Google can’t afford the $6.5 million-per-year fee.
- True, but that misses the point. Firstly, when you say “Google should continue to pay the license fee,” you are making a business decision for them. If a company has a $6.5M-per-year expense and they want to cut it, they are well within their rights to do so, even if it affects you personally or they could afford it. They don’t have a contract with you to provide this service. Secondly, not all browser manufacturers can afford it. Mozilla can’t (or won’t), and if I decided to write a browser tomorrow, which suddenly became popular, I wouldn’t be able to afford it either. If Google paid the yearly fee, they would be asserting their vast wealth, and saying “look, we’re one of the few companies in the world that can afford to make a popular web browser.” By not paying the fee, and dealing a blow to H.264, they are saying “we want smaller companies and people to be able to make browsers too. More browsers is better for the web.”
- Google is a hypocrite because they are dropping H.264 in the name of openness, but still support Flash. / H.264 is patented but at least fully open, whereas Flash is closed source. (This makes up about a third of the comments.)
- Not even Google can change the world over night. Flash is currently so entrenched that you couldn’t possibly drop support for it (unless you are Apple and millions of developers and users will bend to your every whim). Google will probably eventually drop support for Flash, once HTML5 is far enough along. But for now it is simply impractical to drop Flash support, while it is quite practical to drop H.264 support.
- In terms of which is more open out of H.264 and Flash, both are published standards. H.264 has open source implementations, but is patented, whereas Flash is a closed-source implementation that nobody has fully replicated yet. This is a totally different issue. With Flash, Adobe is protecting their implementation — their own work (as is their right), but they won’t stop competing implementations. With H.264, MPEG-LA is outlawing all possible implementations, even those which they didn’t write.
- Update: Can I just re-iterate the first point? Google has to pay to put H.264 in the browser. They don’t have to pay to put Flash in the browser. It’s their wallet, not yours. It isn’t hypocritical to use something someone gives you for free (even if it’s “bad”), yet not be willing to pay for something else which is “bad”. (Hey, I should know: I used an iPod which my parents bought me for years, but like hell I would pay for one!)
- Google are probably being paid by Adobe to hold back adoption of HTML5 video
- Google have ties with Adobe due to their support of Flash on Android. But supporting Flash natively is just a way to make the browsing experience better. As I said above, Flash is too entrenched to get rid of, whatever your ideals are — for now. I’ll believe accusations of back-room deals when I see them.
- Google is a hypocrite because YouTube supports H.264.
- Yes. Your point? Everybody supports H.264 (at least in a Flash wrapper). That’s precisely the problem Google is trying to break away from. YouTube also supports WebM.
- Stupid move, and it won’t have any impact. Chrome doesn’t have enough market share. / Nobody will bother to encode WebM just for the benefit of Chrome users.
- True, Chrome only has 10% market share, and that might not be enough to convince web admins to support the format. But Firefox doesn’t support H.264 either (and will soon support WebM). Combined, they have over 30% of the market.
- This is bad for the open web because sites will just go back to supporting Flash. / This will slow the adoption of HTML5 video.
- Perhaps a bit, but since Firefox has double the market share of Chrome, and it doesn’t support H.264, this was already a problem — we can’t move to a pure HTML5+H.264 web while Firefox doesn’t support it. It is better to stay with a proprietary old standard while we build towards an open new standard than transition from a proprietary old standard to a proprietary new standard. Once the transition is complete, we’ll be too exhausted to do it again for another ten years. I disagree that transitioning to H.264 is better for the “open web”.
- I couldn’t believe this extremely narrow-minded comment on the Ars Technica article, under the heading “This hurts the open web”: “even Firefox users would be able to use H.264 video through Microsoft’s plugin for that browser” — how the hell can we call it the “open web” if users of the leading open source browser are forced to use a proprietary plugin which only works on a single proprietary operating system? That’s just the same as Flash, only worse, because it’s for Windows only.
- This is bad for site admins because now they have to encode their video in two formats.
- True. But it’s already bad for site admins who have to support both Flash and HTML5+H.264 for Apple devices (though to be fair these both support the same underlying H.264 codec). These same admins are looking forward to a future where they can drop Flash support, but cannot due to browsers which don’t support HTML5. The problem is, H.264 video will never be supported by the open source browsers, so they will always have to support either Flash or an open video codec. This move might help move towards a single, open video codec.
- Also, since Adobe has announced that Flash will soon support WebM, site admins will be able to provide HTML5+WebM content with a fallback to Flash+WebM for browsers which don’t support WebM directly, leaving only iOS (which supports neither). That would be just as reasonable as HTML5+H.264 with a fallback to Flash+H.264, only Apple can implement WebM if they want to (whereas open browsers cannot implement H.264).
- This is bad for users because suddenly a whole bunch of sites will stop working.
- False. Currently, there are no websites which exclusively support HTML5 video; they all fall back to Flash (obviously this won’t break the web, because otherwise Firefox would already be broken). Therefore, now is the time for any willing browser manufacturers to drop support for H.264 without Flash, before it becomes the standard. It is too late to drop support for Flash without it first being replaced by another standard. Dropping H.264 at this early stage will not affect any users. If we wait, it will be too late.
- By contrast, when Apple dropped support for Flash, that was bad for users because it broke a shitload of existing websites. Apple was so powerful that they managed to get pretty much the whole Internet to switch over to their new patent-encumbered standard, H.264. That was bad for site admins and users.
- All the other browsers support H.264. If only Google continued to support it, we could finally agree on a standard.
- False. Firefox has never supported H.264 (without Flash), and never will. An open source product can’t ever support it, so therefore we will never have an open source browser supporting this standard. Bear in mind that Chromium, the open source version of Chrome, has never supported H.264 either, for the same reason. This is part of Google’s motivation: to make Chrome more open source (the H.264 part of Chrome is proprietary, by definition). Hence the announcement: “we are changing Chrome’s HTML5 support to make it consistent with the codecs already supported by the open Chromium project.”
- H.264 was around in HTML5 first. Why is Google trying to change it now?
- False. HTML5 video was first introduced with Ogg Theora as the standard format. Due to refusal by certain browser manufacturers to support Theora (largely Apple’s support of H.264 on iOS), the codec was removed from the standard. As it stands now, browser manufacturers are free to implement any codec.
- This won’t kill open source browsers. You can still distribute source code, just not binaries.
- False. Or, maybe technically true, but that isn’t how open source works. “Open source” does not refer to programs distributed only in source code. It refers to programs whose source code is available. The vast majority of open source users do not build their software from source. If, for example, Mozilla were to put H.264 support in Firefox, it would become illegal to distribute Ubuntu with a binary of Firefox, and all Ubuntu users would need to compile Firefox from source. Even Google, who currently pays the $6.5M-per-year fee, does not include H.264 support in the open source version of Chromium.
- Furthermore, even if you could argue in court that you didn’t distribute an implementation of the patent, only the source code, this is not a risk many small open source developers would be willing to take. The cost of implementing a web browser is simply too high under this regime.
- Edit: Nick Chadwick points out that FFmpeg (an open source video encoder/decoder) supports H.264 for both encoding and decoding. I am openly wondering how they are able to distribute binaries (and the implications for distros such as Ubuntu). Edit: David Coles points out that free distributions such as Debian and Ubuntu have removed H.264 support (and other codecs) for this reason.
- This is about free-as-in-cost (gratis) not free-as-in-speech (libre). H.264 is open, you just have to pay for it.
- This is a point the Ars Technica article raised. It treads the subtle line between gratis and libre — the implication being that you shouldn’t make this a moral issue when it is merely a financial issue. The problem is, patents are a free-as-in-speech issue. Gratis is about how much something costs, whereas libre is about what you can do with something once you have it (i.e., your freedoms). Now if MPEG-LA had developed an H.264 encoder and decoder, for example, and were charging for it, that would be a gratis issue. You would have to pay for it, but if someone figured out the protocol, they could make their own without being restricted. Instead, the MPEG-LA has given away the spec for free (gratis). But in doing so, they have told you what you can and cannot do with it, and what you cannot do is make a web browser without paying them. Imposing a financial cost on somebody if they take a certain action (once they already have your property) is limiting their freedoms (libre), not charging for a service (gratis).
- H.264 is an open standard. The MPEG-LA have promised not to charge any royalties.
- No, it isn’t. As I outlined above, MPEG-LA will still seek royalties from encoder and browser manufacturers, and site operators distributing behind a paywall.
- WebM is an inferior codec / WebM isn’t as fast because H.264 is implemented in hardware.
- Maybe it is inferior, but it’s the best codec we have that isn’t patent-encumbered. Here is a technical analysis (which is way over my head) of the WebM codec, which doesn’t speak well for it. Edit: See the analysis of WebM and its patent risk (in reply to the above link), which basically explains that WebM was specifically designed to be inferior to H.264 to avoid treading on MPEG-LA’s patents. It is sad times indeed.
- Now of course, H.264 is implemented in very fast hardware on iPhones and many other devices, whereas WebM needs to be decoded in software. But of course, if WebM took off, newer devices could support it in hardware instead, so that argument doesn’t work in the long run.
- Nobody other than Google supports WebM; it isn’t going anywhere.
- For what it’s worth, the WebM Project page shows a very large list of supporters, including Mozilla (WebM will be implemented in Firefox 4), Opera (Opera already supports WebM), Adobe (WebM will be implemented in an upcoming version of Flash), FFmpeg, AMD (owner of ATI), NVidia and ARM.
- Not to mention, Google. Between Chrome, Android and YouTube, that’s a significant chunk of the browser, hardware and content delivery markets.
- WebM might be patented too.
- Of course the problem with patents is you never know when you’ve infringed one. Unlike copyright, where if I create something entirely on my own then I own it, with patents I can infringe someone’s patent merely by inventing the same thing they did. Therefore, nobody can say for sure that WebM doesn’t infringe on any patents and MPEG-LA has audaciously suggested they will begin charging for use of WebM — typical behaviour of a patent troll. But so far, nobody has named any specific patents infringed by WebM.
- Edit: Here is an analysis of WebM and its patent risk.
- This will put Apple at a disadvantage; if the web moves over to WebM, iPhone won’t be able to play video any more / This is a power play by Google to lock out the iPhone.
- If WebM does become the standard, Apple can easily implement it. It is open source and patent free, so it’s not like Google is trying to make everyone use a format they control and lock out the competition. (Of course, implementing WebM in hardware isn’t trivial, but I’m sure Apple have the resources to do it if they were pressed to.)
Edit: I just found this post by an Oracle developer which provides some similar rebuttals to mine.
Unspecified Behaviour 
As far as, the difference between WebM w/ Flash fallback or H264 w/ fallback is that it doesn’t require re-encoding of preexisting content, and was more broadly supported for the latter.
I think the point about YouTube supporting h264 has less to do with the player or file formats they accept, and more to do with the format all of the video they serve, which is h264, last time, I checked.
Personally, I love the idea of an open standard web. Professionally, I want a streamline process, that HTML5/WebM promises. My main complaint, speaking as the Web Director for my company, we will now have to spend time and resources on encoding 1000s of legacy videos for ourselves and our clients. So I get both sides of the issue, which I think some people are missing. $6.5 million for Google to have broader video support or Millions and Millions for public and private organizations to encode old content for a new open standard. Or they don’t and we still have Flash based video players, for another 5-10 years.
To be honest, I’ll probably wait 6-12 months before we make any changes, to see the response of the other players and what happens with Android. WebM is still very immature in my opinion, but ubiquity has to start somewhere, I suppose. If Adobe can add support for WebM to not only Flash, but FMS, and then someone comes out with a brain-breakingly fast WebM encoder, my mind could be changed more quickly.
Yeah, I agree with all of that. It will be a nightmare to re-encode all of the existing videos as WebM. But as I said in the blog post, it is already a problem, as you’ll have to use WebM (or Ogg Theora) anyway to get to the Firefox/Chromium crowd, or stick with Flash+H.264. I agree that WebM is quite immature. I don’t think Google is removing H.264 on the grounds that it’s time for us all to move to WebM. I think they are removing it on the grounds that we shouldn’t migrate to it — we should stick with Flash until we are ready to move to an open standard.
As for YouTube, I believe they do keep all of the videos in H.264 format, but according to Wikipedia, they are making all new content above 720p available in WebM, and have committed to converting their entire archive to WebM at some point.
I think the ars technica article saying its a “step backwards” is overstating things, but my thoughts are rather similar:
– There is an excellent, open-source encoder for h264 – x264
– There is an excellent, open-source decoder for h264 – ffmpeg+friends
– There is a freely-available specification of h264, allowing anyone to write an encoder, or a decoder, that can interact with anything else.
So whats not open about this? Simple, patents. But theres nothing stopping other people forming a patent pool, exactly like h264, and putting us in _exactly the same scenario_ .
Without patent reform, resisting this bullshit is futile – We should just go with the most open standard we have.
Yes so anyone can access an open-source decoder or encoder, but distribution of such things is illegal. That is not open source. Interesting — I didn’t realise FFmpeg had H.264 support. I wonder how binary distribution of it is justified?
Without patent reform, the best we can do is avoid building standards out of patent-encumbered formats. We did it with PNG and now basically everything else on the web; video is the last holdout.
Also, did you read the Ars article? It’s nonsense!
See David’s comment below. (I also updated the article with your suggestion about FFmpeg.)
I always saw h264 as a necessary evil intermediate step to something better than either WebM, Theora, or h264. Much like Flash fallback is a necessary evil to HTML5 Video. Even though HTML5 video spec needs some work, from the last time I looked at it. As far as I know still no true streaming, and still doesn’t do a good job at protecting content, without that “Hollywood” is going to have a hard time moving that direction. That’s why Hulu and Netflix haven’t jumped on the bandwagon.
I think if the world fully converted over to HTML5+H.264, there would be no impetus to again switch to WebM. The concerns seem too idealistic, and not pragmatic enough (despite very real pragmatic concerns for open source users and browser manufacturers, nobody will care). Google is taking a heavy-handed approach and joining Mozilla and Opera in making this a pragmatic concern.
From what I’ve seen of HTML5, the streaming support depends on the browser, the container format and the HTTP server. There’s nothing the spec really needs to say about it: you just start downloading the file and start playing it once you’ve buffered enough. Jumping around the video just requires sending an HTTP request for a certain byte offset of the file.
As for Hulu and Netflix, I think a major problem for such adoption is lack of DRM. HTML5 doesn’t attempt to address this, so Flash will always be needed for sites which require DRM.
Forgive me if I’m wrong, but what it sounds like you are talking about is pseudo-streaming, rather than traditional streaming, like what FMS and Darwin do. In my mind it’s currently more like variable start point progressive download. Video is cached locally like during progressive playback. In traditional streaming data, isn’t cached locally. Think about the behavior of Youtube versus Hulu. On Youtube which is pseudostreaming you can click back to any position in the timeline you’ve cached, and you instantly go there, but going forward you wait. Hulu which is traditional streaming there is a slight pause in both directions while it caches that chunk. Because of this and to my understanding the construction of the protocol, HTTP streamed video is easy to rip-off. I do believe you are correct about different browser supporting different streaming/capabilities, but then aren’t we even in a worse place than the native video format argument. I believe Apple has decent solutions for HTTP Streaming which is more akin to traditional streaming, but I’m not so sure they’ll want to share, let allow make it WebM/Theora compatible. Netflix is also working with others including Apple and Microsoft to come-up with a viable robust streaming and DRM solution. We’ll get there, but it really needs to be part of the HTML5 spec, until then Hollywood will shy away from that distribution method.
Ah, I guess I misunderstood what you meant by streaming. But I’m still not quite sure what you mean. Is the key difference the ability to stop people downloading the video (DRM), or the fact that you can live-stream video as it is being created, rather than having to upload a file to the server?
For the former concern (DRM), well HTML5 never aimed to address this, and there’s really no way to get DRM into an open specification (that is, one which can be implemented in an open source browser). Someone can always write some code to save the video stream, whether it is being pulled from a single file on the server, or a bunch of chunks in a more complicated protocol. I suppose Flash DRM works because the DRM is implemented not in the specification, but in the actual Flash program hosted on the site. In theory, JavaScript could do the same thing, I suppose.
As for the latter (live streaming), I agree. I have heard about weird proposals for serving nine-second chunks of video via normal HTTP and piecing them together on the client side, but I suppose the HTML5 video doesn’t offer a way to do that. I’m not sure how much control you get over the image though. I could imagine some JavaScript gurus could write a client that does just that, downloading them into separate hidden elements and then displaying them on a . So maybe there is a way to do that without updating the spec.
In any event, both of these problems apply equally to HTML5+H.264 and HTML5+WebM. It’s intrinsic to the element, not the codec.
DRM for the most part doesn’t prevent you from downloading/copying the file, it prevents you from doing anything you want with it. Moving to other devices, reencoding, etc. What I’m talking about is making it much more difficult to actually get the file in the first place. Its adding a second layer of protection. You are right that someone can write code to grab the files, just as someone can write code to remove DRM, but when you can do both to the protect the content, like Hulu and Netflix do, it starts to make it much less worth someones time to do so when there are alternatives.
Yes, I agree, I’m not making a distinction between the two video formats in question. Only that the spec needs to include it so that people are who are concerned about such things feel safer and it becomes trivial to implement for those of us that develop online video platforms. Making broad acceptance become an easier and faster proposition.
Matt, I just want to say, I appreciate the actual conversation. It’s vastly different, than what I received on Haarvard’s blog on the Opera Community. I really don’t know why people can’t discuss and accept that there are both good and bad points to this situation. I don’t question in the long run this is good, but not recognizing the issues this will cause in the short term, hurt my head. Thanks again.
No problem. I don’t know where you came from, but it was good to have an opinion from someone who’s actually going to face these issues, but isn’t a raving hothead. Thanks for the informative discussion.
Lol… Twitter #webm … Your’s was one of the extremely few posts, I saw that actually tried to address the elephant in the room of what this does for all preexisting content, which is almost entirely in h264, and particular how it actually effects site admins and architects. It’s been largely ignored or dismissed in other places.
At least in Debian/Ubuntu, ffmpeg is stripped of certain codecs unless you install the non-free package. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/ffmpeg/maverick/annotate/head:/debian/README.Debian
It can make some things a bit of a pain in the ass since the striped packages can causes things like VLC to silently break when attempting to encode video. Anything in non-free/multiverse is not FOSS, but may be legally distributable in some countries/for some purposes. There are other things that can’t be distributed at all (such as decss) and thus have to go into things like Medibuntu (see https://help.ubuntu.com/community/RestrictedFormats).
There’s a lot of hoops to go through even if it might be legal in some countries.
Cheers. There you go — that’s why FFmpeg is not an acceptable solution to this problem.
Tom Greenaway linked me these two articles of interest.
http://techcrunch.com/2011/01/14/webm-plugins/ TechCrunch’s snarky post about the news of WebM plugins for IE and Safari.
http://www.geek.com/articles/news/microsoft-pledges-webm-support-in-ie9-20100519 Microsoft announces they’ll play WebM/VP8 tags when the codec is installed.
What kind of annoys me is that WebM should be trivial to include in IE and Safari. Unlike FLOSS browsers who can’t afford to pay licence fees, WebM should be an easy feature. I think it’s now more political than technical.
Codec plugins are certainly one way to work around the issue (so long as they support the API and don’t just drop WMP or RealPlayer in it’s place). The last comment about Apple releasing a h264 extension for Chrome is possible (if Apple decides that it’s worth the money) though I worry that Microsoft and Apple might just release OS level codec support leaving other OSs like Linux in the lurch. That kind of fragmenting of the browser market is something the video tag was designed to get us away from.
And that’s exactly why callously suggesting that Firefox users simply use Microsoft’s Windows 7 H.264 plugin is a ludicrous idea. It’s far worse than the alternative of using Flash.
Totally agree with you, Matt. I still can’t understand the overwhelmingly negative response to Google’s decision.
Flash is just a wrapper. Use it or don’t use it. It’s up to you. Google may have their own interests like everyone else but I completely support this move as the Internet should be free. The standard codec used has to be completely free not this BS that h.264 is free for sites that are free. Apple is just one of the companies thats killing the open source community. The theft of code and then sneaking patents through has to be stopped.
I wouldn’t exactly call using open source code in proprietary software “theft of code” (as it is permitted by the license). But I do find it quite disingenuous that Apple claims to be big on open source when they mostly use open source but do not produce it (except in the case of WebKit). Regardless, I agree, these patents are very bad for open source software and the web in general.