back
64 comments
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.

If you're curious why, see this mailing list thread for the discussion:

https://groups.google.com/d/msg/mozilla.dev.platform/-xTei5r...

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).

Take a look at http://hacks.mozilla.org/2012/03/video-mobile-and-the-open-w... for an official statement from Mozilla on this.

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.

There's a variety of arguments. This was debated to death a couple years ago. http://robert.ocallahan.org/2010/01/video-freedom-and-mozill... contains some discussion, and Google will turn up much more if you're interested.
> I would hope they would support everything practical to support

And how practical is it to support a for-pay format when you're in the business of giving your product away?

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.

And you know what? That sucks.

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:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05698...

"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?
Firefox OS already has hardware H.264 decoding support. We use the Android libstagefright library and the phone vendor provides the hardware decoders.
>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?
seems it was more about marketing than anything :( they probably dropped the ball midway for reasons similar to firefox
>[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?

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. :(

You can actually get a licensed codec for Linux, if you're willing to pay for it, like the Fluendo[1].

Personally, I just use x264. Fuck MPEG-LA.

[1]: http://www.fluendo.com/shop/product/complete-set-of-playback...

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.
For WinXP do you need to transcode, or can you just serve a lightweight player UI that use H.264 support built into the Flash plugin?
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 20 moves to aurora channel on January 6th so it will get a little more exposure then.

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.

Is this good or bad? Does Firefox support H.264 on other OS like Mac or Linux without flash, too?
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.
There are bugs open on doing that and progress on them. I think the windows one was first to land on nightly.
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.

You know, instead of writing things without checking you could have looked this up: i.e. via the tracking bug in bugzilla:

Support H.264/AAC/MP3 video/audio playback on desktop Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=799318)

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. (https://bugzilla.mozilla.org/show_bug.cgi?id=801521)

OS X has H.264 available to all developers without additional licensing fees. Why would Firefox need to have a separate licensing agreement?
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.

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).
Support for HTML's playbackRate API was landed a few weeks back. See bug 495040 https://bugzilla.mozilla.org/show_bug.cgi?id=495040

This means that sites that control playback speed using the HTML media API should work.

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.

actually even nightly is supposed to be mostly stable.

mozilla-central is where stuff is true bleeding edge/may kill your cat more often than not, etc.

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.

It's a huge step for encoding videos in just one format for all browsers.

Even on youtube, 50% of the videos I try to see cannot be watched without flash.

"Videos with ads are not supported (they will play in the Flash player)". http://www.youtube.com/html5
You can watch those without Flash by faking your UA string (try e.g. iPad). Feature detection, Google?
For all browsers running on the same operating system i.e. Windows.
I believe that "Nightly" refers to the nightly build. That is it is a build of Firefox that follows the current development branch.
Will Mac also get this? I'm not sure, but I think this CoreAudio, CoreVideo and friends might have this stuff.
They plan to implement OSX support soon. Here's the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=801521

Wow, they're at 20 already? At that rate, they'll reach Firefox 100 in a decade. Frankly, it sounds quite ridiculous.
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 has a shorter beta testing cycle? I thought both browsers had 6 weeks for that.