That's the "Good News". Now for the rest of the story:
The open source part of this is nearly useless, if not completely so, as evidenced by the fact that Firefox won't be using the source code. The "you don't have to pay the MPEG-LA" part only applies to the binary module. If you want to pick up this code and ship it in your own software, you'll still need to pay the MPEG-LA.
The reason they are doing this is to put more weight behind H264 in the political battle in the IETF over the MTI video codec for WebRTC. But if they succeed in making H264 the MTI, and you want to write a mobile app that interops with WebRTC for doing some form of realtime video, you'll won't be able to use their source code without paying the MPEG-LA. You'd have to use their binary module, downloaded from their servers, which, as they mention in the Q&A, is impossible on iOS.
The announcement seems to try hard to smudge this distinction and push it into the fine print, but there's still a patent "elephant in the room".
TL;DR: This doesn't solve the patent issues surrounding h264, and doesn't make it anymore suitable as an MTI for WebRTC.
I sure hope he's wrong. Personally, I think a patent-encumbered MTI codec for WebRTC would be a very bad, especially for the open source community:
- You can't have a spec-compliant implementation of WebRTC by compiling and running Firefox yourself. You need to download extra binaries from Cisco.
- You can't have a spec-compliant implementation of WebRTC in your Linux distro, without including binaries from Cisco.
- You can't write an Android app that uses the library from webrtc.org to interop with WebRTC in the browsers without downloading binaries from Cisco (unless you pay the MPEG-LA).
- You can't write an iOS app to interop with WebRTC in the browsers, at all, because you can't download binaries from Cisco (unless you pay the MPEG-LA).
- You can't build open source projects that fully interop with WebRTC, without dancing around all the lingering patent issues.
In all these situations, having h264 as the MTI is worse than having no MTI at all.
because the phone browser is "sold" to you. When you buy a phone, even if you are going to wipe out the OS and install something else, you already paid hundreds of dollars on licensing. Heck microsoft quarter only had a profit because of license fees on android.
It is the microsoft taxes on PC all over again. Only this time MPEGLA learned the lesson from MP3 and got their licensing claws sharpened.
Phones (and virtually any other electronic product) contain dozens of licensed technologies including ARM, Wi-Fi, 3G/4G, etc. Do you object to those as well, or just codecs?
One step at a time. Fight for open codecs today, and maybe 50 years from now we'll reach a 100% open stack, from hardware to software and wireless protocols, that provides a free baseline available for implementation by any company or individual without royalties.
where i came from it is forbidden to sell one product and force you on another. Like you can't buy a car and be forced to only use gas from one brand. Likewise i still feel it is wrong to sell a hardware and force you on a certain software.
only company that mentioned the royalties they pay microsoft was HTC and they are paying $5. and HTC is a very close partner to microsoft. others probably pay more.
And microsoft licenses are only bulling, it is not even useful. So i'm guessing it would get close to $100 per device.
Yes this sucks, it's obviously MPEGLA's (of which Cisco is a member as a h264 patent holder) move to prevent WebRTC from standardizing around VP8/VP9 (which is already supported in Firefox and Chrome), so instead we are to rely on a binary blob from Cisco for royalty free WebRTC (Flash all over again).
The big stink is how Firefox is supporting this, it's like a huge betrayal of the principles of an open web which is what I directly associate Mozilla with.
As a long time Firefox user and promoter I feel betrayed.
H.264 won the HTML5 video battle, as noted at http://brendaneich.com/2012/03/video-mobile-and-the-open-web.... If anyone betrayed someone then, it was Google for not doing as they explicitly blogged they would by removing H.264 support from HTML5 video in Chrome. (But I understand why they didn't; they're realists.)
For WebRTC where there is no extant/legacy content reason for us (not speaking for Cisco) to require H.264, we prefer VP8 over baseline H.264, but do not at this point want to rule out either. And on mobile devices, especially at the low end, the h/w codec advantage for H.264 is material.
Even next-year-announced chipsets with VP9 support tend to have only h/w VP9 decoding and at best s/w encoding (perhaps on an extra ARM core!).
Your fancy camera with video short-take capabality has boiled H.264 encoding as well as decoding into even low-end SoCs. How much this means for battery life, we are still digging into, but it's not trivial for long WebRTC calls.
Instead of dramatic talk about betrayal, where you seem to expect Mozilla to fall on the nearest sword stood up and aimed at our gut (probably by a competitor), and die a glorious but pointless death, think about the long run. H.264's price ceiling is now $0.
This matters for future codecs. Between our work on Daala, and downloadable codecs such as OTOY's ORBX.js, there is a better and unrestricted future to invent. Join us, if you can be realistic about H.264 h/w advantages.
You already knew about how much more/better support h264 had long before you embarked on what now comes across as nothing but a charade as you turn coat ONE WEEK before the WebRTC future is being voted on, you KNEW this so what has changed?
Oh, what has changed is that now you, Mozilla, can use h264 royalty free, that is what has changed.
So suddenly open source royalty free standards aren't that important anymore. I threw up a little in my mouth when I read -'we lost the fight' from Monty, you didn't fight!
Instead you switched sides one week before the vote because MPEGLA threw you a bone.
And if all it boils down to in the end is 'hardware advantages' then you can just drop the pretense of Dalaa right now, it will NEVER be anything but much less supported than the latest offering from the MPEGLA cartel, so from that very perspective it's nothing but vaporware.
MPEGLA was terrified of WebRTC and HTML5 standardising under a truly royalty free open source codec which could be used anywhere by anyone, so they gave you the 'flash'-style binary plugin for 'free' and you swallowed it, hook, line and sinker.
This was the chance to break the royalty-laden video technology monopoly of MPEGLA by getting a truly free codec standarised, and despite you having made a show of 'carrying the torch' for royalty free open source web standards you sold out one week before showdown when Cisco called with an offer.
First, MTI votes in IETF are tricky to predict, but here is a safe bet: VPx was never going to win sole MTI. Not ever.
Second, if we had not been fighting -- and holding to only WebM for HTML5 video until last year -- while our competition was shipping H.264 for HTML video, you might be able to say that we didn't fight. If we had not tried to make s/w VP8 perform on lower-end mobile phones ahead of others including Google, you might make that charge.
But we did those things and failed. We learned from those negative results. What have you done? What have you learned? Where is your skin in the game?
Third, MPEG LA has not thrown us a bone. Cisco != MPEG LA. Taking H.264 to zero price is a net public good and a prerequisite for getting RF licensing of part or all of H.264 for all desktop systems (since rents there, as opposed to on mobile devices, are running low).
When we do that in the next year (or sooner) based on taking the price to zero, and gain free as in speech licensing, will you thank us? Not likely.
Fourth, MPEG LA was not terrified of HTML5 standardizing on a truly RF codec, because HTML5 was never going to do any such thing. Now you're just confabulating. Again, read
As for "they got you cheap", if I were about money, I would have gone to Google ages ago. If Mozilla were about money we would have sold out in any number of ways.
This is not about money, it is about interoperation and zero-price ceiling for H.264 now, and RF licensing for desktop next -- and after that, better codecs that are defensibly unencumbered and/or downloadable in JS and WebGL2 or better (probably both).
None of this is easy to pull off. Rejecting interoperation is a sure way to die fast for no good end. Shouting about betrayal on HN is cheap and easy by comparison. Try doing something productive for a change.
> Taking H.264 to zero price is a net public good and a prerequisite for getting RF licensing of part or all of H.264 for all desktop systems (since rents there, as opposed to on mobile devices, are running low).
More realistically, this just lets them have an escape valve for the one area that was likely to rock the boat, while not impacting their revenue at all (likely increasing it in fact).
It's a standard cartel move, which they already used by charging TV networks, and pay TV on the web, but carving out exceptions for video porn ("any paid video under 12 minutes") and the web. How exactly this gets sold as "non-discriminatory" I don't know, but then I don't understand how moving a file across a network can trigger payments for patents on the encoder used to produce it either.
It's a tricky subject, but I don't think allowing monopolies to price discriminate can be described as a "net public good" in the same that say, not allowing monopolies could be.
I understand the compromise, I'd prefer it if Mozilla fully understood it too.
edit: I just realised that by "a prerequisite for getting RF licensing of part or all of H.264" you're probably referring to the ongoing effort (started before H.264 was even begun) to get H.264 Baseline under proper RF terms, rather than "getting the blob for free" which is how I first took it. It would certainly be nice, but it seems to have failed repeatedly over the years.
We at Mozilla understand things like divide-and-conquer to achieve a uniformly public good just fine, thanks. Do you really insist on all or nothing at a given instant? That is not how Firefox took on IE and took back the web, restarting competition and standardization.
Sorry, we aren't able to take on the patent system in full.
Note that US "health care" cartels practice legal price discrimination, they are exempt from Robinson-Patman. Still, piecewise reform can make a net public good.
On RF for some or all profiles, see my point about desktop rents. Time passes. Just because something did not work in the past does not mean it won't in changed future circumstances.
>Third, MPEG LA has not thrown us a bone. Cisco != MPEG LA.
Oh please, Cisco is part of MPEG LA and you'd have to be incredibly naive to believe that this was Cisco striking it out on their own to offer a 'solution'. This is MPEG LA's offering, brought to you by one of it's members.
And likewise it doesn't take a genious to realize that you switching sides one week before the vote came as a result of discussion with Cisco, to offer broader support for h264 as the WebRTC standard.
So yes, I say you sold out.
>Fourth, MPEG LA was not terrified of HTML5 standardizing on a truly RF codec, because HTML5 was never going to do any such thing.
Oh I'm sure this royalty free h264 binary blob offering from MPEG LA was due to the kindness of their hearts.
Of course they were terrified, because even if this was just for WebRTC and not HTML5, it would have set a precedent for a fully open source and royalty free codec, with all the benefits that come along with it, which in turn would increase demands for fully open web video solutions in all areas.
Also you totally avoided the question I posed regarding your 'hardware support' argument, and where that leaves Dalaa as anything more than a toy project.
I held you guys to much too high standards it seems (much higher than any others in the web industry), I was obviously wrong.
> Oh I'm sure this royalty free h264 binary blob offering from MPEG LA was due to the kindness of their hearts.
That's not from MPEG LA to us. That is from Cisco to everyone who wants to use a blog, and it's permitted by the licensing, just the same as Flash today can be downloaded from Adobe as a binary blob and neither I (as a user) nor Mozilla needs to pay MPEG LA.
I still see lots of anger, as well as confusion. Anger leads to the dark side.
A hopeful sign, kind of: you started with "betrayal" (Harold Pinter play!) and now you are faulting Mozilla for being confused, or for not reforming All The Things instantly. A bit of a climb-down -- just sayin'.
Please note that we don't like any of the bad patent-pooling, rent-seeking behavior either. Failing to overcome it all at once, finding an incremental path to what we believe will be a better future, not throwing ourselves on all the swords, is part of how Mozilla operates. If you want purity, there are prefs you can set and add-ons you can install in Firefox. If that's not pure enough because you have to set prefs or use add-ons, there are tiny share browsers you can use instead.
I'm not saying "there's the door", rather I'm explicitly reaffirming that Mozilla does not consider every bad reality imposed on competitive browsers to be a make-or-break principle test (Monty made it sound like that; Mitchell and I do not agree), which we can pass only by rejecting reality and therefore very likely shrinking to tiny market share.
You wrote "MPEGLA was terrified of WebRTC and HTML5 standardising under a truly royalty free ...". Note the conjunction, also the past tense ("was"). When I called you on being wrong (HTML was never going to standardize on VP8/WebM), you changed your argument. Are you implying that WebRTC making VP9 (not 8) MTI would in the future affect HTML? If so, dream on. If not, you shifted your argument, and plonk.
BTW I answered your Daala vs. hardware question. Read more carefully. Getting into hardware as second codec is hard for any codec, even with a big sugar daddy (Google). Leapfrog via the GPU is the better way.
Is it possible to have VP8 as a mandatory baseline on platforms that support it, so at least all desktop users could rely on having VP8 support in WebRTC, even if Firefox still has to support H.264 for WebRTC calls to/from mobile devices?
Yes, that is possible (technically), but again, in the view of people on the scene whom I trust, VP8 was never -- meaning extremely unlokely -- going to win MTI. Likely outcomes: no MTI or H.264 MTI.
No MTI would let peers negotiate, and VP8 does win against baseline h.264 on quality. Then the question becomes: will all the bigs support it? We do, and will.
It's also just a software implementation AFAICT. This does nothing for people wanting to ship open source drivers for all the various hardware codecs (some of which have open source implementations already) on device SoCs. It doesn't even allow shipping the identical codec on platforms that Cisco didn't build for (e.g. no OpenBSD or uclibc for you!).
Basically this sucks. Opposition to H.264 was being driven more or less exclusively by open source browsers, and Cisco crafted a compromise that was (just barely) acceptable to the people leading the fight, and did nothing for anyone else.
By the way, someone else commented further down that Apple doesn't allow third party apps to use it for realtime (video chat). But I can't verify if that's true or not.
Apple doesn't facilitate realtime use through AVFoundation, but there are workarounds. Apple doesn't specifically restrict realtime use and does approve apps using the workarounds.
But surely h.264 is provided by Apple for iOS/OS X? I'm not familiar with either platform (as a developer) -- but with Apple's investment in h.264 on iTunes and via Quicktime -- I would've thought this was one of the benefits of the walled garden? Please enlighten me if I'm wrong.
Which is exactly why I don't understand why Mozilla would support this, instead of backing VP8? They just end up making MPEG-LA stronger, which is bad news for Daala, too, for whenever it will arrive. For Daala to succeed, MPEG-LA better not have a 99 percent monopoly by then.
> and you want to write a mobile app that interops with WebRTC for doing some form of realtime video, you'll won't be able to use their source code without paying the MPEG-LA
You won’t be using software implementation in a mobile app. Hardware decoding is the way to go, if you don’t want to drain the battery.
I __really__ __really__ don't get the mozilla stance here. It just doesn't make any sense to me.
Mozilla has been resisting Googles libre codecs even though they come with full source code and a patent pledge. Google has already even paid to eliminate potential threat from the evil MPEG LA. It is as free(libre) as you can get in this space.
On the other hand, the Cisco plugin is no solution at all. A binary module that has to be downloaded by each user? How can Mozilla justify recommending/requiring a binary module whose source it can not view/audit/share? This approach wouldn't be permitted under Debian Free Software Guidelines, thus ensuring that WebRTC-Firefox won't work on debian and its derivatives.
Cisco benefits from H.264 winning the standards battle. They also have patents in the MPEG LA pool. Apple, MS and Cisco - none of them are under any obligations to provide a libre implementation of WebRTC. Only Google and Mozilla have that responsibility. And they can make it happen today by just agreeing to go with VP8 and VP9 when it lands (both are covered by the patent pledge as well as under the MPEG LA agreement).
H.264 is a defacto standard already, I understand. But google, with its control of youtube and Android, can make a serious dent in that. If Moz and Google ensure that VP8 becomes the de-jure WebRTC standard, a Free software implementation of that can be released by mozilla today. No need to wait for Dwolla to come to fruition.
I'd really like to understand what I am missing here.
AFAICT, we (Mozilla) are trying to solve TWO problems:
1. We need a video codec that everybody agrees on for WebRTC.
2. We need a way to play H.264 on Windows XP and other operating systems that don't provide native H.264 playback, for compatibility with almost all HTML5 <video> content on the web.
If it weren't for problem #2, then I would agree with you more. But, really what Mozilla seems to have said is "Hey, if you provide a free H.264 decoder without field-of-use restrictions, then we'll compromise on WebRTC so we can make sure everybody on every platform can play all the HTML5 video content available on the web."
I don't have an opinion on VP9. But, there's no VP9 content on the web now. There's tons of H.264 content on the web. Mozilla got burned waiting for other players to help with WebM adoption before. Waiting for VP9 would probably just end up with us getting burned again.
FWIW, I work at Mozilla but not on this stuff, and I learned all I know on this topic from Brendan Eich's blog post.
1. Mozilla is the only browser that has no legal way to provide integrated H.264. Every other major browser is backed by a corporation and can afford the MPEG LA fee.
2. While Google probably would prefer VP8/VP9 becoming the WebRTC standard, its not like they can't do H.264. So they have been dropping the ball on pushing people towards WebM and away from H.264.
3. (Speculation) Cisco probably made an exploding offer - "We can enable legal H.264 for all your users and foot the bill for it, but only if you agree to it before the WebRTC meeting".
4. No matter what codec wins at the WebRTC meeting, H.264 content ain't going away anytime soon. Mozilla has to have it either way.
This is an interesting maneuver by the H.264 lobby. It leaves Mozilla very little wriggle room. In hindsight, I have to wonder if a better deal could have been worked out by Mozilla actively seeking a license from MPEG LA for some fixed one-time sum in perpetuity in return for Mozillas' compromise on H.264. Maybe a kickstarter could have been then done to raise the required one-time fee. Who knows - maybe Redhat, Ubuntu etc could have been asked to chip in.
"1. Mozilla is the only browser that has no legal way to provide integrated H.264. Every other major browser is backed by a corporation and can afford the MPEG LA fee."
Mozilla could afford to pay MPEGLA but that doesn't help any of Mozilla's downstream distributions and it doesn't help other developers building open source software that want to include H264 capabilities. (Not to mention that millions of dollars a year in patent fees could be better spent on initiatives like building a better video future with Daala.)
Mozilla's mission is about more than just Firefox, it's about the Web, and solutions that only work for Mozilla distributed products generally aren't great solutions for the long-term health of the Web.
Mozilla could have shelled out the cash to license patents from MPEG-LA and adopted an existing open source H264 implementation. That would certainly have been better sooner for Firefox users, and possibly for <video> on the Web, but that would not have been enough for Mozilla because we are not in this game for our own profit. We're here because the Web needs us on its side, looking out for the interests that BigCos generally won't.
Finally, there is no chance that Mozilla, even with a giant Kickstarter campaign, could buy out the MPEG-LA patents for H.264. Not gonna happen. (Unless I'm missing all the multi-billion dollar Kickstarter success stories.)
At least according to the wikipedia page, it looks like the Mozilla Foundation brings in $300M a year in revenue. I still wouldn't say that $6M a year is trivial for them, but it certainly isn't an impossible bridge to cross. Up until now the Mozilla party line has been that they don't want to pay the patent fees for reasons of principle.
So it looks to me like there was another option: bite the bullet, pay the licensing fee and distribute their own blessed binaries (they still couldn't grant a license to people building from source), then feel free to take whatever position on WebRTC they thought was best.
>Without Sun, HP, Digital and Microsoft on board Linux is dead on arrival.
I think the main reason H.264 is so popular is because of the absolutely fantastic x264 encoder. If anybody delivers something radically better (Daala promises to do) it will gain traction. See Opus. I listen only to podcasts by very technical people, and Opus took them in a storm, even without the MPEG LA.
Don't forget about Firefox OS! Imagine what impact H.264 would do there. Firefox OS and Tizen are the BigBets now, because TelCo's manufacturers don't like to rely on Google for delayed OS updates anymore. That's why these OS have a good chance of becoming as popular as android in a few years. But that's only valid, when Firefox OS and Tizen get their shit together and finally create a robust, independent, secure and most importantly not only beautiful, but usable user interface.
(Firefox does silent upgrades, just so you know. Luckily on Windows only.)
Mozilla has implemented WebM playback, but WebM hasn't gained enough traction to matter.
> But google, with its control of youtube and Android, can make a serious dent in that.
Uninstall Flash and try using a browser without H.264 codec. I have, and it sucks.
YouTube is the only major site that supports WebM, and even there WebM it's a second-class citizen (videos with ads are not allowed to use HTML5 player, and not all videos are transcoded to WebM).
Google dropped the ball here. Android still has better support for H.264 than WebM. YouTube is half-broken with WebM. Chrome broke promise of dropping H.264 — they know that a browser cannot survive without it.
And by the way, it is not possible to use Youtube without Flash Player. Some videos simply are not played with HTML player and Youtube tells you to download Adobe Flash Player :( Hope there will be some new competitor, who will offer video services without third party plugins. Maybe Vimeo?
I haven't had flash installed for years. For videos, I made a key-binding that extracts any URL's in XA_PRIMARY, launches https://github.com/rg3/youtube-dl and then plays the video with mplayer. Looks better (because the vid is full res) and never skips.
Same here. But I continue to endure a WebM only world. I miss out all the vimeo screen casts.. but so what? just means i will have to find another tutorial in text and life moves on.
It is simply a data format that is non-standard and that you have to pay for proprietary decoders. What is new about that? just because google give you that feature if you pay them with your data, does not make it free for everyone. so it is not in place for firefox.
Or should firefox charge a fee for each user? it is crazy, even so when the alternative is already existent and open standard.
what is even crazier is that they demand a payment, for a spec which only "benefit" over the open source code is that they can add DRM on top of it, so they can also charge the end user.
Arguably vimeo could make an effort here too, and do automatic transcoding and delivery to eg: webm and html5. It certainly wouldn't be trivial, but also not impossible.
Has anyone seen any recent news on why Google/youtube doesn't do this btw? The already do transcoding for different quality? And/or if they have any plans for a html5-based viewer that supports ads etc?
Almost nothing supports it. And with Apple dominating in web usage, editing tools and phones/tablets it is hard to see any format surviving without their support. And of course they are fully behind H.265.
if people had no voice youtube would still be showing quicktime or Real video.
I for one rather watch youtube (and uploads my videos there) because vimeo is a pain to watch (have to go get my closed source tablet). while youtube i can just hunt for a non-ad version that will work on html5.
I agree. This is just a move by Cisco to prevent the adoption of free codecs.
But why do you say that Mozilla resists free codecs? They are shipping with Theora, Vorbis, Opus, WebM/VP8 support and are quite active in that area. Meanwhile they were forced to adopt H.264 platform support because all other major browsers including Google Chrome and mobile platforms including Google Android use it and a large amount of Youtube videos are only available through H.264.
Google either lacks the will or capability to make a dent. If they'd ship Android without H.264 support then vendors would simply patch it back in. They said that Chrome would stop supporting H.264 but nothing happened. YouTube still uses H.264. (And Chrome stable still doesn't seem to support Opus.)
> I agree. This is just a move by Cisco to prevent the adoption of free codecs.
Well, yes. From Cisco's point of view, I'm guessing it's just ensuring that it can sell it's video conferencing gear (that users will be able to use them via webrtc etc). Much better for them than having to invest in hardware accelerated webm or whatever. Sad, but true.
>This is just a move by Cisco to prevent the adoption of free codecs.
Perhaps in part, but in addition to motives mentioned by others, Cisco obviously also benefits from increased use of bandwidth. When more people use video, it drives network equipment sales.
Mozilla has been resisting Googles libre codecs even
though they come with full source code and a patent
pledge. Google has already even paid to eliminate
potential threat from the evil MPEG LA. It is as
free(libre) as you can get in this space.
Source? As far as I can tell Firefox implements WebM for <video> and VP8 for WebRTC. In what way is Firefox resisting Google's libre codecs?
The whole idea of Mozilla and Google pushing vp8 (and later vp9) as the WebRTC standard was so that we would FINALLY have royalty free fully open source implementations which could be implemented/ported everywhere with no cost.
Atleast that's what I thought, but with this move Mozilla has shown that the 'royalty free open webstandards' which they touted as their goal was in reality 'as long as it's royalty free for _us_ to ship', as they are now switching sides one week before the voting and suddenly backs h264, which will only be royalty free if you accept a binary blob from Cisco.
I am truly disheartened by this move, and I can only assume that the hiring of Monty to work on Dalaa was just a calculated way of trying to mitigate the criticism by saying: 'look, we still believe in an open royalty free codec, sometime in the far future', which is weak as it's not as if Dalaa is even poised to compete with HEVC and VP9, but against whatever comes next.
And that is assuming that Dalaa will actually end up competitive at all, and if so, also having been able to avoid treading on the sadly insanely broad software patents that litter the video encoding field.
I think it's a huge betrayal of the principles they (Mozilla) have claimed to uphold, and the result is likely that we will end up with a binary blob for WebRTC standardisation come the vote, I'm so very disappointed.
The deal makes it free (as in beer) for everybody.
Mozilla could afford licensing H.264 for Firefox long time ago, but they've been fighting for license that allows anybody to build fully-functional Firefox fork (unlike Google — they bought H.264 for closed-source Chrome, but left FOSS Chromium without H.264 playback).
Willingness to use it doesn't affect how free (as in beer) it is. It does affect how free (as in speech) it is, but that's not what the grandparent was arguing, and there's a huge difference between the two.
Actually, assuming that MPEG-LA allows this Cisco scheme to happen then any corporation who's at the MPEG-LA yearly cap could offer this same scheme for free (and no cost to themselves) too e.g. possibly Google, Microsoft, Apple.
>I'd really like to understand what I am missing here.
You only need to look at what happened with <video> and it should be very clear just how much Mozilla can realistically rely on Google to defend VP8. Or how willing they (=Google) are to make a "dent in it" using YouTube and Android. The answer is: zero.
Firefox will continue supporting VP8 for WebRTC. But Mozilla won't block the standard on it not being MTI.
Mozilla didn't have a choice. VP9/WebM is not happening. The primary reason is almost all inter frame content is acquired or transmitted as H.264. Mobile phones, prosumer cameras, network based encoding appliances, PVR's, cable/satellite tv. No one wants to re-encode. Plus there is a lot of baked in hardware support for H.264 encoding/decoding.
Exactly. Does anyone know if there are any cheap solutions to capture in vp9 on devices such as cell phones?
I'm guessing this is Cisco's motive as well -- they want to sell video conferencing and ip video/voice-chat stuff -- and that'll have to work with cellphones and tablets. As long as almost all devices (including PCs via video hardware) have hw support for h.264 -- and no support for anything else -- we'll be stuck on h.264 for "cross platform" video.
H.264 already won over VP8. The battlefield now is now is going to be on the next generation of codecs (or even two ahead), and Mozilla puts their forces behind Daala.
> Mozilla has been resisting Googles libre codecs even though they come with full source code and a patent pledge. Google has already even paid to eliminate potential threat from the evil MPEG LA. It is as free(libre) as you can get in this space.
But Firefox supports WebM. I don't speak for Mozilla, of course, but I totally think you should use WebM over H.264. :)
Look, H.264 is the standard for online video. All Macs and Windows PCs can play it, the content industry is already tooled to provide it, and it's tough to beat on the compression front.
The fosstards who object to patent issues are a minority of a minority. Man up, pay your license fee, and comply with the fucking standard.
I don't know the exact plan since I'm not working on this, but it would be relatively easy for us to do:
1. Insist that the exact build configurations used by Cisco be open-sourced along with the rest of the code.
2. Require that every binary distributed by Cisco by tagged with the revision control revision ID.
3. Internally at Mozilla, build that revision of the code and compare the result to the binary blob that we would download from Cisco. Note we'd never distribute the outputs of our internal builds; we'd use those builds only to verify that the source code matches what we'd download.
4a: When we verify that the outputs match exactly, update some embedded hashes within Firefox to approve those versions of the binary blob for download/install, or
4b: Cisco could ask Mozilla to sign these blobs for them, and Mozilla would sign the blobs after doing the above checks. Then, the Firefox client would just verify that the blobs were signed by Mozilla's public key.
Actually, on second thoughts - yes, you are right. This could work - partially. But the other way around. Mozilla could build the blobs, sign them and then send them to Cisco who would then provide the download infrastructure.
It still won't allow a third party to verify the same and would require everyone to trust Mozilla itself. Its less problematic than having to trust Cisco, but far from ideal.
On that note: do you know if the blob download would be wrapped in a Cisco EULA?
From a person involved with this at Cisco:
"All the build scripts etc that Cisco uses will be part of the open source project so that anyone can build it them selves and check that their build matches the Cisco binary and check the code does not have backdoors to send all your video to the NSA."
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09293...
They can't "supply". Cisco has the patent license with MPEG LA, not Mozilla. As per the announcement, each firefox user will have to download the blob directly from Cisco.
The main thing that you are missing is the practical downsides are very limited and that AVC/H.264 has won the war for the current generation of codecs (and did so many years again when it was baked into the silicon of the popular smartphones when iPhone and Android first launched (and it was used for Blu-ray, digital TV (in much of the world) and for many other non computer based systems. VP8 cannot be added to those devices. Practically every device supports AVC and new devices will continue to do so anyway for compatibility with existing systems and services so inclusion of VP8 would always be additional on the VAST majority of devices.
> Mozilla has been resisting Googles libre codecs even though they come with full source code and a patent pledge. Google has already even paid to eliminate potential threat from the evil MPEG LA. It is as free(libre) as you can get in this space.
Probably true although Nokia wasn't in the MPEG-LA VP8 pool and was bringing legal action. Not sure where this went but it might still be "as free(libre) as you can get in this space" without reverting to MPEG1 on which the patents should be expired by now.
> On the other hand, the Cisco plugin is no solution at all. A binary module that has to be downloaded by each user? How can Mozilla justify recommending/requiring a binary module whose source it can not view/audit/share? This approach wouldn't be permitted under Debian Free Software Guidelines, thus ensuring that WebRTC-Firefox won't work on debian and its derivatives.
As others have said it is auditable and open source. Debian could offer an option to download or not include it either leaving nothing or offering an non patent licensed FFMPEG decoder or the Cisco one without license or others.
Actually source distribution is probably not patent infringement and neither is personal use so for many people they could freely build from source themselves. Businesses may need to use the Cisco binary or otherwise procure a license.
Practically there is no barrier even if there is an ideological one. I don't expect Stallman to use the Cisco binary although few of us adhere as consistently to the free software lifestyle (and even he makes practical compromises sometimes).
> Cisco benefits from H.264 winning the standards battle. They also have patents in the MPEG LA pool. Apple, MS and Cisco - none of them are under any obligations to provide a libre implementation of WebRTC. Only Google and Mozilla have that responsibility. And they can make it happen today by just agreeing to go with VP8 and VP9 when it lands (both are covered by the patent pledge as well as under the MPEG LA agreement).
Cisco mainly win by being able to sell gear that is compatible everywhere without needing to bake in two codecs and have transcoding gear everywhere for when a Firefox/Chrome wants to talk to a phone user.
> H.264 is a defacto standard already, I understand. But google, with its control of youtube and Android, can make a serious dent in that. If Moz and Google ensure that VP8 becomes the de-jure WebRTC standard, a Free software implementation of that can be released by mozilla today. No need to wait for Dwolla to come to fruition.
It is an international standard too. Google could have made a dent in it a couple of years ago at the cost of some real fraction of Youtube traffic and revenue but it didn't. Moz and Google cannot ensure VP8 becomes the de-jure WebRTC standard because of the existing mobile hardware. [I haven't been following Dwolla so no comment on that].
> I'd really like to understand what I am missing here.
You are missing that AVC won the battle for the generation of video codecs we are currently using at sometime around 2005. (The competition at the time was VC-1, Xiph's video codecs were nowhere near at the time).
You are missing the practical benefits of ubiquity and especially mobile the benefits of hardware support.
I hope Monty is right and that Daala is going to be sufficiently better than HEVC in time to be relevant for the next generation and that it is free of patents. If that doesn't happen we will need to wait for about 2015[1] for a truly free and Free video ubiquitous video codec and that will be AVC when all the patents have expired.
[1] Estimate, I haven't checked the expiry dates, all should have been filed well before then but the grant dates are also critical.
If you live in a country which doesn't allow patents for software, this is great news. I wonder why no one cares about it in this thread. Foreign laws is how we got DeCSS, VLC and Handbrake to name a few.
Mozilla could simply ship different packages for different countries, based on their patent laws. For example, US version could use binaries distributed by Cisco, while EU binaries could be built from source code maintained by Mozilla. IANAL but I think it would be completely legal as long as the company which distributes the EU version is a subsidiary or a separate legal entity located in EU.
You are free to use whichever package you wish. Of course it would be illegal if you live in a country that has software patent laws. But legality never stopped us from using VLC or Handbrake. Why should it now?
Mozilla already supports (in code, not principle) H.264 by leveraging non-Mozilla code. It's not usually a problem on Windows on Mac since the user has already paid for a license when they bought the OS, but on Linux (gstreamer) it can cause patent violations within US.
I hope (an believe) Mozilla will keep that functionality to use one of multiple backends (Windows's fedia framework, gstreamer etc.) when it adds this Cisco binary.
We will need WMF at least until OpenH264 does High Profile, and I believe we are not going to be able to use only the OpenH264 binary blobs. Therefore we'll support other back ends (but not necessarily all possible back ends).
Well, they may publish on their site whatever they want, but if they won't be able to get local authorities' support for their claim, then this is just bluffing. You know, people may get scared and buy a license even if they don't have to, or if they plan to sell derived software products in patent-protected markets like USA. The most convenient way (in multiple aspects) to do so would be to talk with some European subsidiary. The H.265 patents also cover hardware implementations which probably aren't so patent-free, even in Europe.
Cisco already promised to permissively open source this implementation (though not the binary fees-paid bit), because people were complaining they'd need to pay for an H.264 implementation (as well as patent fees) in non-GPL projects (GPL would allow you to use x264), which was another good reason to not vote for this codec to be MTI in WebRTC.
Which Cisco was pushing for as it makes it easier to inter-operate with all their existing video-conferencing gear.
Also, it costs them nothing since the H.264 licences are designed to not annoy the big players too much, because they could shift the market if they wanted too, and so cap out at about $6 million a year which I assume Cisco already pays.
I'm not a video codec enthusiast, but it seems natural to me that low latency/real-time constraints on the encoding process is going to mean you're not benefiting from H264s full potential anyway. High profile H264 encodes are incredibly slow, and there must be other codecs that fill the streaming niche.
This may benefit hardware and corporate conferencing gear manufacturers (aka Cisco?), but I don't see how the encoder specifically benefits Firefox users.
Well it'll help interoperate with those legacy systems. It seems that VP8's libvpx implementation is likely to be better quality than this solution for a while, since it only supports Constrained Baseline (and even x264 roughly ties with VP8 when limited to that level) and won't even be available for months.
Also, if they get an AAC decoder from somewhere it'll provide H.264 decode of HTML5 video to Firefox users on XP.
I'd still like to see VP8 as the MTI in WebRTC, and I'm somewhat surprised by the timing of this announcement (i.e. nothing seems set to happen for months, so why are they talking about it other than to influence that decision?) but there's definitely pragmatic benefits for Firefox and its users.
Interoperating with legacy systems? What legacy systems? The majority of Firefox users currently don't use WebRTC with H264 streaming at all. This is a very new thing. Maintaining legacy only seems to benefit Cisco.
> if they get an AAC decoder from somewhere it'll provide H.264 decode to Firefox users on XP.
aacdec.c and friends in ffmpeg git seem to be LGPL also...
Although it's called WebRTC, and the billion or so installs of the two existing Web browsers that actually implement it both use only VP8, there's a lot of moneyed interests (like Cisco) that want to be able to inter-operate with legacy systems outside the browser. Video transcoding would really put a crimp in their plans.
And when I said "get an AAC decoder" I mean in the same sense that they get the H.264 encoder/decoder from Cisco, or the AAC and H.264 encoder/decoder from later versions of Windows or Android, with the key feature being not paying any patent fees for it.
I'm especially concerned about point 2. If this could be resolved 1. and 3. wouldn't be any problem (if Cisco decided to close the source code (1.), Mozilla would fork the last open version; if you don't trust Cisco's binaries (3.), build your own).
So I agree: as long as 2. is not resolved, Mozilla should better not accept the offer.
What if a source change is accepted and Cisco does not want to release binaries based on that code?
What if the code contains a security issue that is exploitable, but only in remote cases and the maintainers do not want to accept changes to the code for whatever reason?
How many attacks will there be trying to redirect the Cisco DNS in order to let Firefox download a malware-ridden binary?
Will the binaries be available as deterministic builds?
Will the binaries be signed and checked by Firefox? Who has access to those signatures?
How is this a victory over using GStreamer and using the encoders/decoders available on the OS?
This isn't necessary for systems that already have H.264 decoders provided by the OS, but it's useful for platforms like Windows XP (which still accounts for 20-30% of web usage) that don't have built-in H.264 decoders.
Firefox already uses cryptographic signatures to verify other code that it downloads (including updates to Firefox itself); it could do the same for the Cisco H.624 decoder.
Windows XP users already need to download a third-party binary plugin (e.g. Flash) to play H.264 videos in Firefox. Cisco's code has the advantage that it is open source and could be signed and distributed by Mozilla.
Correcting myself: it looks like Mozilla can't distribute the binary itself (while still benefiting from Cisco's end user licensing), though it could still publish its own signature for verification.
> What if the code contains a security issue that is exploitable, but only in remote cases and the maintainers do not want to accept changes to the code for whatever reason?
Surely, Mozilla will release an update which disables the plugin under these circumstances.
> How many attacks will there be trying to redirect the Cisco DNS in order to let Firefox download a malware-ridden binary?
Are there currently attacks trying to subvert Firefox's self-update mechanism? Or Chrome's for that matter? My understanding is that Firefox will be checking hashes or signatures for the download.
> How is this a victory over using GStreamer and using the encoders/decoders available on the OS?
As stated in the blog post, not all OS's have support for H.264, in particular Windows XP. It sounds like Firefox already supports H.264 video when the OS provides the codec. It's not clear to me whether Mozilla will move to OpenH264 across all platforms supported by Firefox, or only when there's no codec provided by the OS.
> How is this a victory over using GStreamer and using the encoders/decoders available on the OS?
MPEG-LA-licensed GStreamer codecs cost 28 euros to the end user. This priced at zero towards the end users.
This is not a particular win over decoders available on the OS when those are indeed available.
As for encoders, this encoder is designed for real-time use and even when encoders are provided by the OS, the OS might not provide an encoder suitable for real-time use.
Cisco owns WebEx. Along with Microsoft (Skype), and Nokia, they are fighting WebM in WebRTC as a mandatory to implement codec, so I am deeply skeptical of this move.
This seems basically about preserving investments in WebEx and Skype IMHO.
I also feel a tinge of Mozilla trying to kill WebM/VP8 to favor their own vaporware codec. Are we being told, forget VP8, use H264 for now until Daala?
Ok, I take it back, vaporware is a little harsh. But in order for Daala to win, it will not only have to beat H.264, but also H.265 and significantly. Otherwise, the argument of the powers that be is that H.264/265 are the established standard, widely deployed, low-power hardware implementations, and here is this spec, which doesn't meaningful improve on quality, bandwidth, or battery life, but is license free.
In other words, Daala will have to hit a homerun out of the park to convince all of the major players to endorse it over their existing deployed infrastructure.
If they do, I will be the first one cheering in the streets. But I'm skeptical, hence again, like with WebP, we see Mozilla opposing something that offers immediate offers benefits now in favor of something that in a few years might be.
This Cisco blob, what if it significantly underperforms x264 in encoding quality and CPU. Would we then be stuck with crappy WebRTC video quality because you can't drop in better implementations?
That's for JPEG, I had a long discussion on HN with someone, apparently from Mozilla, over what I meant by this. My social network streams are more and more filled up with multi-megabyte animated GIFs, and WebP is a reasonable replacement for both animated GIFs and transparent PNGs. Today, we have three formats to serve three needs: lossy, you choose jpeg, transparency, you choose PNG, animated, you choose gif. Animated and transparent? Out of luck. Lossy animated? Out of luck. Lossy and transparent? Out of luck.
I don't care so much about replacing JPEG as replacing GIF and PNG. APNG might fit the bill for animated, but given how much information GIF throws away, and given the 2M-5M GIFs I see out there already, it's likely to exacerbate the bandwidth problem, not make it better.
I don't really care if WebP is the replacement, maybe the replacement of mjpeg, or some other format so that people post short 5-6 second clips using <video> instead of <img>. But animated GIFs are chewing up a lot of mobile bandwidth and there is no solution out there right now that mitigates the problem.
> My social network streams are more and more filled up with multi-megabyte animated GIFs, and WebP is a reasonable replacement for both animated GIFs and transparent PNGs.
Well, you could lossy-optimize PNGs if you really want to. Take Google front page logo, for example: not a lot of colors to justify using 32 bpp PNG. Just sacrifice some alpha bits, and you can switch to 256-color indexed PNG. I bet nobody would notice the difference, and the result would be a lot smaller.
Am I misunderstanding something? Cisco is releasing source code to something heavily patent-encumbered, but is doing so under BSD, an open source license with no patent release. What value is the source code then? I can only imagine it's to allow others to verify the correctness of their implementation. You certainly can't use that source code in your own binaries.
It will be just another H.264 decoder and encoder, like in libavcodec and x264 respectively. It's actually pretty exciting since no competing (with x264) open source H.264 encoder ever managed to reach maturity. And it's licensed more liberally than x264's GPL+commercial.
> You certainly can't use that source code in your own binaries.
Obviously you can, but then it's up to you to work it out with the MPEG-LA. Or not, depending on where you live.
Sure you can use it, but you are obliged to license the patents for distribution. MPEG-LA license fees are $0 for the first 100k instances, and $0.20 per instance over 100k units (up to 5 million). Fees drop further for more units.
Interesting parallel to EME. They've taken the paid for codec licences and the DRM out of Flash and built them into two smaller plugins (one binary based on secret DRM code, one binary based on open source code).
I wonder how this stacks up quality wise to x264. I thought it was a bit suspect that a few months back Cisco announced they would release this under a permissive open source licence only after H.264 was accepted as Mandatory To Implement in WebRTC, while also continuing to argue for H.264 vs VP8 using the highly regarded (though GPL/dual-licenced) x264 encoder.
Also, how can this possibly be legit according to the patent license? Or do the patent owners turn a blind eye, like Microsoft in China, and Adobe with student piracy with their eyes on not losing control?
Yeah, but that's like someone paying for an all-you-can-eat buffet and then smuggling in a few bus loads of hungry people. Just because you paid for it doesn't mean it's what the people you bought it from were intending.
They're licensing per user - just that MPEG-LA has a upper bound of what to pay annually (currently $6.5 million). That's something that Cisco can probably better manage than not being able to move forward with their plans.
Question is if MPEG-LA closes that loop hole the next time they revisit licensing payments (but then, how? Microsoft and Apple profit from the same provisions, for example).
The Cisco paid MPEG LA license fees only cover the Cisco delivered binaries. Doesn't sound like this completely free plug-in method would work for say, iOS apps which can't download external binaries. You'd still have to cover the MPEG LA licensing.
According to http://www.openh264.org/faq.html
"In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints. "
I may be wrong, but I don't believe you can access the H.264 stream to send to a remote location, say for a video conference application. I believe the API only allows for saving to a file.
NO! WRONG! tl;dr NO CODE IS BEING RELEASED AS BSD!
nothing is being released as BSD-license! NOTHING! take down this title! it will only harm the public perception of webM and make webM supporters sound as crazy as i am sounding here (i am the exception guys, everyone else is pretty sane)
CISCO is releasing header files and such so that you can compile their still-patent-encumbered binary blobs into a few major platforms. NOTHING even slightly relevant is being given out as BSD-license. Nada. Zero.
This is nothing but harmful propaganda against open standards.
> NO! WRONG! tl;dr NO CODE IS BEING RELEASED AS BSD!
Then please cite a source that backs that up. Bothering to follow the links from the Mozilla post indicates you are dead wrong:
We plan to open-source our H.264 codec, and to provide
it as a binary module that can be downloaded for free
from the Internet. -- [1]
[...] The source code will be open source and distributed
with a BSD lIcense. The binary module is separate and
when the users software downloads it from Cisco, that
is when we are responsible for paying the MPEG LA
royalties. – Nadee Gunasena, Cisco PR [2]
So it's BSD license but you don't get the mpeg-la license if you build it yourself, because it's covered by cisco's capped binary distribution license with mpeg-la.
So "it's open source, but you can't use what you build".
IANAL, but you can use it if you build it yourself, and even up to some small-ish scale (100k users? check with the MPEG LA). Do get your own legal advice.
As someone tweeted at me, BSD is a free/libre license, but it lacks an explicit patent clause, so BSD-licensed code may well not be free as in speech. Hence my use of gratis to describe what Cisco will release, both source and binaries.
> BSD lacks a patent clause, but the vast majority of open source lawyers believe there is an implied patent license, so this is normally not an issue.
1. I'm an open source lawyer. This has been gone over many times at legal conferences, private and public mailing lists, etc.
2. Ask any others :)
Think of it this way: Your argument for giving someone a BSD licensed piece of software and then suing them over patents in it is "Yeah, I explicitly granted them the right to "freely redistribute and use it", but i didn't really mean for them to be able to do so"
At least in the US, roughly every open source lawyer i've met, believes a judge would have no trouble finding an implied license.
The only question is usually one of scope, and one of whether it would include sublicensing.
> Think of it this way: Your argument for giving someone a BSD licensed piece of software and then suing them over patents in it is "Yeah, I explicitly granted them the right to "freely redistribute and use it", but i didn't really mean for them to be able to do so"
Lawyers are a conservative bunch. So I'm sorry, I just don't believe that a lawyer would be so rash as to allow his client to expose himself like this.
But let's get down to brass tacks. Has there been any significant case law supporting this position?
A. We are not all conservative, we are risk managers. That is not the same. In this case, the risk is low.
As for "allow a client", i think you are confused. Lawyers analyze and assess risk and legal implications. We tell this to the client. The client gets the final say, and makes business decisions. If you live in a world where you need a lawyer's permission to "expose yourself like this", i suggest you run :)
B. Yes. A lot, at least in the US (other countries, more questionable). The general principle you are looking for is "legal estoppel". You don't get to promise people they can use something, and then try to stop them legally when they do.
This is true whether it's patents or contracts.
While most deals of the patent cases deal with sales, the case law is fairly clear on this exact point (IE that unless you explicitly disclaim an implied license, you won't get to give something to someone to use and then claim using it violates your patents). It just would be legal estoppel for a different reason other than sale.
you even cite the source but can read the paradox on "open source [...] and provide a binary blob"? Read the response from Firefox to understand. If you are not a coder, than i apologize and provide a car analogy :) they are giving out cars with the engine bay shut, but they are providing 3D files under BSD license so you can print a glove and a shoe to use when driving the car. And the shoes and gloves are so bad, the the mozilla driver said he will just sew his own and use the car for free, which he still has no idea which engine it is using or what fuel it takes.
as i said, no "significant code" will be provided. The code they are open sourcing is HEADER FREAKING FILES for the entry points on the binary blob.
It is the exact same thing as nvidia provides. and nvidia even provides the header files as GPL! so let's all go buy nvidia drivers as they have GPL OPEN SOURCE DRIVERS PROVIDED BY NVIDIA! huray!
FAQ[1] implies this is not the case, and that the source will correspond to the binary. The only thing the binary will bring that the source itself will not is the MPEG LA licensing.
> Q. Why is Cisco making both source and binary versions available?
> A: The source code is available so that an implementation of H.264 is available for the community to use across any project, and to leverage the community to make the codec better for all. We will select licensing terms that allow for this code to be used in commercial products as well as open source projects. In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints. This gives the community the best of all worlds - a team can choose to use the source code, in which case the team is responsible for paying all applicable license fees, or the team can use the binary module distributed by Cisco, in which case Cisco will cover the MPEG LA licensing fees.
Ah ok, so they are pretty much making a bad implementation public so it is easier to sue open source alternatives since now they can't deny seeing the code... nice move.
I think you're confused here. Let me try to explain with an example. Mozilla provides sources and binary blobs both. The latter in no way negates the former.
Cisco will be providing sources and binary blobs both, and the latter in no way negates the former.
Yes, there's "a catch". The catch is, though you get a BSD code license on the source that allows you to redistribute the the source, you do not get a patent license for shipping products based on that source. The only patent protection you can get from Cisco is from their specific binary.
Cisco's isn't the first open source H264 codec and it won't be the last, but it's the only one that comes with patent help and that's what makes it different from the others.
As far as I can tell (given that they haven't actually released anything yet, I can't verify), they will release the source under a BSD style license, which grants you copyright rights to modify and use the source as you like. A BSD style license grants you no patent rights, however. They will furthermore release a binary blob that grants you patent rights, but only if you use that specific binary blob obtained from them and don't redistribute it.
That's as open as you can get with a patent-encumbered codec. I'm not sure what else they could do.
There is no release yet, but Cisco is saying they will be releasing the source code of the full implementation, not just nvidia-style hooks to a binary blob. AFAIK, the plan is for users to be able to replicate the build and see that the binary they got from Cisco indeed corresponds to the source code.
An interesting aspect of this announcement is that it has the potential to cut into x264's bottom line. For several years now the authors have dual licensed the encoder under the GPL and a commercial license[1], meanwhile enjoying an uncontested position among H.264 implementations. I don't expect Cisco's offering to be able to compete on speed or quality of implementation, but the BSD license also means that it may be "good enough" for some potential x264 licensees. I'm curious to see how this plays out.
Meanwhile you can enable native H264 support on linux with the about:config setting "media.gstreamer.enabled". This requires gstreamer with the respective plugin to be installed.
Very sad that software patents are strangling any type of forward progress in this area (webm/webrtc). I almost want to say a mti is impossible to dictate in this arena, and just leave it to the protocol to handshake... if it fails so be it, no video.
Are they saying that WebRTC is going to standardize H.264, or they are saying just that Mozilla will have an easy way to implement it in cases where nothing else is possible?
It would be better if WebRTC standard remained ambiguous about video (like it is now), but in practice H.264 could be implemented by everyone, rather than making any such encumbered codec mandatory. The big failure here is of course not making VP9 mandatory, but it looks like before Daala comes, we won't have a mandatory free codec for the Web.
If H.264 will become a mandatory part of the standard - then it will be pretty bad.
What's the deal with VLC and H.264? Is it along the same lines?
Also I don't really get why you'd stick with the non-free codec if there was a free better alternative. What's so good about H.264, and is it better than the free competition?
This is probably a RTFM question on my part - but how does VLC play back H264? I presume it's part of the x264 library, but is this essentially a reverse-engineered H.264 codec?
The weirder thing is that I have some handbrake encoded videos from ~ 2008 or so that don't play "Error: codec 'h264' not available. Yet other videos with the exact same codec/media information play fine...which is spooky.
They ignore patents and hope it isn't a problem. Not an option for a us-based corporation.
"Q: Does FFmpeg use patented algorithms?
A: We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie. What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions. . ."
http://www.ffmpeg.org/legal.html
Please go look at the members list of the Linux Foundation [1]. And convince yourself that pretty much every single company on this planet uses open source software. It's not some new fad or hippy communist thing. It's serious multi billion dollar business.
The open source part of this is nearly useless, if not completely so, as evidenced by the fact that Firefox won't be using the source code. The "you don't have to pay the MPEG-LA" part only applies to the binary module. If you want to pick up this code and ship it in your own software, you'll still need to pay the MPEG-LA.
The reason they are doing this is to put more weight behind H264 in the political battle in the IETF over the MTI video codec for WebRTC. But if they succeed in making H264 the MTI, and you want to write a mobile app that interops with WebRTC for doing some form of realtime video, you'll won't be able to use their source code without paying the MPEG-LA. You'd have to use their binary module, downloaded from their servers, which, as they mention in the Q&A, is impossible on iOS.
The announcement seems to try hard to smudge this distinction and push it into the fine print, but there's still a patent "elephant in the room".
TL;DR: This doesn't solve the patent issues surrounding h264, and doesn't make it anymore suitable as an MTI for WebRTC.