
H.264 Support Lands in Firefox 20 Nightly on Windows - twapi
http://browserfame.com/1033/firefox-h264-codec-windows
======
mtgx
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.

~~~
duaneb
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.

~~~
kybernetikos
> 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?

~~~
epistasis
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.

<http://www.mpegla.com/main/programs/avc/Documents/avcweb.pdf>

~~~
nitrogen
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...](http://www.zdnet.com/blog/bott/a-closer-look-at-the-costs-and-fine-
print-of-h-264-licenses/2884)).

------
twoodfin
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?

~~~
zobzu
seems it was more about marketing than anything :( they probably dropped the
ball midway for reasons similar to firefox

~~~
polshaw
_> [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?

~~~
ZeroGravitas
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.

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

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

~~~
icebraining
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...](http://www.fluendo.com/shop/product/complete-set-of-playback-
plugins/)

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

~~~
prodigal_erik
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?

~~~
acdha
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.

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

------
buster
Is this good or bad? Does Firefox support H.264 on other OS like Mac or Linux
without flash, too?

~~~
cube13
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.

~~~
0x006A
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>)

~~~
cube13
None of those bugs are resolved, so where was I wrong?

In fact, there's this bug for H.264 support:
<https://bugzilla.mozilla.org/show_bug.cgi?id=541286>

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.

~~~
doublec
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.

~~~
0x006A
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.

~~~
doublec
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.

------
HelloMcFly
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?

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

~~~
doublec
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.

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

~~~
ck2
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.

~~~
PleaseStand
"Videos with ads are not supported (they will play in the Flash player)".
<http://www.youtube.com/html5>

------
pepijndevos
Will Mac also get this? I'm not sure, but I think this CoreAudio, CoreVideo
and friends might have this stuff.

~~~
dbcooper
They plan to implement OSX support soon. Here's the bug:

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

------
devcpp
Wow, they're at 20 already? At that rate, they'll reach Firefox 100 in a
decade. Frankly, it sounds quite ridiculous.

~~~
cpeterso
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.

~~~
azakai
Chrome has a shorter beta testing cycle? I thought both browsers had 6 weeks
for that.

~~~
cpeterso
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. :\

~~~
azakai
Chrome: canary, dev, beta, release

Firefox: nightly, aurora, beta, release

Isn't Chrome dev the parallel to Firefox aurora?

~~~
cpeterso
AFAICT, Canary is like Nightly and Dev is a ~weekly stable snapshot of Canary.
So Dev is running parallel to Canary.

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.

~~~
azakai
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".

