In the end I don't blame them too much, though. They seemed to have tried to take an even bigger stance pro-VP8, than Google itself, at least publicly. Google could've made the WebM player the default one for Youtube a long time ago, and only leave the Flash one as fallback, much like Apple took the stance with h.264 and gave up on Flash years ago, and then jumpstart the momentum for VP8. But they never did that. Mozilla alone certainly didn't have the power to turn the whole web towards VP8. I think Google could've done it with Youtube, especially considering all their videos are already encoded in VP8. VP8 is also the chosen codec for WebRTC.
Here's the money quote from none other than Andreas Gal:
"I do believe this war is lost. Just look around. Almost none of the content users want to watch is available in WebM. The only reason desktop is usable is because of Flash, a proprietary plugin, playing video for us (in H.264, mostly). Even Google, supposedly a proponent of open codecs, never fully converted youtube and never dropped H.264 from Chrome. Taking a principled (I would at this point prefer 'stubborn' I think) stance on H.264 won't change reality. It just hurts us and our users.
Firefox got to the point where we are on desktop today by embracing reality. In the early days we started supporting IE-isms like document.all that were god awfully ugly and non-standard. But it was needed for compatibility so we can give people a usable web experience. The web uses H.264. Thats an unpleasant fact, but its a fact. We have to support it whether we like it or not, so we can be around for the next round and continue to influence the web for the better."
So to say that they "gave up" isn't the whole story. Mozilla recognized that this wasn't a hill worth dying upon, and are willing to make sacrifices in order to remain relevant in the pursuit of keeping the web open.
On top of that, Adobe promised support for WebM in Flash and never delivered (so sites couldn't use WebM with a Flash fallback for other browsers), and Google (who made WebM in the first place) promised to drop h.264 in Chrome and never delivered.
That said, Mozilla will continue to have WebM support, and fight for WebM and other open standards in WebRTC (in which it matters even more because that standard includes encoding).
Take a look at http://hacks.mozilla.org/2012/03/video-mobile-and-the-open-w... for an official statement from Mozilla on this.
Besides, is it really the browser's role to dictate the video formats of the web? I would hope they would support everything practical to support and let the sites themselves choose.
And how practical is it to support a for-pay format when you're in the business of giving your product away?
But if they wanted to pay the decoder license fee for every one of Mozilla's 400 million users, Mozilla has annual revenue of more than $100 million, and the most that they would be charged is $6.5 million . However, on Windows and Mac, this is not necessary, so they would only need to pay the $0.20 to $0.10 per for Linux.
Then there was the quality issue. VP8 Sucks. It sucks less now but it is still inferior to x264 encodes.
Then there were the cost benefits of converting to Vp8, no bandwidth saving, more storage cost, and other resources for converting its existing library of video FAR out weight the benefits of using a "not yet proven" patents free video which gives not quality or other improvement.
Dont get me wrong, I am not against Vp8 or Patents Free Video Codec. But i am just being realistic here. It is going to be hard, but at least Opus has proven you can actually create Best of Current Audio Codec and patents free. And Mozilla are already working Daala ( Code Name, and i Hope it remains as a code name only ) aims to have superior performance to h.265.
Instead we're going to be paying to watch H.264 encodes that "suck" compared with the state of the art for the next 10 years just as we're still paying to watch MPEG-2 and listen to mp3 codecs that "suck" compared with the state of the art from 10 years ago.
And you know what? That sucks.
Only it doesn't work that way.
Convince us with a better codec, not with politics first and the codec "later" (and if we're lucky).
The same people that shot it down as a standard web codec have been recycling the same FUD for this debate. The last I recall was Google sending this rather mysterious email the day before the decision was supposed to be taken:
"Google understands that concerns have been raised within the IETF RTCWEB WG in regards to VP8 IPR. We endeavored to properly address these concerns in time for this IETF meeting but did not meet the deadline.
We hereby commit to addressing this by the next IETF meeting in Orlando. Our proposal will address prevalent IPR issues.
Google believes strongly that the VP8 codec is the best technical option for a mandatory to implement codec.
We therefore kindly ask to postpone this decision and hope the workgoup will take this opportunity to make progress on other vital topics."
It's the content, not the hardware support. No content provider cared or will care for VP8 when only Firefox is championing it (which it was).
And it's not like Firefox enjoys a steady market share, so it can afford to insist on principle. They have a lot to do if they don't want to continue the downward slope.
Sorry, i really can't accept this.
Google absolutely had it in their power to move us away from h264. If youtube, chrome, android and firefox were all webM centric, it would become the main codec used on the web for video (to be honest, youtube alone would be capable of doing this). Users (that would be >60% of the web) would blame the content provider if videos did not work, forcing them to adopt webM, in a post-flash world.
Compare this to mozilla, with no online video presence, and standing alone, where users would blame firefox and move to chrome.
I don't really understand google's motivation, but perhaps they were (irrationally?) fearful of losing users to IE/safari.. or the influence of iOS?
They needed H.264 for mobile, just like Firefox OS because Apple had already made that the de-facto standard. They obviously came to the same conclusion as Mozilla, but being corporation rather than a charity they had less reason to be forthcoming about the fact that they'd failed to achieve their aim.
But Google and Mozilla are both key to the future of royalty-free codecs with Opus, VP9, WebRTC etc. particularly via the coming global dominance of Android so I don't really see where the benefit of pointing fingers and finding traitors is, there's plenty of villains on the opposing side if you want someone to be angry at.
Well, I guess Linux also doesn't support H.264 unless you're in a jurisdiction that doesn't allow software patents, or you're willing to be a scofflaw, but there's not much Mozilla can do about that. :(
Personally, I just use x264. Fuck MPEG-LA.
This means that finally you can encode all your videos into just one format for all browsers, desktop and mobile.
Well, one format but probably two bitrates.
I don't believe that OSX or Linux provide it, which is why Firefox does not support it natively. Hopefully this means that they've finally worked out an agreement for licensing, and can support it.
Support H.264/AAC/MP3 video/audio playback on desktop Firefox
On Linux Firefox will use GStreamer, the same backend also used in Firefox OS, its not enabled in the nightly builds since not all distros have the right version of GStreamer and it ca not be loaded dynamically right now (https://bugzilla.mozilla.org/show_bug.cgi?id=794282)
For OS X the plan seams to be to use AV Foundations but no patch has been submitted so far.
In fact, there's this bug for H.264 support:
It was raised in January, and it's status is: "RESOLVED WONTFIX"
The stable Firefox build, as of today(12/19/2012) does not support those codecs.
- support for Linux via GStreamer landed but not built by default. It needs a bit more work.
- support for Windows 7 and above which the OP post is about
- Mac OS X is not yet underway but is planned.
- Hardware H.264 decoding on Android phones via libstagefright. Some phones supported and enabled by default. Some supported but disabled at the moment. Some unsupported.
- Hardware H.264 decoding on Firefox OS/B2G enabled by default, implemented via libstagefright. Phone vendors provide the binary blobs to do the decoding.
For detection sites should use the API "canPlayType" and similar functionality to detect if the browser supports playback.
EDIT: Well, I'll eat my hat. I'm not sure why Firefox needs a different licensing agreement on OSX when they COULD just hook into quicktime without any licensing fees at all. I'm probably grossly misunderstanding the situation.
EDIT2: Ok, so I guess AVFoundation is just the objective-c frontend for OSX's media libs. I can't for the life of me understand why it took them so long to implement.
This means that sites that control playback speed using the HTML media API should work.
Basically, "Firefox" is the stable release. It's the one most people use, and should use. It's currently at version 17, for people who actually still care about version numbers :)
On top of that there are three release channels that offer preview builds of varying levels:
* Beta -- is exactly what it sounds like. Beta builds of what will become the next release of Firefox. Beta builds currently are version numbered 18.
* Aurora -- stable but pre-beta. Is two "versions" ahead of mainline Firefox, so Aurora builds are currently version numbered 19.
* Nightly -- the bleeding edge. Rebuilt every single night from latest code, these are three "versions" ahead of mainline, so currently carry version number 20.
mozilla-central is where stuff is true bleeding edge/may kill your cat more often than not, etc.
Beyond saving half of your disk space this is nice because WebM has limited toolchain support so anyone with a video production pipeline basically had to decide whether it was worth the effort integrating a bunch of new tools or continuing to put up with Flash.
Even on youtube, 50% of the videos I try to see cannot be watched without flash.
Firefox: nightly, aurora, beta, release
Isn't Chrome dev the parallel to Firefox aurora?
On my machine, Canary is version 25.0.1365.1 and Dev is 25.0.1364.2, slightly behind. Beta is 24.0.1312.25.