This is a pretty poor rebuttal to what was actually a fairly well written (like it's opinion or not) article by Ars. Ars fairly clearly delineated the difference between "open standards" and "open/free to use" and this one mixes them up continuously
This statement "Indeed, most sites offer different bandwidth options and video sizes. They are already converting the video!" shows a pretty clear lack of understanding on how most site's encoding processes work (you generally encode once at different bitrates, not once at one and others as you need them)
I have to disagree, the article points out a lot of flaws in the Ars. article. The premise of the article is self-contradictory: H.264 is patent encumbered, open web means open/free to use for anybody, these two don't relate to each other.
I find it dubious to suggest the following: we should use it, just because most other people use it.
Google dropping this codec actually helps prevent h.264's monopoly.
> Google dropping this codec actually helps prevent h.264's monopoly.
A baseless assertion. It’s far more likely that most sites will continue using H.264, wrapping it in Flash for desktop users, and then sending it naked to mobile devices including iOS and most other video-capable phones. Economically, what is the incentive to do otherwise, as a publisher? How in the world do you figure otherwise?
And can you please fucking stop pretending your own definition of “open” is the same as everyone else’s? Open ≠ free. Sometimes people use it that way. But there IS open source software (GPL’d, even) that is NOT free of cost (like many Wordpress themes & plugins), and there IS open source software that has been tripped up by PATENT TROLLS, and when we are talking about open SPECIFICATIONS the word “open” should be demonstrating that more than one party controls it — which IS the case with H.264 but NOT the case with VP8. So if you want to argue about openness, DEFINE your terms and ACCEPT others will not agree, but we CAN and SHOULD be dealing in terms of facts regarding who controls the spec and who can use it for free, not to mention what’s best for users (something Chrome is otherwise fantastically and fanatically obsessed with).
I'm pretty sure when most people hear "open specification," they'll think it means "open for anyone to read and implement" or something along those lines, not "owned by a consortium of corporations rather than a single corporation." I know that's what people mean when they say H.264 is open, but "owned by a consortium" is not the usual connotation of "open."
I'm pretty sure when most people hear "open specification," they'll think it means "open for anyone to read and implement
The shouldn't, thats not what it means. An open specification means that anyone can contribute to the authoring of the specification it has no bearing on licensing terms. Which is the OP's point "open" means a lot of different things.
Those who seem to be opposed to Google's decision are often in the Apple camp (disclosure: I am in the Apple camp) but are also the same people who wish Flash to die because of it's closed/proprietary nature.
So why can't we just envision ourselves embracing H.264 and picture what it'll be like in 10 years? Which camp will be trying to push it out the door because of licensing issues? There will be licensing and royalty issues. MPEG LA is a business at heart. Google is as well, certainly. But WebM could be ours instead of theirs, no?
I think what people miss about WebM is that it isn't perfect - and no one is saying it is. It's not fully developed, but shouldn't we participate in fully developing WebM under an open source/royalty-free vision?
When a big company in Redmond says stuff like this, its called FUD. This is FUD, plain and simple.
What technologies have patents, fees and/or licensing around them?
H264, MP3, Flash, USB, Java, HDMI, CDMA, GSM, LTE, WiMax, Firewire, CD, DVD, BluRay, MP3, AMOLED, and many more.
To argue that computing is going to collapse with the existence of all these is pure FUD. Its FUD when MS does it. It's FUD when Google or the Google camp does it.
Not so fast. These licensed technologies you speak of are not embedded within web browser standards. It's a big difference. Flash, for one, is a plugin. It hitches a ride with the browser, it's not part of its standardized, internal workings.
Google probably will benefit financially from this change and the rhetoric from Google's camp probably is FUD. No different than what Apple is doing with it's proprietary App Store process or it's closed source OS or how Apple's camp (again, I'm apart of this camp) manages to stick-shift through an uncomfortable conversation about open source beyond WebKit.
The difference is that WebM might also help open source as well. Just because it benefits a corporation doesn't necessarily mean it's the devil.
Not so fast. These licensed technologies you speak of are not embedded within web browser standards.
...which is puts them on equal footing with H.264 and WebM. The HTML5 video standard specification does not specify a codec, so no codec can be said to be "embedded within web browser standards" either.
And not embedding h.264 may prevent it from becoming a de-facto standard while pushing WebM, a fully open competitor (that's not perfect yet), may give it a chance of becoming, rightfully, part of a standard.
This was a spit in the face of Apple, and Jobs is the type to hold grudges. iOS devices won't use WebM. And no matter how you slice it, iOS devices will be popular in the formative years of HTML5.
At best WebM splits <video> into a state where its really not much more useful than it is today. Or H264 just kills it anyways, and Chrome dies.
So, because of your questionable personal knowledge of Jobs and the influence he holds over Apple, a video codec will fail? Last time I checked the world didn't run entirely on Apple hardware and software alone.
Having a fragmented standard or no standard at all is usually better than having a very bad one. People can always encode to multiple file types if they want to serve the increasingly large audience that doesn't support h.264.
And, BTW, Android phones just passed their iOS competitors, so, it doesn't matter how popular they will be, Android devices will be more popular. If Google decides they won't support h.264, it will be a serious hit.
I agree with your thesis. I just disagree that H264 is a worse standard than WebM.
On marketshare, while Android just passed up iPhone, something happened this past Tuesday which will probably tighten up the race a fair bit more. On top of that, the report counted iPhone subscriptions. Not iPad or iPod Touch devices. I've heard estimates that iPod Touch + iPad sales == iPhone sales.
And iPad2 is likely hitting the market in a few months.
In anycase the road we're going down is a fragmented one. Maybe people will get it right for HTML6. But I think most of the vendors at this point take the view that they'd rather have a fragmented web, rather than one dictated by their competitor.
> I just disagree that H264 is a worse standard than WebM.
Both WebM and h.264 are imperfect solutions for the same problem. WebM has a image quality issue h.264 has not, but this can be corrected, as WebM can be improved over time. The problem h.264 has - being encumbered by patents you can borrow for free only for a limited time - will not be corrected. If we decide to store all our video in h.264 we risk being unable to play it a couple years from now without paying the MPEG-LA for its licenses.
> iPod Touch + iPad sales == iPhone sales.
All it shows is that it may take more time for Android-based devices to surpass iOS's individual market share. Still, the world is not going to be an iOS monoculture. While we can't say Blu Ray is a huge success, the lack of Blu Ray drives on Apple computers cannot be credited. We consistently over-estimate Apple's influence.
> In anycase the road we're going down is a fragmented one.
I am happy for that. Diversity and competition are the twin tools of evolution. I like fast evolution.
> Maybe people will get it right for HTML6
I don't think the lack of a specification for video codec is such a bad thing for HTML5. Like I said before, the worst that can happen is HTTP header-based media retrieval of multiple encoded files. Where I work, we routinely batch-encode our video content for just about anything between classic iPods and 1080i h.264 (yes) video. Encoding for WebM will not be a heavy burden. If a pocket device asks for a URL, it gets the pocket version. If, a couple years from now, a huge 4K 3D TV asks for the same URL, it will get 4K-sized video. I think I won't have to change a single line of code...
Both WebM and h.264 are imperfect solutions for the same problem.
WebM has a image quality issue h.264 has not, but this can be corrected, as WebM can be improved over time.
Certainly it can be improved over time, but the degree of improvement will be limited to features not covered by the hundreds of video-centric patents that comprise H.264 (assuming WebM isn't already violating any of those patents). Additionally, H.264 encoding technology can be improved over time. You'd be hard pressed to make any technical analysis that demonstrates WebM could ever improve enough to exceed H.264 and it's encoding improvements. The probable reality is that H.264 will always have a not insignificant quality lead over WebM.
The problem h.264 has - being encumbered by patents you can borrow for free only for a limited time - will not be corrected. If we decide to store all our video in h.264 we risk being unable to play it a couple years from now without paying the MPEG-LA for its licenses.
That's not an accurate summation of the H.264 license. H.264 delivered for free on the web will always remain free. H.264 delivered at cost to the viewer is currently free. For more details on the cost H.264 licensing, refer to this: http://www.zdnet.com/blog/bott/by-dropping-h264-is-google-av...
So perhaps neither WebM nor H.264 are perfect ... but using the two points made to highlight the imperfections of each shows that perhaps H.264 isn't as imperfect as some would make it seem.
I'm impressed you guys encode that much. I don't think you're the common case.
The case where WebM dies is that everyone continues to encode with H264 (which is what they're doing now). If you're IE or an iOS device you get raw H264. If you're Chrome or Firefox you get H264 in Flash.
You just encode H264 and that's it. Now dual encoding, and you work everywhere.
Whereas with WebM there is NO delivery mechanism to iOS devices (iOS won't play WebM and won't play Flash). You have to dual encode to get those devices. Just seems like a less likely scenario.
> I'm impressed you guys encode that much. I don't think you're the common case.
Compared to the effort it takes to produce the content, encoding is negligible. We have a complete studio and a dedicated team producing a couple hours of original material every week. Originals are kept as uncompressed as possible storage-wise and are captured at the highest quality the equipment allows. Encoding happens in a server that's nowhere near capacity.
I proposed a presentation on it at the last FISL but it didn't make the cut (for which I am glad - two others did and it was quite enough work preparing them).
I can tell you exactly how, as many others already have in this and other discussions: flash is a plugin; h.264 support is native browser code.
Google bundles flash for one reason only: to make sure that users aren't given the chance to shoot themselves in the foot by not upgrading. Everyone downloads the flash plugin because sites require it. It has 98% penetration (perhaps less now with more people using iDevices, but still very high). But people never update the plugin, which is a major security issue. Google has solved that problem in chrome.
And you are mistaken that flash is part of the internal workings of chrome. You can disable it: see about:plugins. And there is no need to update it since chrome takes care of that for you.
To those who pointed out that a codec is not a part of the browser standards, you are correct. I misspoke. I don't know why since I remember that Mozilla also took this stand a while back. Apologies. :)
and none of those are required to produce or consume web based content.
I dont need to pay anyone in order to write text on the web, I dont need to pay anyone in order to share images that I have created, I dont understand why people think its ok that we should have to pay to share the videos we create
I know mpeg-la arent actually charging end users (yet), but that doesnt matter, someone has to pay
>When a big company in Redmond says stuff like this, its called FUD. This is FUD, plain and simple.
Even if they say the sky is blue?
I don't even know why you're dragging MS into this. They've already stated that IE9 will pick up WebM codecs if they're installed on the machine and will use it play HTML5 video.
They just don't want to ship it with the OS and step onto patent landmines which could cost them billions in lawyer and licensing costs. Google does not provide patent indemnity with WebM.
I brought MS into it, not to bash MS, but to point out how hypocritical these arguments often are. If MS says something with no substantiation, but merely an attempt to create fear, uncertainty, and doubt in the future, people are up in arms yelling FUD. But when Google does it it's about the greater good of humanity.
It's not Google making up FUD — Google is noting an objection that's been around for a long time, and they're doing something about it. Mozilla has been saying the same thing for a long time.
And I don't know how you even create FUD about something like this, where the uncertainty is based on traps that are known to exist, which most users are currently standing on but simply haven't been triggered yet. Is it a controversial claim that H.264 requires a patent license? Is it a controversial claim that MPEG-LA has only offered a limited-time indemnity, and that only for a subset of uses? This is all verifiable and documented.
FUD, FUD, FUD, FUD. Now it's FUD that you may subscribe to, but it's FUD nevertheless.
I love this line, "where the uncertainty is based on traps that are known to exist"
Have you never bought a DVD player in fear of MPEG-LA might do? Do you own no computers with no licensed technology? I shiver in my boots every morning for fear over this.
Gimme a break. I love how the Google/Mozilla tribe have become the world's best FUD slingers. Everything now is about this horrible tragedy that can happen at any moment.
If that's your choice fine. Stick with Chrome and stay away from H264 streams. Like I said to RBanffy, a fragmented web won't keep me up at night either.
I don't shy away from buying DVD players. The companies that make them are the ones on the hook there. But I certainly wouldn't want to build one.
Again: We have no guarantees from the MPEG-LA that they won't turn around tomorrow and demand outrageous royalties from anyone using H.264 videos. We also know that they are able to do so. The only reason it isn't so today is by their good grace. That is real uncertainty, and it seems like a valid cause for worry (Google would have been better off if they'd treated Java so cautiously). Am I mistaken somewhere, and this situation is actually not plausible? I'm not personally involved with either camp — they just seem to have the facts on their side, while all any pro-H.264 folk ever respond with is ad hominem and dismissals.
We have no guarantees from the MPEG-LA that they won't turn around tomorrow and demand outrageous royalties from anyone using H.264 videos.
Yes, we do know that, for the same reason that they don't start charging end users of DVD players. They have legally binding agreement.
For free video, H264 is permanantly free. They can not turn around and change this.
For non-free video, they have established pricing that is locked-in until 2016. And then you're saying, but then they'll screw me, right? Wrong, MPEG-LA states in their contract: "For the protection of licensees, royalty rates applicable to specific license grants or specific licensed products will not increase by more than ten percent (10%) at each renewal."
So enough with the FUD please. H264, amongst licensed technologies, is probably one of the clearest there is and with the least minefields.
To me it is about permission and free legal redistribution. If H.264 were to become an entrenched part of HTML5 video, then freely distributed browsers would greatly suffer. Open source browsers like Konqueror would be left by the roadside. This is why I think Google is doing a good thing. HTML5 video suffers in the short term, but it is a good thing for the future.
You could say the same for any tribe, I think. I like Google but I doubt that they are making decisions for the greater good intentionally, or all the time. I do think that Google, like Apple, try to swing their business model towards a better design or better implementation. In a lot of those cases, the better implementation or design is open source or built for the greater good.
No. WebM could be Google's instead of MPEG-LA's. WebM is a Google project, Google-owned and Google-managed. Much like Android, it is open source so that anyone can see the code and make their own changes, but again, like Android, it is not a community effort. There's a chance that your changes, if useful, will make it back in, but in the end WebM, like Android, is controlled not by the community, but by a corporation.
Essentially the comparison being made is between open source and open standards. The WebM implementation is open-source, but it is not an open standard. There are also open-source implementations of H.264 (e.g. x264), but H.264 is also an ISO/ITU standard which anyone can read and implement. WebM, however, is royalty-free, whereas H.264 is not.
WebM has two of the three (open source, royalty free). H.264 also has two of the three (open source, open standard). If Google submits WebM to a standards body for approval, it will have all three.
Until Google does submit it as a standard, it's still Google's format, not ours, they're just letting us use it for free. Down the road they can always change the format, the container, add new features (like some kind of inline advertisement), and anyone who's invested in implementing this format will have to scramble to add the new functionality or be left behind.
Will they? Who knows, but the price you pay for implementing WebM right now is uncertainty. With H.264, you know exactly where you stand, and the licensing terms are specific, and corporations like that about it.
So why can't we just envision ourselves embracing H.264 and picture what it'll be like in 10 years?
You mean imagine when we're 2 or 3 years from the last of the H.264 patents expiring? At that time I would expect it to only be ditched for something that offers substantially better quality/bitrate.
"Google dropping this codec actually helps prevent h.264's monopoly."
How about a Google monopoly? At least h.264 is owned by a number of different companies. Never mind that almost everyone agrees that it is the better codec.
> How about a Google monopoly? At least h.264 is owned by a number of different companies.
It's amazing to me. In the 90s Microsoft's overt policy was "embrace, extend, extinguish," and it called the GPL a "cancer," the MPAA was launching war against DeCSS, and Amazon.com was flexing its one-click patent against competitors. Open source developers had no powerful allies.
Now you have a powerful company like Google that releases millions of lines of open source, sponsors college students to work on open source, fights for openness standards in wireless spectrum auctions, fights for open standards like HTML5, open sources its entire mobile operating system, and in its latest move, buys a video codec company for $106 million and promptly pledges all of the patents for use by anybody.
And yet some people would prefer the codec whose rights are effectively owned by a known patent troll (MPEG-LA) because "at least [it] is owned by a number of different companies."
It goes to show that you can never please everyone.
Why doesn't Google release the source code of the flavor of Linux that it uses after earning tens of billions basically leveraging Linux code?
Google open sources things that are not central to it's business, just like every other company out there.
MPEG-LA cannot be a patent troll let alone a known one, because it's a loose organization of companies that agree on a standard to prevent fragmentation of video and let people deal with one entity instead of a thousand. Those individual companies could be trolls.
>fights for open standards like HTML5
Really? Then this move to remove support for H.264 will get Flash even more entrenched because it would be the easiest way for content providers to get WebM video working on IE9 and Safari. Flash has already announced upcoming support for WebM.
The MPEG-LA patent troll is a reference to MobileMedia, a Non-Practicing Entity (aka patent troll) that uses patents it got from Sony and Nokia and sued Apple, Rim and HTC within months of forming as a company.
MobileMedia is owned by, and shares a CEO with, MPEG-LA (who also licence non MPEG patent pools e.g. Firewire, the name alone is a bit misleading if you ask me).
> Why doesn't Google release the source code of the flavor of Linux that it uses after earning tens of billions basically leveraging Linux code?
Because the GPL does not require them to do so.
If the GPL required them to do so, nobody would licence their code with it, and only the most batshit-insane people would dare use code licensed under it. Would YOU want to run a Linux server if it obligated you to provide a complete dump of source code to anyone who asked? Seriously people, think before you write.
> MPEG-LA cannot be a patent troll let alone a known one, because it's a loose organization of companies
MPEG-LA manage a suite of patents and can issue press releases, therefore they can be a patent troll.
MPEG-LA cannot be a patent troll let alone a known one, because it's a loose organization of companies that agree on a standard to prevent fragmentation of video and let people deal with one entity instead of a thousand.
Also, the licensing terms are fixed at a maximum 10% rise per five-year renewal. Given the lifespan of patents, that's a low ceiling.
Also, the licensing terms are fixed at a maximum 10% rise per five-year renewal. Given the lifespan of patents, that's a low ceiling.
This is the first I've heard of this. Since one of the main concerns I've heard is that MPEG-LA could raise fees to unacceptable levels, do you mind providing a source for this? I'm still less comfortable with H264 being the standard rather than WebM, but this makes me less worried. (Anti-FUD?)
Considering how the large corporations easily reach the annual cap (currently $6.5 Million per year until at least 2015), the footnote that the 10% maximum increase in royalties does not apply to the cap is a bit disconcerting.
Ah, that explains how the cap has managed to go from $5 to $6.5 million (a 30% rise) since the last time I looked at it, which certainly wasn't 15 years ago.
What does owning a video codec even mean if you make it royalty-free? Is there a concern that if webm becomes widely used Google will use its control of the code to harm competitors? In that case, you should know that the webm project is in fact run as a separate project from Google[1].
In real life you easily can, because of incompatibilities with the existing software. Eg. Chrome and Android are technically open-source but their direction and development are completely governed by Google.
If you make changes and are unable to convince Google to incorporate them, the video generated by your software will be incompatible with all the millions of WebM decoders out there.
I do not care about WebM or H.264 since I dislike both, my comment will concern the license and the situation.
WebM have a Apache style license, you can grab the source, fork it and develop your codec, and you're not even obligated to open a repository including your changes, they can remain closed.
Google will not stop you from doing so and guarantees that he will not sue you asking for royalties, since a license like the Apache license gives the use of the patent for free.
The case of Android and Chrome is simple, Google employes the majority of developers in both projects, however Google does not employes the majority of Linux kernel developers an as a result much of the Android code isn't in the kernel.org code.
Similarly the directions of Webkit is decided by the two main committers: Google and Apple.
Actually, recoiledsnake's scenario has already happened. The VP8 "spec" isn't a spec at all, it's just copy pasted C code. Unfortunately, they also chose to reuse the same code for the encoder and the decoder. This means bugs in either one can propagate into both. There was already one of these bugs found, fixed, and had a patch applied to the source tree. Google came in and reverted that patch because too much video had already been encoded with the bug in the encoder. This is exactly what happened with IE6, where bugs in the product become de facto requirements on the web.
Maybe the H264 spec drones on and on but at least it's a spec. The VP8 "spec" is just a mandate from Google. A shitty one, at that. I'll take the small risk of patent litigation among only the biggest players for an open specification and standard any day. Of course, there's also the fact that H264 is way better than VP8 which it seems like no one cares about.
Write a spec, not a "bitstream guide," so that this problem doesn't happen in the first place? Or at least admit that your spec is not finalized and is, in reality, a piece of crap that needs wide peer review first.
I am talking about practicality or the chances of it happening. Anyone can do what they want, but if it's incompatible with the 800lb gorilla's offering, it's basically a moot point.
You clearly haven't read the article. Flash is a sandboxed plugin running alongside the browser. It's not the internals of a new and heatedly debated HTML tag, which ultimately has to be an open standard and format, and supported until HTML6 comes around in another decade. Choosing to drop experimental support for a closed, proprietary, and royalty-encumbered codec in a tag's specification that hasn't even been finalized by the W3C yet isn't even in the same universe as dropping support for an external plugin.
Supporting arbitrary codecs is more like supporting arbitrary font formats. Each separate codec uses its own (potentially vastly) different way of encoding video, and requires its own code to handle. Using the operating system facilities is too risky from a security standpoint (such as if someone finds an exploitable bug in the ancient Indeo codec).
Can't drop something you didn't have in the first place.
As many have argued, it's disingenuous to treat Flash and the H.264 as being equal in this argument. One of these would be implemented into the browser rather than a plugin. One of these would incur a royalty cost. One of these has viable alternatives.
Last March, Adobe and Google jointly announced that Flash Player would soon come built in to the latter’s Chrome browser, eliminating the need for users to download, install and update it separately.
sure. not sure how this is relevant tho. if dropping h.264 is a good thing, then Google should drop it. kind of irrelevant whether it also does or does not drop Flash.
All the outcry over this I've read is basically a complaint that you can't ship one codec for HTML5 video, which you've never been able to do. That's what the whole argument over the video tag has always been about.
The only difference this makes is that this cements the split instead of everybody expecting Firefox and Opera to give up and adopt H.264. If you were willing to ship just H.264 and flash fallback for Firefox/Opera, why wouldn't you be willing to ship H.264 and flash fallback for Chrome?
On desktops, falling back to flash for H.264 decoding is a pretty good strategy.
On mobiles, though, Google's change has a bigger effect. Flash is abysmal (if existent) on Android devices--and now there is no clear solution that doesn't involve serving multiple encodings.
Before this change, you could be comfortable that your H.264 HTML5 video would play on the majority of smartphones; the flash fallback was only necessary for desktop browsers.
There is no Chrome for smartphones, and so far no one has said anything about dropping H.264 on Android (although you can see it happening as soon as WebM extensions for ARM start being more popular).
You are correct, but why would you imagine Google would treat Android differently? Even though they haven't announced any changes specific to Android, I expect Google's left and right hands to work together... eventually.
They'll almost certainly have an H.264 chip but the standard Android browser (and Firefox and Opera Mobile) might not take advantage of it when faced with an HTML5 video tag.
Maybe we'll see Apple and Microsoft release browsers for Android!
From what I understand, the main reason for Mozilla and Opera not wanting to include H.264 is that there would be licensing fees for including a decoder with the browser. Correct me if I'm wrong, but it could potentially cost both Mozilla and Opera a significant amount in licensing fees to include H.264 support.
Apple doesn't care because it's already a licensee, the same for Microsoft (including in Win7) and Google (encoding for YouTube).
The fee would be about $5 million a year. Arguably, both could afford it (it would be about 5-10% of revenue, but doable).
The reason Mozilla is not wanting to include H.264 is that:
1) It can't do that in the open source version, and doesn't want to have separate open-source and closed-source releases.
2) It feels H.264 would be bad for the web, since it requires paying to create content in H.264.
Reason #2 is somewhat more important than reason #1, since #1 could be worked around by using system media frameworks, etc.
Both of those things are misleading or wrong. There's no reason why they would have to make it closed source, especially if they use x264. H264 patents don't require everyone to pay to create content, you should read the MPEG licensing agreement.
> There's no reason why they would have to make it closed
> source, especially if they use x264.
That's not what the lawyers said. In the US, at least; things may be different in your jurisdiction.
Note that this is the route Chrome used to take: Chromium did not support H.264, while the Chrome binaries, built from some source that was not public, did.
> H264 patents don't require everyone to pay to create
> content
They do require you to pay to produce an encoder. Of course someone can then distribute said encoder for free if they want, so the end user doesn't technically _have_ to pay. But in practice they do.
And if you use an unlicensed encoder, then you're infringing on the patents. So is anyone who views any videos that were produced with the unlicensed encoder, even if their decoder is licenced. And some other restrictions to do with the fact that encoders are typically not licensed for arbitrary use (e.g. the encoder in a typical digital camera doesn't give you the right to put the resulting video on a website that you make money from, via Google Adwords, say). You should in fact read the licensing agreements involved, or at least the excerpts in http://bemasc.net/wordpress/2010/02/02/no-you-cant-do-that-w...
You are spectacularly incorrect about how Chrome and Chromium are built — the only difference between the two regarding <video> is which flags the bundled copy of ffmpeg's libavcodec was built with.
There is no secret source code. When you build Chromium, you can just swap in a symlink to your system's copy of libavcodec, and then it magically supports whatever codecs that one was built with.
Even if you decide to use a closed-source decoder, just because the decoder has to be closed source doesn't necessarily mean the entire browser has to be closed. What exactly was the lawyers' reasoning behind this?
They do require you to pay to produce an encoder. Of course someone can then distribute said encoder for free if they want, so the end user doesn't technically _have_ to pay. But in practice they do.
And if you use an unlicensed encoder, then you're infringing on the patents. So is anyone who views any videos that were produced with the unlicensed encoder, even if their decoder is licenced.
What are you talking about? The page you linked clearly says that non-commercial content is free. I didn't say that no one has to pay to create content, I said not everyone has to pay to create content.
> doesn't necessarily mean the entire browser has to be closed.
Right. I did say that #1 can be worked around. If you you you approach, you still get the Chromium/Chrome model, where you can't release the actual source to the binaries you ship, and worse yet others can't easily fork your "open-source" app while keeping the functionality or redistribute your binaries.
> The page you linked clearly says that non-commercial content is free.
"commercial use" in that context includes putting it up on a website that has ads. So yes, not everyone has to pay to create content. If you find someone who will give you a free encoder for which they paid the licensing fees, and you make sure that either you don't put your content on the web or if you do that there are no ads on the page and you don't charge for the videos, then you can get away with paying nothing.
Quick; name me the places on the web where there are free videos and no ads. I'd love to know where this is!
"commercial use" in that context includes putting it up on a website that has ads. So yes, not everyone has to pay to create content. If you find someone who will give you a free encoder for which they paid the licensing fees, and you make sure that either you don't put your content on the web or if you do that there are no ads on the page and you don't charge for the videos, then you can get away with paying nothing.
Quick; name me the places on the web where there are free videos and no ads. I'd love to know where this is!
You completely misinterpreted that. First, the author pulled ads out of his ass -- there's no legal statement to support that theory. Second, the statement from MPEG-LA that I linked to trumps that article -- as long as you're not charging for H264 encoded content you have nothing to fear.
You're misunderstanding the statement. That seems to be pretty common.
H.264 has royalties that you need to pay to produce a licensed encoder.
Then it has _separate_ royalties you have to pay to take content encoded with a licensed encoder and send it to someone else.
Furthermore, whether an encoder is "licensed" depends on what you do with its output; the details are in the license that came with your encoder.
The statement you linked to is that the royalties on sending to someone else don't have to be paid as long as you're giving it to them for free and sending it over the internet _and_ your encoder is licensed for whatever else is going on (e.g. if you're making money in the process then your encoder has to be licensed for that).
I'm saying that to produce the content in the first place you have to pay money to the MPEG-LA. If you don't, then anyone you send it to has to pay money to the MPEG-LA. Here "has to" just means "they can sue you and will win if you don't, since the licensing terms don't allow you to do that". They might, of course, not sue you. That's up to them.
Further, most encoders out there are not licensed to produce content you make money from (note that this is NOT the same as charging users money). So you'd have to buy your camera, then pay the MPEG-LA for an encoder license that allows commercial use. This is a one-time payment. Then you could stream the resulting encoded media as much as you want and not have to pay for each download that happens. The per-download fees are what they waived.
You are again spectacularly incorrect, this time about the relationship between the distribution of open source code and patent law.
It is perfectly 100% legal to distribute uncompiled source code without a license to any related patents. After all, it's a description of the patented machine and not the machine itself, much like an ideal patent application. Where you run into trouble is distributing the compiled binaries, the actual machines covered by patents.
You can get into no trouble at all over source tarballs of ffmpeg, but Debian is deathly afraid of hosting usefully-compiled debs of it in their repositories for a reason.
I didn't say anything about distributing source code. To a first approximation users download binaries, not source code (things like Gentoo and MacPorts are edge cases; very few users use either one, really) .
What I said is that the old Chrome model, wherein the official binaries ship H.264 and have a paid-for license, if adopted by Firefox, would have meant two things, as I understand:
1) If someone wants to take the Mozilla binaries and redistribute them (possibly with some simple changes like a different default theme or a default preferences file that whitelists some intranet sites or whatever) they have to pay for an H.264 license. Things like copying Firefox from your computer to your friend's computer would need you to have an H.264 encoder license, since you're creating a new encoder (now it happens that the license fee for that level of distribution is 0, so you're actually ok; just don't put that modified package on a public web site).
2) If someone wants to fork the Mozilla codebase and build a browser with equivalent functionality and distribute it, they have to pay for an H.264 license.
#2 there is precisely what GPLv3 is intended to prevent, by the way. Mozilla is licensed under GPLv2, so this would be within the letter of the license, but arguably not the spirit. Certainly we felt that it would not be within the spirit.
I'm kind of curious... It seems like the MPEG-LA is doing great work by creating all these video and audio compression codecs. MP3 is used by everybody, MPEG2 was good for the day, and now H.264 is even better. Plus, nobody else seems to be coming up with something compelling. Sure, there's WebM and VP8, but if I recall correctly, they are, at best, at parity with H.264. It seems like here's a good case of patents being useful: the MPEG people do research and create great codecs and we all pay them a $1 (or something) in licensing fees so we get small video. I'm all for open standards and free and Free software, but it seems like H.264 is a net will, compared to what we'd have without it. (Remember the days of huge .wav files and electronic .mod files before MP3 came out?)
You know what we actually need? A h.264-buyout. Let's ask MPEG-LA how much they are planning to earn by the time their licence runs out (2024?). It will probably be ~200 Million or so. Then ask the whole internet to chip in.
Result: all the open source people are happy, and we all get to use the higher quality codec in any application we can imagine. And we also get to keep our devices with their battery efficient dedicated h.264-decompression chips.
Or we could just use VP8. All the open source people are happy, the codec will quickly improve, and the vast majority of your devices with their battery efficient dedicated H.264-decompression chips will be replaced by devices with battery efficient dedicated VP8 and H.264-decompression chips within three years. We also save 200 mill.
I am sorry, but codecs don't work like regular software. Fixing bugs and issues in the encoder could make the resulting video incompatible with older decoders (decoders and encoders are not easily updateable in firmware devices such as consoles, set top boxes, mobile devices etc.).
Therefore it's important to have a proper spec in place and then improve encoders and decoders. A dump of C code is not a spec like Google did with VP8.
Well they did valuable work. It's only the MPEG-LA that's acting badly. In fact, one should probably bypass the MPEG-LA and talk directly to the patent holders.
Not really. If anything, it's the eventual use of market power for profiteering.
> But it would become another closed de facto standard, just like IE6.
Huh? IE6 is a browser not a standard.
> This is comparing apples and oranges. Flash is a plugin,
This is splitting hairs and a straw man. The user does not care or typically doesn't differentiate between something that's part of the browser and something that is a bundled plug-in. The user experience is basically the same.
So any argument using a criteria about building in a proprietary and closed standard to the browser versus bundling a proprietary and closed plug-in is at somewhere between fatuous and disingenuous.
> If you want to do any kind of video on the web, you don't have a choice. Flash is needed.
WRONG. Bizarrely wrong in fact since we're arguing about the HTML5 container for video and supported codecs. Flash isn't involved. This isn't vapourware either. Modern browsers already support it.
> it is much more likely that an open format will prevail in the end.
If there are two dominant standards, sites will be faced with a choice: double-encode everything or pick one. Many have already picked H.264. What's more likely? Double-encoding or simply delivering H.264 to Chrome via a Flash (rather than HTML5) container?
If anything, this move prolongs the existence of Flash.
> Just because a format is widespread offline does not mean that it is suitable for use on the web.
Is the author really suggesting H.264 a) isn't widespread on the Web and/or b) isn't suitable for use on the Web? Really?
> In other words: The processing will always be there, and instead of re-processing to a slightly more compressed H.264 file for online play, it can be converted to an open format.
If the author thinks this move will displace H.264 they are sadly mistaken. For one, the license fees for using H.264 are negligible for the largest players. For another, there is an enormous installed base of devices with hardware H.264 decoding. Hundreds of millions in fact, most notably the various Apple iDevices.
These provide a compelling use for the continued use of H.264 in the long term.
> As already explained, videos are typically re-encoded or processed in some way anyway.
Yes but double the processing and double the storage are real issues.
> Notice the word "plugin". It means that we're basically removing HTML5 video, and returning to plugins. All the benefits of native video disappear just like that
What benefits are those exactly? At least for now the user experience, HTML5 video is still playing catch up to Flash video in terms of user experience.
> If I am not mistaken, the share of open standards based browsers is growing at the expense of Internet Explorer.
Worst case for IE is still about ~50%. That still makes it the single largest browser. Chrome's share exceeds Safari's (AFAIK) but the latter is still significant and I can't imagine it getting WebM support anytime soon. Apple are very much wedded to H.264 support by virtue of their devices if nothing else (anecdote: I played 6 hours of video on a plane on my iPad using 10% of the battery).
> it is H.264 which takes away choice.
By definition, not giving someone a choice takes away choices.
All of the arguments for this move seem to be focused on the long term. That's fine but in the short term it will unarguably cause users and sites headaches.
> I also find it puzzling that Google is being accused of giving users fewer choices, while Microsoft and Apple aren't even mentioned.
Hold yourself to a higher standard (and, more importantly, preach those standards to others) and you will be the recipient of greater scrutiny.
At best, the author's argument descends to "two wrongs make a right".
Note: I'm saying arguing in favour of Flash. In fact, I consider the lack of Flash on my iDevices to be a feature rather than a limitation.
Ironically this moves will likely prolong Flash and slow the adoption of HTML5 as a result.
> But it would become another closed de facto standard, just like IE6.
Huh? IE6 is a browser not a standard.
Well, neither can H.264 be a standard, it is a non-free codec for video. The key was de facto..
Internet Explorer 6, at the peak of its dominance, became the standard that many web developers developed for. Even though it wasn't a standard, when it had over 90% of the market, it was often the only browser that was developed for and other browsers were locked out or suffered. Browsers like Opera spoofed as IE by default, Netscape had quirks to behave similar to IE in some respects...
It's saying that everyone who wasn't on H.264 would suffer or be forced to conform, as was the case with IE6 for some time.
I can see the point you're arguing (or at least what the author is trying to argue, whether or not it's your opinion as well). But it's at best a stretch.
In the IE6 "glory" days, it wasn't just a case that Websites wouldn't be made to work for other browsers (meaning they were never tested or, if they were, it was beyond scope to fix). It was worse than that. Sites would deliberately look at the user agent and simply not work if it was a non-IE browser. This still happens. I still come across sites that not only warn you they're optimized for IE and FF (ie proceed at your own "risk" when using Chrome). Some go further and simply won't work if you try and use Chrome. It's thankfully rare but it still happens.
Anyway, the point here is the IE6 displayed HTML/CSS content differently than other browsers and had JS differences too. It took effort to make things cross-browser and it was (and arguably still is) a big deal.
So the stretch of comparing H.264 to IE6 is twofold:
1. We're talking about the entire Web vs the narrow context of Web-based videol so it's a question of scope; and
2. Converting video from one format to another can be automated. Converting a site designed for IE6 to work on other browsers cannot.
So not only aren't the problems analogous but the author is engaging in scaremongering to try and equate H.264 with the (stipulated) horrors of IE6.
>2. Converting video from one format to another can be automated. Converting a site designed for IE6 to work on other browsers cannot.
Sure it can. You run it through IE6 and print to an image format of your choice.
>1. We're talking about the entire Web vs the narrow context of Web-based videol so it's a question of scope; and
Yes, and thanks to the narrower scope it's not as big a deal to convert between video formats, but there's still going to be a marked loss of quality.
>So not only aren't the problems analogous but the author is engaging in scaremongering to try and equate H.264 with the (stipulated) horrors of IE6.
Viewing a website designed specifically for IE6 is likely to cause similar loss of fidelity to viewing a video transcoded from VP8 to H.264, or vice versa.
>Let's not split hairs. Browser != data format.
The data format in question is the HTML accepted by IE6. That data format actually works fairly well with modern web browsers, much like VP8 decoders will likely be bundled with H.264 encoders once the patents run out and H.264 can properly be called an open standard.
"Works on IE6" is a type of HTML/CSS/JS that works on IE6. People had to make websites to work on IE6. That meant new features of the web (HTML, JS & CSS) could not be used because they didn't work on IE6.
> > But it would become another closed de facto standard, just like IE6.
> Huh? IE6 is a browser not a standard.
If you don't understand why the article is correct, you really don't understand the topic. It's fine to disagree, but this statement demonstrates your complete lack of knowledge in the area.
> > It's called bait and switch.
> Not really. If anything, it's the eventual use of market power for profiteering.
Personally I think "bait and switch" fits here correctly.
> > But it would become another closed de facto standard, just like IE6.
> Huh? IE6 is a browser not a standard.
I don't think that you understand what "de facto standard" means. Or maybe you understand, but choose to ignore it to make bullshit argument.
> > This is comparing apples and oranges. Flash is a plugin,
> This is splitting hairs and a straw man.
Really? I thought we are talking here about video codecs not Flash. Please stick to meritum. Dont use red herring. Why do you insist to bring Flash to discussion about two video codecs?
>WRONG. Bizarrely wrong in fact since we're arguing about the HTML5 container for video and supported codecs. Flash isn't involved.
Oh so now you insist that Flash isn't involved in this discussion?
> This isn't vapourware either. Modern browsers already support it.
But old browser are still here for at least couple years. I still have to deal with people using IE6 - 10 years after original release. One of the ways, for people building websites, to deal with old browser is to use Flash for certain tasks. So some websites still require Flash as they need to deal with this type of users. But let's not divert this discussion to Flash as it's NOT what we are talking about.
> If there are two dominant standards, sites will be faced with a choice: double-encode everything or pick one. Many have already picked H.264. What's more likely? Double-encoding or simply delivering H.264 to Chrome via a Flash (rather than HTML5) container?
True, there will be probably double encoding involved, but most likely only for certain period of time, the time of transition. Once WebM will gain popularity, double encoding will end, as majority of providers will chose free format.
And google just took first steps to popularize WebM.
> If anything, this move prolongs the existence of Flash.
Here we go again. You bring Flash to discussion whenever you don't have another argument. But if you insist - there is still massive hole in your logic: "> What's more likely? Double-encoding or simply delivering H.264 to Chrome via a Flash (rather than HTML5) container?" I don't know if you realize but major players (youtube, vimeo, etc.) in web video double-encode at least since a year - at least to VP6 and h.264.
But there is even bigger hole in your logic: "...simply delivering H.264 to Chrome via a Flash..." - you just contradicted yourself by saying that it's in fact h.264 that keeps Flash alive (that you hate so much). If we remove h.264 and propagate WebM, we will remove flash as a fallback dependency.
> > Just because a format is widespread offline does not mean that it is suitable for use on the web.
> Is the author really suggesting H.264 a) isn't widespread on the Web and/or b) isn't suitable for use on the Web? Really?
a) No, not really. You're putting YOUR words in original author's mouth. He said that it's widespread offline. He didn't said anything about it's web share. Your biased point of view implied this.
b) Yes, he meant that, but you skipped context of the article. Article is in context of OPEN web, and in that context H.264 isn't suitable.
> If the author thinks this move will displace H.264 they are sadly mistaken. For one, the license fees for using H.264 are negligible for the largest players.
License fees for large players might be negligible but if another - free - format will become widespread enough they will simply switch to that free one, as there will be no reason to pay that fees. And as most big players are public companies, or parts of public companies, they have obligation to shareholders to maximize profits which is easy if you can cut costs.
> For another, there is an enormous installed base of devices with hardware H.264 decoding. Hundreds of millions in fact, most notably the various Apple iDevices.
And that step by Google is an attempt to change it. And given time it will change. First new devices will incorporate hardware encoding of WebM along with h.264. Later, given time they will abandon h.264. You think in categories of months. Big players think in years. Also, I remember people using similar argument against Android, and now android sells biggest number of smartphones.
> These provide a compelling use for the continued use of H.264 in the long term.
And to force world to use paid format for long term.
> Yes but double the processing and double the storage are real issues.
But adoption of WebM will not change situation. We encode to multiple formats whether WebM is here or not. And long term view is that widespread adoption of WebM might actually end that and end licensing fees. So double savings.
> What benefits are those exactly? At least for now the user experience, HTML5 video is still playing catch up to Flash video in terms of user experience.
So now you're arguing that there are no benefits of html5 video? What about the benefit of knowing that user of certain browser definitely have support for your video without requirement of using plugins, which might or might not be there? Honestly, are you trying that hard to shoot yourself in the foot, or are you just picking arguments when they are suitable to prove your point, whatever it is.
> HTML5 video is still playing catch up to Flash video in terms of user experience.
Are you now in favor of using flash instead html5 video? Sure html5 video is playing catch up with flash, but it's playing catchup regardless we use h.264 or WebM. And again, given time html5 video might catch up. If it will not than we will still use flash regardless if dominant codec will be h.264 or WebM.
> Worst case for IE is still about ~50%. That still makes it the single largest browser.
> I can't imagine it [Safari] getting WebM support anytime soon.
Apple might change their mind anytime if there will be money or pressure involved. Just like they finally removed ban on flash apps from appstore.
> By definition, not giving someone a choice takes away choices.
But you will have a choice. If you like h.264 you can install plugin, if you like Flash you will have Flash, and if you like WebM you will have WebM.
> All of the arguments for this move seem to be focused on the long term. That's fine but in the short term it will unarguably cause users and sites headaches.
Ah, sorry, I see you actually understand that it's not overnight change that they play in here. Sorry again your opinions above were worded (or understood by me) like you didn't understand that.
> That's fine but in the short term it will unarguably cause users and sites headaches.
That's true, but we are already in times of transition from Flash to html5 video, so that's the best time to make strategic moves like that.
> At best, the author's argument descends to "two wrongs make a right".
> Note: I'm saying arguing in favour of Flash. In fact, I consider the lack of Flash on my iDevices to be a feature rather than a limitation.
I don't really understand what you are trying to imply here.
> Ironically this moves will likely prolong Flash and slow the adoption of HTML5 as a result.
As I stated many times above I don't think you're right about that. In fact I think opposite - keeping h.264 is prolonging flash and slowing adoption of HTML5.
I'm actually curious about the differences in the formats. Is H.264 a better format? If so, does that mean that the web will always choose "free" over quality, if so, is there any incentive to create better embedded technologies, if a "free" albeit technically worse "knockoff" is available regardless of how open the other tech is, simply because it wants to be compensated when used by commercial entities that plan to profit off their work. For example, if they had non-commercial, GPLv2 and commercial licensing options.
The main problem with WebM/VP8 vs. H.264, especially in the face of the mobile internet device explosion, is hardware acceleration.
Once devices start coming with native WebM acceleration, it won't be an issue. Given that Android is so popular and Google is looking to abandon H.264, it's inevitable that hardware acceleration will come to phones, probably in conjunction with H.264 acceleration (just like H.264 and H.263 right now) At that point, any ARM platform with a H.264 acceleration will include a WebM acceleration, and it would be more than trivial for Apple/Microsoft/whoever to implement WebM in their mobile browsers.
A more interesting day will be when Google says "Android 3.x phones must have WebM acceleration"
Quite simply, what most people are missing here is that Chrome is removing H.264. How does removing a capability of a browser enhance its capabilities?
Its nice that they add WebM, but there is just no practical reason for removing H.264.
What about video support for existing Android devices? AFAIK WebM is only available for Gingerbread, which means the large majority of Android devices would have to fall back on Flash for Android. And that's not fully-baked yet.
I can't see why this won't be turned into a lawsuit w.r.t. intentional degradation of performance/battery life.
I like his point that the core of the debate should really be about choice. But then he lost me when he characterized the MPEG-LA as a ruthless cartel.
>I also find it puzzling that Google is being accused of giving users fewer choices, while Microsoft and Apple aren't even mentioned. They refuse to support WebM, after all.
Err, Microsoft has already declared that WebM will be supported if a compatible plugin codec is installed on the machine. They just don't want patent trolls (successfully) suing them for shipping hundreds of WebM decoders. After all, Google is not indemnifying users of WebM from patents(like Android OEMs like HTC were left on their own when Apple decided to sued) like Microsoft does with Windows Phone 7.
Opera is being disingenuous by spinning this as if Microsoft blocks WebM from being used in IE9 for the HTML5 video tag.
Worth pointing out? Sure, but let’s not forget that what MPEG-LA actually does is license to you all the patents which H.264 is known to use — so you’re probably not infringing anything, barring of course the insanity the USPTO perpetuates… If you have a patent for part of the H.264 process, chances are, you’re part of the MPEG-LA and getting royalties through that organization already, legitimately, without suing anyone.
Very true. But by shipping WebM, MS would be vulnerable not to the patent holders coming out of the blue on H.264, but also ALL the mpeg-la companies AND patent holders coming out of the blue. It would greatly increase their risk.
I think they have reached a good compromise by developing support for IE9 to pickup WebM codecs installed by the user and playing HTML5 video through it.
The WebM patent grant contains insurance against this. If any "new" patent holder sues anyone or makes available their patents for suing by other party, he will be excluded from the (VP8) patent grant.
Any CE or IT company will think twice, whether it is worth it. Can you imagine Samsung or LG suing someone over VP8 and in return losing access to VP8 content on Youtube? What it will do to their CE business?
Chrome is 100% compliant without extraneous h264 support. The HTML5 spec contains no requirement for h264. If you want to blame anyone then blame the W3C working group for not specifying a codec.
As of now h264 is on the same level as ActiveX and VBScript so you might as well ask for Chrome to support those, too.
Granted, in this respect WebM is not perfect either. But at least WebM is meets the criteria to be a part of the W3C spec without modification whereas currently h264 does not.
tl;dr Don't complain if Chrome uses WebM for <video>. My browser will only support Dirac and we're both right.
If Google is truly whole-heartedly after the openness of web video, they should go ahead and disable H.264 playback in the bundled flash plugin in Chrome. It's technically just a simple wrap around the stock flash plugin. Given their cozy relationship with Adobe, they might even get a special binary from adobe, cut down the download size of Chrome and save bandwidth cost (which I believe is a greater saving than the $6.5 million)!
This statement "Indeed, most sites offer different bandwidth options and video sizes. They are already converting the video!" shows a pretty clear lack of understanding on how most site's encoding processes work (you generally encode once at different bitrates, not once at one and others as you need them)