Summon comment box
This is a tracking bug for desktop support of H.264/AAC/MP3 playback using the HTML video and audio elements.
Also depends on 435298 https://bugzilla.mozilla.org/show_bug.cgi?id=435298
*** Bug 801485 has been marked as a duplicate of this bug. ***
Removing bug 541286, we're never going to support MPEG2 and that bug is already WONTFIXed.
Matthew, obviously the decision which lead to WONTFIX bug 541286 was reversed. Thus, this is a clear dup of bug 541286.
In fact, the approach employed here to get around patent issues by using platform APIs is exactly what I proposed in bug 541286.
(In reply to Ben Bucksch (:BenB) from comment #4) > Thus, this is a clear dup of bug 541286. No, this is a tracking bug for actual work. Bug 541286 turned in to a discussion bug and covers unrelated topics such as codecs we won't be supporting. Let's keep this bug clean and use it for things that matter, please.
Matthew, we don't re-file bugs that we already have, but we use the older bug. The discussion there is actually useful. This is an open source project, not your personal desktop.
*** Bug 815808 has been marked as a duplicate of this bug. ***
(In reply to Ben Bucksch (:BenB) from comment #7) > Matthew, we don't re-file bugs that we already have, but we use the older > bug. The discussion there is actually useful. This is an open source > project, not your personal desktop. FWIW, we re-file bugs *all the time* when the old bug has turned into a flame war and a developer wants to get actual work done without dealing with unproductive discussion. Bugs are cheap, and if people are doing actual work then bugzilla pedantry is counterproductive.
> if people are doing actual work then bugzilla pedantry is counterproductive. Can I take that to mean that if somebody did "actual work" to allow MPEG2, that work would be accepted?
(In reply to Ben Bucksch (:BenB) from comment #10) > Can I take that to mean that if somebody did "actual work" to allow MPEG2, > that work would be accepted? I don't think that's what ted meant at all.
*** Bug 835386 has been marked as a duplicate of this bug. ***
*** Bug 856093 has been marked as a duplicate of this bug. ***
*** Bug 859090 has been marked as a duplicate of this bug. ***
Any idea when will the linux version be capable of such playback?
(In reply to kkostas_2006 from comment #15) > Any idea when will the linux version be capable of such playback? If you build Firefox with the "--enable-gstreamer" option it should work. There's still some things to be ironed out which is why it's not on by default.
Well, when? Linux and Mac don't have this yet but Windows has already made release, though disabled for now. Is this being prioritized yet? Will all tier 1 platforms get it on by default at the same time? I'm aware Windows has most of the users, but Mac and Linux aren't feeling like tier 1 platforms at this rate.
(In reply to Dave Garrett from comment #17) > Well, when? Linux and Mac don't have this yet but Windows has already made > release, though disabled for now. Is this being prioritized yet? Will all > tier 1 platforms get it on by default at the same time? I'm aware Windows > has most of the users, but Mac and Linux aren't feeling like tier 1 > platforms at this rate. You'll want to follow bug 794282 and bug 851290. AFAIK the plan is still to support this on all platforms in the same release.
(In reply to Chris Double (:doublec) from comment #16) > (In reply to kkostas_2006 from comment #15) > > Any idea when will the linux version be capable of such playback? > > If you build Firefox with the "--enable-gstreamer" option it should work. > There's still some things to be ironed out which is why it's not on by > default. I finally managed to build a Linux64 Firefox from source with gstreamer enabled. Running it right here, right now, works well, much better than I expected really. See no reason why Nightly builds can't be compiled with --enable-gstreamer option, you can still pref it off by default (I see there is a media.gstreamer.enabled option in about:config). Turning on a flag in about:config is definitely done a few hours more quickly than compiling a Firefox build from source.
(In reply to Markus Popp from comment #19) > See no reason why Nightly builds can't be compiled with --enable-gstreamer > option, you can still pref it off by default There are issues related to what version(s) of gstreamer happen to be installed at runtime that haven't yet been resolved. That's what I was a little worried about, but bug 859199 just showed up with a patch in progress that aims to get this in working order. :) (In reply to John Schoenick [:johns] from comment #18) > AFAIK the plan is still to support this on all platforms in the same release. Thank you for that clarification.
(In reply to John Schoenick [:johns] from comment #18) > You'll want to follow bug 794282 and bug 851290. AFAIK the plan is still to > support this on all platforms in the same release. WMF backend is still enabled on beta. https://mxr.mozilla.org/mozilla-beta/search?string=media.windows-media-foundation.enabled Are you saying bug 837859 will be reverted? (Because it's very unlikely that GStreamer support will be enabled on Linux and Mac OS X and backported to beta in 5 weeks.)
(In reply to Masatoshi Kimura [:emk] from comment #21) > (In reply to John Schoenick [:johns] from comment #18) > > You'll want to follow bug 794282 and bug 851290. AFAIK the plan is still to > > support this on all platforms in the same release. No, we're going to ship H.264/AAC/MP3 support on platforms as we implement them, we're not waiting for them all to be ready to ship at the same time. We've already done this by shipping H.264/AAC/MP3 on Firefox for Android for example.
(In reply to Masatoshi Kimura [:emk] from comment #21) > WMF backend is still enabled on beta. > https://mxr.mozilla.org/mozilla-beta/search?string=media.windows-media- > foundation.enabled > Are you saying bug 837859 will be reverted? (Because it's very unlikely that > GStreamer support will be enabled on Linux and Mac OS X and backported to > beta in 5 weeks.) (In reply to Chris Pearce (:cpearce) from comment #22) > No, we're going to ship H.264/AAC/MP3 support on platforms as we implement > them, we're not waiting for them all to be ready to ship at the same time. > We've already done this by shipping H.264/AAC/MP3 on Firefox for Android for > example. I stand corrected! Apologies for the misinformation
(In reply to Chris Pearce (:cpearce) from comment #22) > No, we're going to ship H.264/AAC/MP3 support on platforms as we implement > them, we're not waiting for them all to be ready to ship at the same time. > We've already done this by shipping H.264/AAC/MP3 on Firefox for Android for > example. Mobile and desktop are two very different things. All the tier 1 desktop platforms really should end up with it on by default in the same release, otherwise you're inviting sites to code just for Firefox for Windows, probably with bad UA sniffing. You're also basically saying that Mac and Linux aren't really tier 1 supported anymore, seeing as feature parity will go away in a noticeable way, which is not a great message. :/ Is there the possibility of getting things backported to Aurora (or next Beta) so they're only a release apart? Or, is the current plan to be separated 2 or 3 cycles?
Web developers should use the HTMLMediaElement.canPlayType() function to determine whether a user agent can play different formats, they shouldn't sniff user agents. We are actively working on Linux and Mac support, H.264/AAC/MP3 on all tier-1 platforms is a priority for the media team at the moment.
(In reply to Dave Garrett from comment #24) > Mobile and desktop are two very different things. All the tier 1 desktop > platforms really should end up with it on by default in the same release, > otherwise you're inviting sites to code just for Firefox for Windows, > probably with bad UA sniffing. You're also basically saying that Mac and > Linux aren't really tier 1 supported anymore As someone who has used only a Linux or Mac desktop since before Firefox existed, I respectfully disagree. <video> has a great canPlayType format detection feature – which is what I use to serve H.264 and fall back to Flash for Firefox and IE8 – and I think it's critically important to start make Firefox competitive, particularly since the Windows port is both the most widely used and very popular in enterprise shops as an alternative to legacy IE. Getting those users off of Flash is a bigger win for the web than coaxing a much smaller number of Mac users like me away from browsers like Chrome/Safari which already support H.264 <video>.
I was not aware of HTMLMediaElement.canPlayType() and do hope it is as widely used as it should be. It still bugs me that support is landing inconsistently, nonetheless. Anyway, thanks for clarifying the official position on the topic.
My 2 cents: I agree that the advantage that the majority of Firefox users on Windows get H.264/AAC/MP3 ASAP outweighs the disadvantage that not all platforms get support at the same time. But to avoid that users on Linux and OS X feel like 2nd class citizens it would certainly be helpful if by the time when H.264/AAC/MP3 support becomes available in a final Firefox for Windows release (i.e. 21.0 as it looks), support for H.264/AAC/MP3 would at least be available in development builds for Linux and OS X. So you can say: "sorry, we're late on Linux & OS X, but if this is important to you, we can offer you something". To accomplish that, gstreamer support would have to be enabled before Firefox 21 gets released, which means during the current development cycle. So H.264/AAC/MP3 playback would be available for Linux and OS X in the Aurora channel by the end of the week of the Firefox 21.0 release. Given that my self compiled Linux64 build with --enable-gstreamer looks very good in terms of H.264/AAC/MP3 playback (actually I can't find a difference to Firefox Beta on Windows), maybe this is a realistic goal to target.
People need to use .canPlayType() (or other fallback-based solutions) in any case as we only support those types if they're present on the system. I'm not sure if you can even uninstall them on Windows or Mac, but I know for sure that not all Linux installations will have them available, and I guess the same can be true on Android, esp. as we blocklist this functionality on some devices. So, people can never take for granted that some version of Firefox can play those files for sure, UA detection is useless here. Only .canPlayType() can determine if we really can play it.
I added http://areweplayingyet.org/ to the URL field showing examples of .canPlayType() (In reply to Dave Garrett from comment #17) > Mac and Linux aren't feeling like tier 1 platforms at this rate. (In reply to Markus Popp from comment #28) > So you can say: "sorry, we're late on Linux & OS X Please note that Windows Vista support is also late (Firefox 22), see bug 825153, and Windows XP is likely to only get .mp3 support at a yet to be determined version, see bug 861693. Support landing inconsistently was known and used initially as an argument to not support patent encumbered formats in any way back before that stance was reversed, see http://robert.ocallahan.org/2009/06/directshow-and-platform-media_23.html
(In reply to Mardeg from comment #30) > I added http://areweplayingyet.org/ to the URL field showing examples of > .canPlayType() > (In reply to Dave Garrett from comment #17) > > Mac and Linux aren't feeling like tier 1 platforms at this rate. > (In reply to Markus Popp from comment #28) > > So you can say: "sorry, we're late on Linux & OS X > Please note that Windows Vista support is also late (Firefox 22), see bug > 825153, and Windows XP is likely to only get .mp3 support at a yet to be > determined version, see bug 861693. Support landing inconsistently was known > and used initially as an argument to not support patent encumbered formats > in any way back before that stance was reversed, see > http://robert.ocallahan.org/2009/06/directshow-and-platform-media_23.html My point is that for the most part (actually I haven't encountered any issues at all), it works (on Linux), but in order to get a copy with gstreamer, I have to compile Firefox on my own which is time consuming and annoying. I can't see why Nightlies aren't built with --enable-gstreamer already, and if really necessary, preffed off. And if things aren't 100 % matured and stable yet, that's why Nightlies are Nightlies, and not final releases.
(In reply to Markus Popp from comment #31) > I can't see why Nightlies aren't built with --enable-gstreamer already, and > if really necessary, preffed off. Currently, if you don't have gstreamer installed or have a different version than it was built for then Firefox won't start at all. This is being fixed in bug 859199 after which point it'll be added to Nightly builds in some form. (In reply to Mardeg from comment #30) > Please note that Windows Vista support is also late (Firefox 22), see bug > 825153, and Windows XP is likely to only get .mp3 support at a yet to be > determined version, see bug 861693. Those are old operating systems. Technically, nobody should be running them anymore (though obviously people do in droves; my gaming OS is still XP). The high-priced OS plus paid upgrade model just forces people into old, out of date, and insecure OSes, which is sad. Also, every other MS OS release sucks. Is no effort being made to get h.264 support on XP through DirectShow? I can understand not wanting to. You'd be relying on whatever 3rd party codecs were installed to do it, but it would at least give them feature parity. I'm wondering if it would be possible to have this sort of thing in an addon so XP users could at least have the hoops to jump through if they knew what they were doing.
Directshow as a back-end, even if possible (and even already having a patch for it) was made a WONTFIX. It's a pity since it's a nice framework to use, although it does have a few drawbacks, of course. Bug 435339 - DirectShow backend for HTML5 video element
I am currently resurrecting the DirectShow backend for MP3 playback only in bug 861693.
Why not use DirectShow for more than just MP3 audio on XP/Vista? I mean, if the capability is there to use the code for video as well, might as well use it...
WinXP does not contain H.264 codec. Roc suggested it may be possible to use H.264 decoder from Flash Player.
DirectShow is a framework that allows you to use any installed codec - including e.g. ffdshow and others that most definitely do support H.264 and other decoders to play just about any format available.
We won't support any random format which may or may not be installed on users' system. H.264 is an exception because of the patent restriction.
emk, nobody said that. We can use DirectShow and whitelist the formats. Even if they are not coming by default with the OS release, the user can still install them (via MediaCenter, ffdshow, DVD player software, whatever), and we use them, and only those.
Patents suck.
Guys, I noticed that Firefox nightly (25.0a1) when uses gstreamer have a big performance during playing of mp4 stream. I use ArchLinux Gstreamer 0.10 and 1.0 was installed, also vaapi plugin for 0.10 and 1.0 was installed also. If try to play file via below command (for 0.10 and 1.0 version) I see that vaapi is used and performance is low. gst-launch playbin2 <url> Should I open a defect for this or working in this area is performing now? Best Regards, Vladimir
> Should I open a defect for this Yes, please open a new bug. You can mention the bug number here as reference for others.
Done, 894372 was open.
Firefox 21 was released on 2013-05-14. I'm currently using Firefox Aurora 24.0a2 (2013-08-05) for Mac and I've got my homepage set to "about:config" so that I can check if anything like "media.windows-media-foundation.enabled" got added. It's been almost three months now since Win7+ had support for this enabled by default in a stable release. The last update for getting H.264/AAC/MP3 support for Mac: bug 851290 was back in June, yet the last update for supporting WinXP: bug 861693 was... Yesterday. Why is Windows XP (now 4 generations old) getting more attention than the current generation of Mac OSX?
(In reply to jcready from comment #44) > Why is Windows XP (now 4 generations old) getting more attention than the > current generation of Mac OSX? Because it has five times as many users, obviously.
(In reply to Dave Garrett from comment #45) > (In reply to jcready from comment #44) > > Why is Windows XP (now 4 generations old) getting more attention than the > > current generation of Mac OSX? > > Because it has five times as many users, unfortunately. Fixed.
There is that bug on vimeo where some html5 H264 videos are not displayed within Firefox. It seems to be a bug common to GNU/Linux & Firefox OS : https://bugzilla.mozilla.org/show_bug.cgi?id=884558#c1 Is it related to Bug 875573 (Add support for m4v as 'video/x-m4v' MIME type) ? Or shall we update the dependance tree of this bug ?
Does the http://www.openh264.org/ effort have an impact on what we're doing here? Notably, on platforms where we're not done yet, like mac? (i know, still nothing but "soon" there, but still)
*** Bug 942130 has been marked as a duplicate of this bug. ***
To enable H.264 in Debian Firefox 24/25 (Iceweasel) build you must install apt-get install gstreamer0.10-plugins-good gstreamer0.10-ffmpeg and enable gstream support in about:config "media.gstreamer.enabled" according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917
But what about gstreamer 1.x which is spread more and more on distributions ? Like in bug #921714 ?
Debian package maintainer just add --enable-gstreamer to ./configure. If 1.x compatible with 0.10.x I see no problem...
(In reply to Frederic Bezies from comment #51) > But what about gstreamer 1.x which is spread more and more on distributions > ? Like in bug #921714 ? GStreamer 1.0 support is Bug 806917.
or
