Cisco to release BSD-licensed H.264 stack
brendaneich.com
brendaneich.com
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.
http://xiphmont.livejournal.com/61927.html
Which goes into some of the details of the fight for a free web.
- 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.
Realistically, don't phones provide already-licensed hardware codecs?
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.
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.
I agree with you that patent encumbered technologies don't have their place in open standards. The current situation sucks.
And microsoft licenses are only bulling, it is not even useful. So i'm guessing it would get close to $100 per device.
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.
/be
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.
They got you cheap.
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
http://brendaneich.com/2012/03/video-mobile-and-the-open-web...
and wake up and smell last year's coffee.
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.
/be
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.
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.
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.
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.
/be
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.
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.
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.
Which would be a bit more of an issue if iOS didn't already ship a h264 encoder and decoder.
Edit: I mean usable by apps other than Apple-owned apps such as Facetime.
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.
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.
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.
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.
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.
Sigh. Big money tends to get its way. :(
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.)
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.
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.
(Firefox does silent upgrades, just so you know. Luckily on Windows only.)
> 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.
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.
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.
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.
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.)
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.
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.
> 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.
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).
No, it only makes it free (as in beer) for those who will (and is supported) use the Cisco binary.
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.
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.
But Firefox supports WebM. I don't speak for Mozilla, of course, but I totally think you should use WebM over H.264. :)
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.
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.
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?
Blobs can be verified against the open source. See https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie.... More on this in a future blog post.
/be
There's ways around the problem.
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?
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.
/be
What country is this? H.264 is patented in every EU country: http://www.mpegla.com/main/programs/avc/Documents/avc-att1.p...
1. You can't guarantee the code will remain open.
2. You still can't build and distribute modified works even with the code you already have, because of patent constraints and licensing.
3. You're using binaries from Cisco which you can't verify (unless they're going for deterministic builds).
We already have mature, high quality, open source implementations of H.264. Why can't Cisco just build and license one of those?
I for one will not be installing the binaries.
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.
This may benefit hardware and corporate conferencing gear manufacturers (aka Cisco?), but I don't see how the encoder specifically benefits Firefox users.
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.
> 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...
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.
This announcement seems to be a tactic move to help with h264 push. "See, even Mozilla folks support it".
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?
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.
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.
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.
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?
> Are we being told, forget VP8, use H264 for now until Daala?
We're told Mozilla can't win battle against H.264, but will be fighting the next battle with Daala.
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?
http://people.mozilla.org/~josh/lossy_compressed_image_study...
https://groups.google.com/forum/#!topic/mozilla.dev.platform...
If you work at Google, please point out errors in our methods or data, give us better metrics, or otherwise correct us.
> This Cisco blog, what if...
"What if?" What if Google fails to get VP9 codecs into h/w? (See my response above; half-way [decoder only] does not count.)
Lots of what-ifs here, but I believe OpenH264 is Cisco's best s/w codec. Let's see, shall we, and not speculate idly.
/be
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.
It's only slightly better than lossy PNG:
It doesn't appear to be good at beating GIF, and loses to APNG in compression (and I suspect also decoding speed):
http://littlesvr.ca/apng/gif_apng_webp1.html
and I find it highly questionable whether a new format that is exactly as expensive as WebM intra frames should be used instead of WebM.
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.
> 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.
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?
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).
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.
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]
[2] Comment on same: http://blogs.cisco.com/collaboration/open-source-h-264-remov...
So "it's open source, but you can't use what you build".
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.
/be
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.
It is in this case, sadly.
I agree that your terminology is probably a better description of what is happening here.
What? Where did you hear such a thing?
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.
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?
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.
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!
> 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.
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.
That's as open as you can get with a patent-encumbered codec. I'm not sure what else they could do.
The project website: http://www.openh264.org/
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.
http://www.zdnet.com/blog/bott/if-vlc-can-ship-a-free-dvd-pl...
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?
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.
"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