I wonder why they gave up on this issue. I think it's because of Firefox OS. But all new chips support hardware acceleration for VP8, so I don't get it. Also, VP9, which is the codec Google started working on since they bought On2, is starting to be implemented in Chromium, along with Opus inside WebM.
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.
The biggest reason: the majority of sites used h.264 video with fallbacks to a Flash h.264 player rather than a WebM video; thus, refusing to support h.264 just resulted in more usage of the proprietary Flash player and less use of <video>. Mozilla cared about supporting an open video format, but also cared even more about killing off Flash in favor of open web standards.
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).
To be honest, I was not even aware that VP8/VP9/WebM/whatever existed; I always just thought that Firefox had crappy video support.
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.
Mozilla doesn't have to pay for anything, as they can use codecs that exist on the supporting platform, precisely as they are doing on Windows, and will do on Mac.
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 [1]. 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.
It's not the decoder fee alone that was a problem for Firefox, it was the patent encumrance (problematic for an internationally distributed open source browser), not to mention the requirement for some content producers to pay a separate license just to be able to take advantage of the encoder licenses they already paid for with their camera and editing software. Also, instead of getting cheaper over time, MPEG-LA can raise the H.264 rates by 10% every five years (http://www.zdnet.com/blog/bott/a-closer-look-at-the-costs-an...).
I wonder why they NOT gave up the issues earlier at all. They were battling in my view as a lost battle before they start.
I would be surprise if these new chips even comprise of more then 20% of the current total market shares. There are many who claimed to have Hardware Decode of Vp8 are actually not fully hardware accelerated.
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.
Better quality royalty-free audio and video codecs would have arrived a lot faster if it wasn't for so many people taking an astoundingly short-term view on what "sucks".
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.
>Better quality royalty-free audio and video codecs would have arrived a lot faster if it wasn't for so many people taking an astoundingly short-term view on what "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).
Have the IETF actually chosen VP8 as the/a mandatory to implement video codec for RTCWeb yet?
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."
But what will they do for Firefox OS? Leave it out? Get OEMs on board, and have them pay the license fee? Add an 'in app purchase' where users can buy H.264 decoding?
>I wonder why they gave up on this issue. I think it's because of Firefox OS. But all new chips support hardware acceleration for VP8, so I don't get it.
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.
On a related note, has Google officially dropped their plans to remove H.264 from Chrome? They made a big deal about it a couple of years ago, but it's still there, no?
>[google] probably dropped the ball midway for reasons similar to firefox
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?
It was a good effort from Google but just too late to win that particular battle.
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.
more accurately, OS media decoders are now supported on firefox. Firefox isn't actually providing support for h.264, they're just exposing your operating system's video decoders. so if your OS doesn't have h.264 support, you're not going to have it in firefox.
As far as I know, the only reasonably common desktop OS to lack H.264 support out of the box is Windows XP, and Mozilla plans to use Flash to decode H.264 video there.
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. :(
Note H.264 support in Firefox is only available on Windows 7, and soon Vista. So if you want to support Windows XP, you will still need WebM, Ogg, or Flash fallback.
Use something like mediaelement.js which uses standard formats first and falls back to Flash if not - XP is a legacy platform so there's no point in investing time on it.
It depends. You'll get better integration into the browser if you transcode. But if you're doing the "YouTube testcase", just using a Flash player fallback (without transcoding) would probably suit your needs adequately.
Firefox on Linux has GStreamer but it's turned off at build time. Developers can build with it to test it. At some point it'll be enabled by default, or distros can enable it for their builds, to get H.264 support.
Firefox only supports H.264 on Win7 and above because MS provided a plugin for the MS-provided codec.
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.
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)
We are implementing support on desktop using OS frameworks where we can. So far we have:
- 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.
will you enable H.264 support only on desktops once you have working backends for Windows/Linux/OS X or will they be enabled by default as they are working? Just wondering if there will be stable releases of Firefox where some platforms have H.264 decodes and some don't.
They will be enabled by default as they are working. We already have the issue of some platforms having it and others not. Some Android devices have it with Firefox for Android and some don't for example. Linux distro's could enable the GStreamer backend and gain it while others don't as another.
For detection sites should use the API "canPlayType" and similar functionality to detect if the browser supports playback.
It was a pretty big deal a while ago that quicktime support H.264; off hand, I'm pretty sure they supported it for years before MS did. If firefox supports quicktime, they support H.264.
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.
a) We decided not to support h.264 for non-technical reasons (patent-encumbrance etc) for quite some time.
b) We don't have infinite developer resources, so it just hasn't gotten done since then.
Does that mean soon I'll be able to control playback speed on Coursera and Khan Academy (presuming I've signed up for HTML5 beta in YouTube, which I have)? Anyone know?
If this new H.264 support in Firefox means that you can control playback speed on YouTube itself, you should also be able to control the speed on Khan Academy (or any other site that uses YouTube's iframe embed).
Yeah I'm struggling to determine if this really is a big step. I'm not sure what the difference is between "Firefox Nightly" and regular old Firefox. But honestly, most browsers support H.264/MPEG-4 AVC at this point(especially mobile). I would really like to see this become the primary codec for streaming web video. It has excellent compression ratios, much better than webm or flv and it's the perfect encoding type for HD videos.
Nightly is the build generated each night from the latest trunk code. After 6 weeks, nightly becomes aurora, which is more stable (not updated each night). Then after 6 weeks, it becomes beta and is tested by a wide audience. After 6 more weeks, it is released as the current stable version.
I'm not sure what the difference is between "Firefox Nightly" and regular old Firefox.
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.
It's big for anyone doing video because it means you no longer need to encode everything in two formats simply to support Firefox.
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.
The end user shouldn't care or know what version the browser for anything but troubleshooting anyways, to them it's just "Firefox" and "Chrome" no more of this stupid bullshit like IE6/7/8/9/10 that will held back progress for the last decade and will continue to do so for the next decade to come.
So? Chrome's dev channel is version 25. Plus, Chrome has a shorter beta testing cycle than Firefox, so Chrome's version number will always outpace Firefox's.
Chrome and Firefox both have 6 week release cycles, but Chrome does not have an equivalent to Firefox's Aurora channel. Aurora adds an extra 6 weeks from feature checkin to release. :\
Oh, I didn't realize that. I don't see this written anywhere though, the best I could find is a quote from Paul Irish that features on Canary get to users in 11 weeks, "unless there is a delay".
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.