Build Firefox with GStreamer support

[Mar-castelluccio]

Building Firefox with GStreamer support would provide support for a lot of websites that use h264.
To build Firefox with GStreamer support you should use the "--enable-gstreamer" option.

[Mar-castelluccio (mar-castelluccio)]

Alessandro Decina is the guy who worked on GStreamer in Firefox, most probably he knows if this is feasible right now better than me.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Coulson (chrisccoulson)]

Hi,

Does anyone have any idea of Mozilla's own plan for enabling this? (ie, is there one?) In general I avoid turning on options that are NPOTB upstream, as this can leave us quite exposed to changes which result in our packages being unbuildable (it's happened before with GIO support, which we do enable).

[Mar-castelluccio (mar-castelluccio)]

Enable GStreamer in official builds for Linux.

[Mar-castelluccio (mar-castelluccio)]

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

[Ted Mielczarek (ted-mielczarek)]

I suspect we don't want to do this until we have a plan for getting support for all the platforms we ship desktop Firefox on. Just shipping h.264 support on Linux doesn't help us. (And it might hurt us, by having different codecs supported on different desktop Firefox builds.)

[Pdowling (pdowling)]

Does having different codecs in mobile and desktop already hurt?

Case: User wants to view a video they have accessed on Firefox mobile and synced with Firefox Sync onto their desktop. One scenario they can play it, another they cannot, frustration ensues?

In addition, Flash continues to be problematic for security, reliability and so on. Enabling genuine HTML5 video support (h.264) across all desktop and mobile builds would enable developers to take a genuine pro-HTML5 open web, plugin-free step they cannot easily take right now because Firefox is a substantial blocker for h.264 on a seemingly shrinking basis.

Re XP lacking native h.264 support, what are the issues surrounding bundling or linking to the x264 codec to solve this issue?

[Chris Double (doublec)]

I think we should enable GStreamer in Linux builds even if we don't support H.264 in the other platforms yet.

Things to be resolved before we can do this though:

1) Get the mochitest media tests passing. There's a H.264 video file in the tests already.
2) Ensure Firefox still runs on Linux distributions that don't have GStreamer or have older versions.
3) Check that we have new enough GStreamer libraries on build machines.

[Pdowling (pdowling)]

(In reply to Chris Double (:doublec) from comment #3)
> I think we should enable GStreamer in Linux builds even if we don't support
> H.264 in the other platforms yet.

Agreed.

> Things to be resolved before we can do this though:
>
> 1) Get the mochitest media tests passing. There's a H.264 video file in the
> tests already.
> 2) Ensure Firefox still runs on Linux distributions that don't have
> GStreamer or have older versions.
> 3) Check that we have new enough GStreamer libraries on build machines.

I'd be more than willing to help test at least every Debian-based distribution I can get my hands on as I have basic familiarity with the Advanced Packaging Tool (apt) but not really with rpm or other systems.

[Henri Sivonen (hsivonen)]

(In reply to Chris Double (:doublec) from comment #3)
> I think we should enable GStreamer in Linux builds even if we don't support
> H.264 in the other platforms yet.
>
> Things to be resolved before we can do this though:
>
> 1) Get the mochitest media tests passing. There's a H.264 video file in the
> tests already.
> 2) Ensure Firefox still runs on Linux distributions that don't have
> GStreamer or have older versions.
> 3) Check that we have new enough GStreamer libraries on build machines.

4) Check that when MP4, H.264 and AAC support is present, canPlayType() behaves as in other H.264 and AAC-supporting browsers. See bug 760140.

5) Test that when both H.264 and AAC decoders are absent, canPlayType() behaves like in Firefox today even if an MP4 demuxer is present.

6) Test that MPEG4 Visual, MPEG2 or other non-H.264, non-AAC encumbered codecs do not get exposed to the Web as a side effect.

#4 and #5 are important for avoiding poisoning canPlayType(). #6 is important to take care of before enablement, because it’s hard to take features away even if the features were unintentional.

[Mh+mozilla (mh+mozilla)]

I doubt this is possible to do for official builds. Distro builds could do it, but official will likely have a hard time maintaining binary compatibility with different versions of the system libraries. Look at the ABI changes between 0.10 and 1.0. http://upstream-tracker.org/versions/gstreamer.html

[Mh+mozilla (mh+mozilla)]

and no, embedding gstreamer like we embed other third party libraries won't help. The only way it would work would be to also embed the mp4 decoder, and that's opening a legal can of worms.

[Pdowling (pdowling)]

(In reply to Mike Hommey [:glandium] from comment #7)
> and no, embedding gstreamer like we embed other third party libraries won't
> help. The only way it would work would be to also embed the mp4 decoder, and
> that's opening a legal can of worms.

Perhaps we're missing the point here. I realize this specific bug focuses on GStreamer but AFAIK the broader goal is (or perhaps should be?) enabling HTML5 <video> support for the most common format(s) on all platforms that Firefox supports.

Is it possible that this goal would be more easily achieved if Firefox were to use the native media frameworks for each platform, i.e. DirectShow, GStreamer and Quicktime, as Firefox mobile does with Stagefright? Would utilizing these frameworks possibly be less work than targeting a single framework that perhaps changes so often because it is trying to be everything to everybody?

On another note, has anybody engaged the GStreamer people and asked them if they are willing to work with Mozilla by maintaining a branch of their code that preserves binary compatibility for longer than they historically have to date? If not glacial pack ice frozen APIs, perhaps ice cube APIs capable of thawing every summer or so? :) There could be a ceremonial GStreamer/Mozilla ice cooler that API documents get thrown into, a bit like a time capsule :) Sorry, just a bit of mirth there!

In addition, doesn't any code base change a lot more frequently whilst getting to version 1 than it is likely to after that point? Perhaps then Mr Hommey's example in comment 6 is not necessarily representative of future development trends?

Apologies if these points are less technical and more general than is ideal. However this bug thus far has seemed to evolve in more of a discussion manner than other bugs might normally so I hope it's ok to continue that style for the moment at least.

[Henri Sivonen (hsivonen)]

(In reply to Mike Hommey [:glandium] from comment #6)
> I doubt this is possible to do for official builds. Distro builds could do
> it, but official will likely have a hard time maintaining binary
> compatibility with different versions of the system libraries. Look at the
> ABI changes between 0.10 and 1.0.
> http://upstream-tracker.org/versions/gstreamer.html

I took the topic to dev-planning since Bugzilla isn’t a discussion forum:
https://groups.google.com/d/topic/mozilla.dev.planning/aYOuhdkKNXo/discussion

[Matěj Cepl (mcepl)]

Just to note that we are IMHO getting back to bug 422540, bug 435298, and bug 435339, which IMHO was a mistake to WONTFIX.

[Chris Double (doublec)]

(In reply to Matej Cepl from comment #10)
> Just to note that we are IMHO getting back to bug 422540, bug 435298, and
> bug 435339, which IMHO was a mistake to WONTFIX.

It was WONTFIX according to the policies and direction at the time. How (and if) support of H.264 across platforms is eventually done is yet to be decided and it may be that those approaches are used. I'd rather leave general H.264 support out of this bug though and concentrate on what needs to be done to get GStreamer enabled - if it's even a good idea based on Mike Hommey's comments.

Is it better just to leave it up to distro's to enable? Should we change the GStreamer backend to use the MPAPI plugin approach that Android's media support uses to enable dynamic loading of it?

[Riles (riles)]

gladium makes a good point. I think it's clear that if we enabled the gstreamer backend in official builds, we'd want to include our own build. But that doesn't help if it's not abi compatible with the elements we want to use on the system.

I just tried loading the fluendo binary elements for gstreamer-0.10 with today's git (gstreamer 1.0.0) and it wasn't able to find the entry points:

  WARN GST_PLUGIN_LOADING gstplugin.c:383:gst_plugin_register_func: plugin "/home/giles/gstreamer/fluendo-bin/libgstflump3dec.so" has incompatible version, not loading

So while I thought it was clear official biulds would include their own builds of gstreamer if we enabled this back end, that doesn't help if we can't load elements from the system gstreamer install.

We could still pick a target version and only support that, which is easier to do now that gstreamer 1.0 is released. That might be ok if we could fall back to our built-in decoders when the requested elements aren't available.

[Mar-castelluccio (mar-castelluccio)]

http://www.collabora.com/about/gstreamer-interview/
Looks like simple usages of GStreamer shouldn't be broken (but http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-1.0.txt is pretty long...).
Maybe we can load GStreamer dynamically and, if we use only a subset of the API, we could avoid running into issues (just like we're now doing with libnotify).
AFAIK, there will be other API breakages in the future.

[Riles (riles)]

Keep in mind that calling system gstreamer libraries means feeding data from the network into code we have no way to issue security fixes for.

Being able to protect our users independent of distro updates is why the official builds include there own copy of even ubiquitous libraries like zlib.

[sam tygier (samtygier)]

There is an existing old Bug #412647 . Not sure if this would be considered a dupe of the old one, as this is just specifically asking for a build option change. but fixing this would fix #412647.

there is also useful discussion at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917 and https://bugzilla.redhat.com/show_bug.cgi?id=843583 including some reports of regressions with the gstreamer build.

[sam tygier (samtygier)]

some related discussion in the distros, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917 https://bugzilla.redhat.com/show_bug.cgi?id=843583

[Henri Sivonen (hsivonen)]

(In reply to Ralph Giles (:rillian) from comment #14)
> Keep in mind that calling system gstreamer libraries means feeding data from
> the network into code we have no way to issue security fixes for.

We are already on track to doing that on Android, and the Android security update situation is worse than the security update situation on various desktop Linux distros. As in: It’s worse to the point of not having system updates—security or other—in most cases.

(In reply to sam tygier from comment #15)
> some related discussion in the distros,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917
> https://bugzilla.redhat.com/show_bug.cgi?id=843583

I think it would be unwise for distros to turn GStreamer on before bug 760140 is fixed.

[Cpearce-t (cpearce-t)]

Created attachment 670672
GStreamer backend mochitest failures (with GStreamer only playing H.264, not Ogg or WebM)

Additionally, the mochitests fail with the GStreamer backend enabled. Currently the GStreamer backend takes over playback of Ogg and WebM resources when it's enabled, and Firefox times out trying to run test_buffered because GStreamer can't handle playing Opus in Ogg. test_a4_tone also fails.

If I change our code to use our existing Ogg/WebM backends for Ogg/WebM when the GStreamer backend is enabled (so GStreamer only plays H.264, not Ogg or WebM), the test run completes but with test failures and a shutdown hang with the decode thread stuck in nsGStreamerReader::WaitForDecodedData().

The unexpected test failures from the mochitest run's log are attached.

Looks like mostly problems with duration calculation.

[Riles (riles)]

(In reply to Henri Sivonen (:hsivonen) from comment #16)

> We are already on track to doing that on Android, and the Android security
> update situation is worse than the security update situation on various
> desktop Linux distros. As in: It’s worse to the point of not having system
> updates—security or other—in most cases.

This is a good point of perspective, although relinquishing control of code on one platform does not make it ok to do so on another.

Perhaps we should add some infrastructure to let us blacklist particular gstreamer elements, the way we do with plugins?

(In reply to Chris Pearce (:cpearce) from comment #17)

> Additionally, the mochitests fail with the GStreamer backend enabled.
> Currently the GStreamer backend takes over playback of Ogg and WebM
> resources when it's enabled, and Firefox times out trying to run
> test_buffered because GStreamer can't handle playing Opus in Ogg.

Do the mochitests pass if you update your gstreamer to support Opus?

I'm wondering if the canPlayType filters can be improved to handle the lack of Opus support, the way mp4 files pass outside the gstreamer build. Is this just because of bug 760140 or are there occasions were we need to verify probably and not just truthiness?

I wrote the opus tests with the expectation that they should fail if opus support isn't available, but apparently I missed some more permissive tests. :)

[Cpearce-t (cpearce-t)]

We talked about this in Auckland, and we'd prefer to use our existing built-in backends for Ogg and WebM, since they've been fuzz tested and we know they're reliable.

I'm going to change our decoder creation code in bug 799344 to not use GStreamer for Ogg and WebM.

(And my GStreamer is whatever is the current up-to-date version in Ubuntu 12.04. I don't think we should rely on users having a newer version.)

[Riles (riles)]

(In reply to Chris Pearce (:cpearce) from comment #19)

> I'm going to change our decoder creation code in bug 799344 to not use
> GStreamer for Ogg and WebM.

Works for me. Thanks!

> (And my GStreamer is whatever is the current up-to-date version in Ubuntu
> 12.04. I don't think we should rely on users having a newer version.)

I don't think we should either. I was just trying to understand the origin of the failure you described.

[Henri Sivonen (hsivonen)]

(In reply to Ralph Giles (:rillian) from comment #18)
> Perhaps we should add some infrastructure to let us blacklist particular
> gstreamer elements, the way we do with plugins?

I think it’s more important to make really, really sure that the only GStreamer things that are whitelisted are:
 * MP4 demuxer
 * H.264 decoder
 * (LC-)AAC decoder
 * MP3 decoder only in the context of .mp3 container

I’d leave Firefox agnostic to which specific implementations of these live on the other side of GStreamer.

[Oibaf (oibaf)]

Maybe it was already discussed, but Mozilla was not interested in supporting only free codecs? Why the change to support also (software that can enable play of) patented codecs?

[Henri Sivonen (hsivonen)]

(In reply to Fabio from comment #22)
> Maybe it was already discussed, but Mozilla was not interested in supporting
> only free codecs? Why the change to support also (software that can enable
> play of) patented codecs?

https://brendaneich.com/2012/03/video-mobile-and-the-open-web/

[Gquigs+bugs (gquigs+bugs)]

(In reply to Chris Pearce (:cpearce) from comment #19)
> We talked about this in Auckland, and we'd prefer to use our existing
> built-in backends for Ogg and WebM, since they've been fuzz tested and we
> know they're reliable.

Maybe I'm misunderstanding this, but are there outstanding exploits that Mozilla found that haven't made it upstream yet to Ogg, WebM? If it is gStreamer specific, but not the codecs, then all someone would need to do is use H264 to exploit it.

> I'm going to change our decoder creation code in bug 799344 to not use
> GStreamer for Ogg and WebM.

One of the reasons I am interested in this bug is due to what seems to be much better video acceleration code in gStreamer vs Firefox. At least could it be be made an about:config option, pass all to gstreamer?

[Davemgarrett (davemgarrett)]

Having a pref to toggle on/off built-in codecs in addition to external codecs could be really useful at least for troubleshooting.

[antistress (antistress)]

As per comment 24, GStreamer 1.2 (planned for december 2012) should provide hardware acceleration
http://gstreamer.freedesktop.org/wiki/ReleasePlanning/RoadMap

[Cpearce-t (cpearce-t)]

(In reply to Bryan Quigley from comment #24)
> (In reply to Chris Pearce (:cpearce) from comment #19)
> > We talked about this in Auckland, and we'd prefer to use our existing
> > built-in backends for Ogg and WebM, since they've been fuzz tested and we
> > know they're reliable.
>
> Maybe I'm misunderstanding this, but are there outstanding exploits that
> Mozilla found that haven't made it upstream yet to Ogg, WebM? If it is
> gStreamer specific, but not the codecs, then all someone would need to do is
> use H264 to exploit it.

We apply several patches on top of our libvpx, and a couple on top of the Xiph Ogg libraries. I don't know if these have been fixed upstream yet. Possibly some or all of these patches have been upstreamed and our libraries are behind current-stable versions.

This decision also motivated by the fact that we know our built in decoders work reliably, and we know that the GStreamer backend has some problems; it fails our unit tests, so we know there are bugs either in GStreamer or in our use of it.

> > I'm going to change our decoder creation code in bug 799344 to not use
> > GStreamer for Ogg and WebM.
>
> One of the reasons I am interested in this bug is due to what seems to be
> much better video acceleration code in gStreamer vs Firefox. At least could
> it be be made an about:config option, pass all to gstreamer?

Sure, I will do this, it's a good idea.

[derf (tterribe)]

(In reply to Chris Pearce (:cpearce) from comment #27)
> We apply several patches on top of our libvpx, and a couple on top of the
> Xiph Ogg libraries. I don't know if these have been fixed upstream yet.
> Possibly some or all of these patches have been upstreamed and our libraries
> are behind current-stable versions.

For libvpx, I believe the only patch that isn't upstream or a backport of a commit that is upstream is the one dealing with the stdint.h types.

For libogg, we have one Solaris-specific patch for inttypes.h that is not upstream, and that's it.

For libvorbis, we have a Solaris-specific patch for alloca, a fix for bug 719612 (CVE-2012-0444), which is upstream as r18151, and a fix for bug 722924 (no CVE), which is upstream as r18166. Both of these were released in libvorbis-1.3.3.

For Tremor, we have a similar fix for bug 719612, which is upstream in r18152. Tremor was not affected by bug 722924. Xiph.Org does not publish releases for Tremor.

For libtheora, we currently carry four patches (bug 468275, bug 625773, bug 752139, and bug 752668), all of which are upstream (in r18219, r17780, r18031, and r18268, respectively). None of these bugs affect the most recent stable release (libtheora-1.1.1). We are actually using a more recent (unreleased) snapshot.

[Oibaf (oibaf)]

(In reply to Timothy B. Terriberry (:derf) from comment #28)
> For libvpx, I believe the only patch that isn't upstream or a backport of a
> commit that is upstream is the one dealing with the stdint.h types.

Is there a plan to update libvpx, currently at 0.9.5? Latest releases have some decoder speed improvements.

[Matthew Gregan (kinetik)]

(In reply to Fabio from comment #29)
> Is there a plan to update libvpx, currently at 0.9.5? Latest releases have
> some decoder speed improvements.

media/libvpx is based on 1.0.0 (see bug 730907), but README_MOZILLA and some other bits haven't been updated to reflect that.

[Cpearce-t (cpearce-t)]

(In reply to Chris Pearce (:cpearce) from comment #27)
> This decision also motivated by the fact that we know our built in decoders
> work reliably, and we know that the GStreamer backend has some problems; it
> fails our unit tests, so we know there are bugs either in GStreamer or in
> our use of it.

Some of the test failures with GStreamer were due to the test file having the wrong duration listed in its manifest, I fixed that in bug 803427.

> > > I'm going to change our decoder creation code in bug 799344 to not use
> > > GStreamer for Ogg and WebM.
> >
> > One of the reasons I am interested in this bug is due to what seems to be
> > much better video acceleration code in gStreamer vs Firefox. At least could
> > it be be made an about:config option, pass all to gstreamer?
>
> Sure, I will do this, it's a good idea.

I'm doing this in bug 803287.

[Cpearce-t (cpearce-t)]

(In reply to Chris Pearce (:cpearce) from comment #31)
> > > One of the reasons I am interested in this bug is due to what seems to be
> > > much better video acceleration code in gStreamer vs Firefox. At least could
> > > it be be made an about:config option, pass all to gstreamer?
> >
> > Sure, I will do this, it's a good idea.
>
> I'm doing this in bug 803287.

Just landed this change. I also renamed the pref to enable gstreamer, and nsHTMLMediaElement's gstreamer related functions, from .*H264.* to .*GStreamer.*, since we'll have other backends which also provide H.264 playback on other platforms.

[Pavlo Bohmat (bohm)]

Other platforms are not interested. Fix it for ubuntu.

[Mozaic (mozaic)]

@ Paul Bogmat : Reference needed

But, it will be great , if it will start with Ubuntu ...

[Unghost-mozilla-russia (unghost-mozilla-russia)]

(In reply to Ben Bucksch (:BenB) from comment #83)
> Correction:
> Testcase MPEG2 video, mimetype video/mpeg:
> http://www.bucksch.org/xfer/montee.mpg
> Testcase MPEG4 video, mimetype video/mp4:
> http://www.bucksch.org/xfer/walter-roehrl-short.mp4

FWIW, I can not play these files. However, I have a very old video card - intel 915.

[koda (vitto-giova)]

Multiplexing h264 streams in ts files is fairly common and recommended in many video streaming protocols.
What is the rationale in not supporting it? Moreover is the decision final?

[Ben-bucksch (ben-bucksch)]

Agreed, MPEG TS is definitely needed.

[Riles (riles)]

In general we try to limit the number of supported formats. Web developer refusal to support webm compelled us to add support for h.264 in mp4. I haven't heard a similar argument for h.264 in mpeg-ts.

Also, we're implementing the Media Source extensions (bug 778617) which make is straightforward to remux ts as mp4 in client-side script for playback in the <video> element. So this is a use case which can be addressed without native support.

If you think native support for mpeg-ts is important, the following steps are the best way to further that goal:

- Open a new bug specifically for it, rather than arguing either way in this bug.
- Provide a factual argument why this is important.
- Provide a patch implementing the new feature.

I can't speak for the media peers, but I don't expect the support decision to change unless one of the rationales I mentioned above changes.

[Chris Double (doublec)]

(In reply to Ralph Giles (:rillian) from comment #87)
> - Open a new bug specifically for it, rather than arguing either way in this
> bug.
> - Provide a factual argument why this is important.
> - Provide a patch implementing the new feature.

Starting a thread on mozilla.dev.media would be good too, outlining why you think it's useful and important. For example, this thread was started to discuss VP9:

https://groups.google.com/d/msg/mozilla.dev.media/iurA0-DJFoE/ObucKnJ3_ZQJ

[Justin-lebar+bug (justin-lebar+bug)]

> configure: error: gstreamer and gstreamer-plugins-base development packages are needed to build
> gstreamer backend. Install them or disable gstreamer support with --disable-gstreamer

Stupid question: Which Ubuntu packages do I need to install to get this to work?

I flailed about and finally got it to build, but I'm not sure exactly what I needed to install. I think it's a subset of

libgstreamer-plugins-base1.0-dev
libgstreamer-plugins-base0.10-dev
libgstreamer0.10-dev
libgstreamer1.0-dev

We should probably update the wiki with real package names for Ubuntu and other distros.

https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Linux_Prerequisites

[Chulee (chulee)]

I am using Ubuntu 12.10 but failed to build xpcshell test.
I resolved it now and narrow down to two packages:

libgstreamer0.10-dev
libgstreamer-plugins-base0.10-dev

[Philip P. (nucrap)]

@Chuck Lee, Justin Lebar: Ah, I think gstreamer1.0 was implemented so you should use gstreamer1.0 packages instead of the old gstreamer0.10 ones.

[Chulee (chulee)]

(In reply to nucrap from comment #91)
> @Chuck Lee, Justin Lebar: Ah, I think gstreamer1.0 was implemented so you
> should use gstreamer1.0 packages instead of the old gstreamer0.10 ones.

I installed libgstreamer-plugins-base1.0-dev and libgstreamer1.0-dev, but failed to pass the check.
Maybe its because the version check in configure.in is 0.10[1].

[1] https://mxr.mozilla.org/mozilla-central/source/configure.in#5780

[Philip P. (nucrap)]

Oh, sorry yeah it seems that gstreamer1.0 support is a work in progress: https://bugzilla.mozilla.org/show_bug.cgi?id=806917

[antistress (antistress)]

Interestingly there is a bug common to GNU/Linux & Firefox OS concerning Vimeo. See Bug 884558 for the case and its workaround

[Dylan Borg (borgdylan)]

Gstreameer was enabled in firefox 23 by default in mozilla's builds. I have tested it in a private build and it worked fine.

[Bryan Quigley (bryanquigley)]

Why it's not enabled yet in Ubuntu (https://bazaar.launchpad.net/~mozillateam/firefox/firefox-aurora.head/revision/1259#debian/changelog) :
"* Build with --disable-gstreamer for now, as this adds a hard dependency on
  the *old* gstreamer stack. Reenable this once Firefox has been dropped
  from the default install"

[Bryan Quigley (bryanquigley)]

Sorry, should add.. In Aurora PPA builds.

[Mar-castelluccio (mar-castelluccio)]

Weird, I thought the decision was still in progress: https://lists.ubuntu.com/archives/ubuntu-desktop/2013-June/004240.html

[Mozaic (mozaic)]

@ Dylan Borg (borgdylan): Are-you sure is enabled for Linux ?? https://bugzilla.mozilla.org/show_bug.cgi?id=794282 is for the next version: Firefox 24 and https://bugzilla.mozilla.org/show_bug.cgi?id=799318 don't have any target Milestone.

In Firefox 23, H264 could be read but only for user on Windows Vista, Seven or 8 Not for Mac OS or Linux:
> "Enabled DXVA2 on Windows Vista+ to accelerate H.264 video decoding " https://www.mozilla.org/en-US/firefox/23.0/releasenotes/

[Tuxist (jan-koester)]

If you want to build at with gstreamer support you can use my patches.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "control.in.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Mozaic (mozaic)]

In firefox 24, on Ubuntu 12.04 you could have this feauture:
write about:config in the url and find gstreamer.enabled=false and change it to true

[Id2ndR (id2ndr)]

Now that Firefox 26 is released in Ubuntu, gstreamer.enabled is set to false, but it seams that it still can decode h.264 (according to https://www.youtube.com/html5).

[Mozaic (mozaic)]

"Support for H.264 on Linux if the appropriate gstreamer plug-ins are installed"
https://www.mozilla.org/en-US/firefox/26.0/releasenotes/

I test in Virtual Machine with and in about:config gstreamer.enabled=true, now.

need gtremaer plugins-bad and plugin-ugly

[madbiologist (me-again)]

I can confirm comments #119 and #120 on Ubuntu 12.04.1 LTS only. When using Firefox 26 on Ubuntu 12.04.1 LTS with the gstreamer 0.10 plugins installed I get https://launchpadlibrarian.net/159672016/firefox26.png
When using Firefox 26 on Ubuntu 13.04 with the gstreamer 1.0 plugins installed, the top centre box (H.264) was red with an exclamation mark. Firefox support for gstreamer 1.0 is being worked on in https://bugzilla.mozilla.org/show_bug.cgi?id=806917

[gavenkoa (gavenkoa)]

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

[Id2ndR (id2ndr)]

The support of H.264 works after installing gstreamer0.10-plugins-bad gstreamer0.10-plugins-ungly gstreamer0.10-ffmpeg on Ubuntu saucy 13.10.

[Ajones-m (ajones-m)]

Using gstreamer on 24/25 will exhibit bug 884651 which is not fixed until Firefox 26. This is probably the most annoying of the bugs that blocked the pref on by default.

[Bryan Quigley (bryanquigley)]

Firefox 30.0 (approx June 6th) will have GStreamer 1.0 support (see https://bugzilla.mozilla.org/show_bug.cgi?id=806917).

Will we plan to enable by default (on trusty+ only) when it comes out?

[Mozaic (mozaic)]

@Bryan Quigley (bryanquigley): In Trusty, Gstreamer is the 0.10 not the 1.0
https://launchpad.net/ubuntu/trusty/+source/gstreamer0.10

[Oibaf (oibaf)]

There is 1.0 also since quantal:
https://launchpad.net/ubuntu/+source/gstreamer1.0

[j^ (j)]

gstreamer0.10-ffmpeg is no longer available in Trusty but Firefox is still build with gstreamer 0.10 support.

[Mozaic (mozaic)]

With Firefox 28 and Gstreamer1.0-plugins-bad in this website: i can't see H264/MP4

[Mozaic (mozaic)]

If install and use Aurora 30.0a2 (2014-04-04) on the same PC, i could no see again H264/MP4

In attachement, for information, libav-tools

[Mozaic (mozaic)]

@ j^ (j) : In 2011, there a fork in FFmpeg, some developper go away and create Libav.

Ubuntu/Debian maintener choose LibAv: http://forums.debian.net/viewtopic.php?f=6&t=73558
https://launchpad.net/libav/+packages
https://launchpad.net/libav
and there are an error message when you launch ffmpeg in terminal:
" *** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. "

Gstreamer could use the both now: http://gstreamer.freedesktop.org/releases/gst-libav/0.11.90.html
In 14.04 gstreamer1.0-libav make the job of gstreamer0.10-ffmpeg:
https://launchpad.net/ubuntu/trusty/i386/gstreamer0.10-ffmpeg
https://launchpad.net/ubuntu/+source/gst-libav1.0

FFmpeg could come back to Debian: http://www.phoronix.com/scan.php?page=news_item&px=MTYxNjA

The problem is that now with Firefox 28, we could not see H264 in Ubuntu 14.04, but we could do it in 12.04
If you want to test: http://www.quirksmode.org/html5/tests/video.html
I try use Aurora (Firefox 30 alpha) on Ubuntu 14.04, no H264 video. I check about:config and media.gstreamer.enabled is true
The same video on Ubuntu 12.04 work fine with Aurora

As i understand, when Firefox have <video> with H264, it use gstreamer who use gstreamer*-ffmpeg who use gstreamer-plugins-bad and gstreamer-plugins-ugly to read H264.
But with LibAv, how does it's work ?? I forget a plugin ?? Firefox use gtsreamer who use gst-libav1.0 and after i don't know.
I find one bug with LibAV in Firefox bugzilla, it's very short: https://bugzilla.mozilla.org/show_bug.cgi?id=801521

[Alan Pater (alan-pater)]

Using firefox-trunk from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/ and it now appears to be built with gstreamer1.0 support.

https://www.youtube.com/html5 shows it as supporting H.264

My understanding is that with this, everything is in place for when FF 30+ is stable.

Mozilla did not add gstreamer1.0 support to FF 28, just to FF 30.

[Mozaic (mozaic)]

@ Alan Pater (alan-pater): I confirm your affirmation: it work with https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/ (tested with dailymotion, vimeo, http://www.quirksmode.org/html5/tests/video.html )

I don't understand why with official Aurora (who is Firefox 30 alpha) from Mozilla (http://www.mozilla.org/en-US/firefox/channel/#aurora ) does not work.

[Mozaic (mozaic)]

Tested with Firefox's ubuntu ppa 32.0a1 (2014-05-08): work
Tested with Firefox's Mozilla 30.0 beta: fail, mp4 can't be played

Firefox' ubuntu ppa should have some modifications: one side mp4 could be launched in ppa's version on other side ppa's version could not use F10 to acess to menu bar like in Mozilla's version

[Philip P. (nucrap)]

Why is this marked as FIXED? Is it already the default in new firefox releases on Linux?

[Davemgarrett (davemgarrett)]

(In reply to nucrap from comment #100)
> Why is this marked as FIXED? Is it already the default in new firefox
> releases on Linux?

Yes. This bug enabled it in builds (meaning it was capable of being turned on at all) and bug 886181 enabled it by default for Firefox 26 and later. It's been on by default for 4 major releases now. The current extended support release (ESR) is based on Firefox 24, so that branch doesn't have it on by default yet, though it is available to be turned on via about:config. Generally, you should be using the normal current release, however.

If you have an issue with gstreamer in your installation, please file a new bug with specific information.

[Mozaic (mozaic)]

Tested on Ubuntu 14.04 with Firefox 30 from Canonical : we can see H264's video.
Bug Fixed for me

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.