Closed Bug 947287 Opened 11 years ago Closed 9 years ago

Build against GStreamer 1.x by default on Linux

Categories

(Core :: Audio/Video: Playback, defect, P5)

Product:
Core
Component:
Audio/Video: Playback
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: manday, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

Diable_gstreamer.patch
5.24 KB, patch
ajones
: review+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332




Expected results:

As by https://bugs.gentoo.org/show_bug.cgi?id=493456 I'd like to ask if it is possible to provide a binary version of firefox which links against the current stable gstreamer release in order to more fully support HTML5 video.
As noted in that bug, this is effectively a dupe of bug 806917, which is going through yet another period of dormancy.
Depends on: 806917
Component: Untriaged → Video/Audio
Product: Firefox → Core
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
I do not see how the capability to support GST 1.0 is related to actually prodividing a binary which supports GST 1.0 (other than that it depends on said capability). Bug 806917 is closed, yet, firefox-bin-29.0.1 does not use gstreamer.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
GStreamer 0.10 is getting to the point in its lifecycle that we should be looking at building against 1.x by default.

IIRC Alessandro had tests passing for him locally, so in theory (hah!) we're only blocked on infrastructure here. I'll make sad faces at releng and see if anybody there can help.
Status: UNCONFIRMED → NEW
Depends on: 973274
Ever confirmed: true
Summary: Binary link against gstreamer → Build against GStreamer 1.x by default on Linux
I confirm I had all the tests passing at some point, last I tried was about a month ago. If we can get the infra sorted out I'll be happy to help make the tests pass.
(In reply to Edwin Flores [:eflores] [:edwin] from comment #4)
> […]
> only blocked on infrastructure here. I'll make sad faces at releng and see
> if anybody there can help.

How's the guilt trip going? ;)
Flags: needinfo?(edwin)
Depends on: 1024125
Any news about this ?
I'd like to use nightly builds with gstreamer 1.0 :)
I think bug 1034957 is a blocking issue before we can enable gstreamer 1.x.
Depends on: 1034957
There doesn't seem to be anything blocking it now :)
(In reply to Florian Bender from comment #6)
> How's the guilt trip going? ;)

Bug 973274.
Flags: needinfo?(edwin)
This should be done now, since Debian stable (Jessie) now ships GStreamer 1.0. No reason to use GStreamer 0.10 anymore.
Probably someone who is interested to change that in default builds should collect the GStreamer version availability in Linux distros out there and see if there are still "GStreamer 0.10-only" distros which are worth to be supported.
There are tools who still need gstreamer 0.10. For example, distributions providing xfce 4.10/4.12. Audio mixer tool still need gstreamer 0.10 plugins.

For example, on my archlinux powered computer with xfce :

[fred@fredo-arch ~]$ yaourt -Rcs gstreamer0.10-plugins
checking dependencies...

Packages (15) gstreamer0.10-bad-0.10.23-9  gstreamer0.10-good-0.10.31-6
              ladspa-1.13-5  libcdaudio-0.99.12-7  libdc1394-2.2.3-1
              libkeybinder2-0.3.0-2  liblrdf-0.5.0-2  libmpcdec-1.2.6-4
              musicbrainz-2.1.5-6  xfce4-mixer-4.11.0-2
              gstreamer0.10-bad-plugins-0.10.23-9
              gstreamer0.10-base-plugins-0.10.36-3
              gstreamer0.10-ffmpeg-0.10.13-2
              gstreamer0.10-good-plugins-0.10.31-6
              gstreamer0.10-ugly-plugins-0.10.19-14

Total Removed Size:  20.59 MiB

:: Do you want to remove these packages? [Y/n]

Do not underestimate environment and tools needing gstreamer 0.10. There are more spread than you think. What about Clementine Music Player ?
but gstreamer 1.x and 0.10.x are parallel installable, so that isn't indicative of a problem.
Even if 0.10 is packaged, 1.0 is packaged as well in most distros. Firefox has nothing to do with what some other tools need. As long as 1.0 is widely available - it should use it.

It's a question of practicality. Even if some few distros still use GStreamer 0.10 only, but the vast majority already provide GStreamer 1.0 (which is the case), there is no need to support 0.10 anymore, because they can be mutually exclusive. For instance Debian stable doesn't ship gstreamer0.10-ffmpeg at all at this point. So GStreamer support in Firefox isn't be usable there. Either Firefox should support both if you really worry about some minority, or chose default which is most common.
(In reply to Johnny Robeson from comment #15)
> but gstreamer 1.x and 0.10.x are parallel installable, so that isn't
> indicative of a problem.

Of course. It is the case on my computer. I was just adding some informations. 

(In reply to Shmerl from comment #16)
> Even if 0.10 is packaged, 1.0 is packaged as well in most distros. Firefox
> has nothing to do with what some other tools need. As long as 1.0 is widely
> available - it should use it.
> 
> It's a question of practicality. Even if some few distros still use

I agree.

> GStreamer 0.10 only, but the vast majority already provide GStreamer 1.0
> (which is the case), there is no need to support 0.10 anymore, because they
> can be mutually exclusive. For instance Debian stable doesn't ship
> gstreamer0.10-ffmpeg at all at this point. So GStreamer support in Firefox
> isn't be usable there. Either Firefox should support both if you really
> worry about some minority, or chose default which is most common.

A "sniffing" will be required to use the right version of gstreamer. On distributions proposing and using both, it could be problematic.
Mint >=16 - gstreamer 1.2
Ububtu >=13.04 - gstreamer 1.2
Debian 8 - gstreamer 1.4
openSUSE >=13.2 - gstreamer 1.4
Fedora >=20 - gstreamer 1.2
Mageia 4.1 - gstreamer 1.2
!!! CentOS 6 - gstreamer 0.10
CentOS 7.1 - gstreamer 1.0
Arch Linux - gstreamer 1.4
elementary OS 0.3 - gstreamer 1.2
!!! RHEL-6.6 - gstreamer0.10
RHEL-7.1 - gstreamer 1.0
PCLinuxOS 2014.12 - gstreamer 0.10
!!! Slackware 14.1 - gstreamer 0.10
Slackware current - gstreamer 1.4
Gentoo - gstreamer 0.10/1.2/1.4 ebuild
ROSA R4 - gstreamer 1.2
FreeBSD - gstreamer 0.10/1.2/1.4 ports

as we can see, some LTS distros use gstreamer 0.10.
in a question of practicality, firefox can keep suppor both gst versions. mozilla binary builds with 1.x, and distros which want use 

> Either Firefox should support both if you really worry about some minority, or chose default which is most common.

yes. distros which use gstreamer 0.10 can build firefox pkg themselves (for example redhad/FC/CentOS make their own)

by the way. gentoo portage shows what gstreamer 1.2 is stable for alpha, amd64, arm, hppa, ia64, ppc, ppc64, sparc, x86 arch
(In reply to Shmerl from comment #12)
> This should be done now, since Debian stable (Jessie) now ships GStreamer
> 1.0. No reason to use GStreamer 0.10 anymore.

There is one: the build machines don't have gstreamer 1.0 available, and the test machines don't either. So we can't build it, and even if we could, we can't test it. That's what's blocking this, more than anything else. Short of making the necessary changes on the test slaves (which may or may not mean upgrading the base distro (I'd say it should be not)), one way forward would be runtime support for both gstreamer versions, possibly without even requiring any at build time (how much of the headers do we need anyways?).
(In reply to Mike Hommey [:glandium] from comment #19)
> There is one: the build machines don't have gstreamer 1.0 available, and the
> test machines don't either.

The build machines have the necessary files as of bug 973274.  It's the test machines that are currently blocking this.  According to bug 973274 comment 37 this should be fixes as part of a planned OS upgrade to the test machines this year.
Blocks: 1160726
Version: 25 Branch → Trunk
is there any more information about when the test machines will be updated?
Is that test machines issue still blocking this?
My understanding is the test servers don't need it because we don't actually have any gstreamer tests for 0.10 or 1.0.   So we might as well go ahead and turn it on if the headers are available on the build servers.
Attachment #8638942 - Flags: review?(cajbir.bugzilla)
Comment on attachment 8638942 [details] [diff] [review]
0001-Enable-gstreamer1.0-as-the-default-gstreamer.patch

Passing this to Anthony to decide who is a suitable reviewer.
Attachment #8638942 - Flags: review?(cajbir.bugzilla) → review?(ajones)
Attachment #8638942 - Flags: review?(ajones) → review+
(In reply to Bryan Quigley from comment #23)
> My understanding is the test servers don't need it because we don't actually
> have any gstreamer tests for 0.10 or 1.0.   So we might as well go ahead and
> turn it on if the headers are available on the build servers.

Try it on try.
Seems the necessary headers are not on the try servers (or not set up correctly).   Does this mean 973274 should be reopened or would try need it's own bug? 

Relevant message: 06:54:15     INFO -  checking for gstreamer-1.0 >= 1.0
06:54:15     INFO -                        gstreamer-app-1.0
06:54:15     INFO -                        gstreamer-plugins-base-1.0... configure: error: gstreamer and gstreamer-plugins-base development packages are needed to build gstreamer backend. Install them or disable gstreamer support with --disable-gstreamer
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=a929122a1129
You need to apply something like:
https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=973274&attachment=8576674

(but there are more manifests to change)
Also, you need to change mach bootstrap accordingly (files in python/mozboot/mozboot).
Blocks: 1187047
Depends on: 1112371
I added the obvious manifest and switch mozboot over to gstreamer1 (or whatever it was called in distro).  I'm really not sure if this is all that is needed, but figured I might as well not keep this just to myself.  Anyone want to Try.. on try?
Attachment #8638942 - Attachment is obsolete: true
Blocks: 894372
I assume compiling Firefox isn't an easy task, but I'd gladly test it if there was a Copr repo with this patch (there is a Copr repo for gstreamer 1.0, but it is 14 months old).

https://copr.fedoraproject.org/
(In reply to romain.failliot from comment #32)
Fedoras Firefox build has GStreamer 1.0 enabled by default:
http://pkgs.fedoraproject.org/cgit/firefox.git/tree/firefox.spec#n30

Also, the patch above doesn't build on Mozillas infrastructure yet. AFAICS, the build machine still installed the wrong packages:

19:19:25     INFO -   gstreamer-devel         i686   0.10.29-1.el6       centos6               169 k
19:19:25     INFO -   gstreamer-plugins-base-devel
19:19:25     INFO -                           i686   0.10.29-1.el6       centos6                85 k
[...]
19:19:25     INFO -   gstreamer               i686   0.10.29-1.el6       centos6               753 k
19:19:25     INFO -   gstreamer               x86_64 0.10.29-1.el6       centos6               764 k
19:19:25     INFO -   gstreamer-plugins-base  i686   0.10.29-1.el6       centos6               929 k
19:19:25     INFO -   gstreamer-plugins-base  x86_64 0.10.29-1.el6       centos6               942 k
19:19:25     INFO -   gstreamer-tools         x86_64 0.10.29-1.el6       centos6                23 k

Otoh, the gstreamer-headers.tar.xz was successfully fetched and unpacked.
Or, re-reading the discussion from bug 973274, the configure-checks probably have to be relaxed, to allow compiling with just the gstreamer-headers and no installed package.
(In reply to Johannes Pfrang [:johnp] from comment #34)
> Or, re-reading the discussion from bug 973274, the configure-checks probably
> have to be relaxed, to allow compiling with just the gstreamer-headers and
> no installed package.

gstreamer is enabled, but I don't see the version 1.0 defined anywhere. And one thing for sure, Firefox has trouble recognizing va_api libs and drivers (I don't remember the error line precisely, but it is quite self-explanatory when running Firefox in command line).

I'm compiling the 40.0.2 sources with the patch right now, we'll see how it goes.
Yea, the issue (AFAICT) is just to hook up the headers in the proper way - Mozilla's build servers don't have an available gstreamer1.0 package.  I was looking at using https://github.com/mozilla/build-environments to help debug this, but I ran out of space (docker and btrfs wasn't fun) and time.
Just finished the compilation and I still have the same error messages when running `./mach run`:

ATTENTION: default value of option force_s3tc_enable overridden by environment.
libva info: VA-API version 0.37.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 0.37.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 0.37.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.37.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
I'm starting to think that maybe it's more a problem with libva and the radeon open source drivers...
(In reply to romain.failliot from comment #37)
> Just finished the compilation and I still have the same error messages when
> running `./mach run`:
> 
> ATTENTION: default value of option force_s3tc_enable overridden by
> environment.
> libva info: VA-API version 0.37.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
> libva info: va_openDriver() returns -1
> libva info: VA-API version 0.37.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
> libva info: va_openDriver() returns -1
> libva info: VA-API version 0.37.0
> libva info: va_getDriverName() returns -1
> libva error: va_getDriverName() failed with unknown libva
> error,driver_name=(null)
> libva info: VA-API version 0.37.0
> libva info: va_getDriverName() returns -1
> libva error: va_getDriverName() failed with unknown libva
> error,driver_name=(null)

That looks like this issue: https://bugs.launchpad.net/ubuntu/trusty/+source/vdpau-video/+bug/964040

On Ubuntu 14.04 at least, you can work around it by setting the environment variable LIBVA_DRIVER_NAME=vdpau
(In reply to Mathew Hodson from comment #39)
> That looks like this issue:
> https://bugs.launchpad.net/ubuntu/trusty/+source/vdpau-video/+bug/964040
> 
> On Ubuntu 14.04 at least, you can work around it by setting the environment
> variable LIBVA_DRIVER_NAME=vdpau

It does work, but I don't see much improvements actually... Well I hope everything will be better once it'll be stabilized (firefox with gstreamer 1.0, Fedora properly setting the vdpau driver... and everything else related to video in Linux which is far from being easy)
(In reply to romain.failliot from comment #40)
> It does work, but I don't see much improvements actually... Well I hope
> everything will be better once it'll be stabilized (firefox with gstreamer
> 1.0, Fedora properly setting the vdpau driver... and everything else related
> to video in Linux which is far from being easy)

This is off-topic for this bug.
There are two things that prevent the build from happening correctly with patch attached to this bug:
- configure wants a pkg-config file for gstreamer, and the tooltool package doesn't provide one. If it did provide one, its path would also not be searched for, so shipping one wouldn't be enough, something like what is done for gtk in build/unix/mozconfig.gtk would be necessary. Alternatively, allowing GSTREAMER_CFLAGS to be set without using pkg-config, and setting it in the right mozconfigs would work.
- configure.in wants to be able to link gstvideo, but it's only really used for gstreamer on mac (which I don't even know if that actually works) because toolkit/library/moz.build wants to add GSTREAMER_LIBS there.
No longer blocks: 1187047
Component: Audio/Video → Audio/Video: Playback
So, did anyone manage to build it successfully on build servers?
Per ffmpeg being turned on in Linux I'm not sure we care about enabling gst1.0 on Mozilla's build servers.

This patch disables gstreamer0.10, and does make gstreamer1.0 the default gstreamer if --enable-gstreamer is passed.
Attachment #8643491 - Attachment is obsolete: true
Attachment #8672632 - Flags: review?(ajones)
Enabling gstreamer 1.0 on build servers can make next release of Firefox usable for video / audio with relevant codecs, while ffmpeg only landed in nightly and will arrive in releases much later. So I'd say until ffmpeg will appear in release there is a practical benefit in enabling gstreamer 1.0 on the builds machines.
(In reply to Bryan Quigley from comment #44)
> Per ffmpeg being turned on in Linux I'm not sure we care about enabling
> gst1.0 on Mozilla's build servers.

Where's the bug about ffmpeg?
Bug for my latest slave request_ https://bugzilla.mozilla.org/show_bug.cgi?id=1212916 where I found about ffmpeg bug https://bugzilla.mozilla.org/show_bug.cgi?id=1207429

Just "enabling" it on the build servers won't enable it in the builds.  AFAIU that would have to follow the normal process (or be expatiated like they might do for ffmpeg).
Attachment #8672632 - Flags: review?(ajones) → review+
(In reply to Bryan Quigley from comment #47)
> Just "enabling" it on the build servers won't enable it in the builds. 
> AFAIU that would have to follow the normal process (or be expatiated like
> they might do for ffmpeg).

Should there be some separate bug open for actually enabling it in the release builds?
Thanks Anthony Jones for committing that patch.

@Shmerl
It would need to get enabled in nightly first, then you can assign reviews to the patch to move it to aurora, beta, etc.  I'm not planning on working on this given that ffmpeg is now enabled on nightly and might be pushed to aurora as well.  If it makes it to Aurora, that means ~ 6-12 weeks until it's in a released version.
gstreamer is going in bug 1234092
Status: NEW → RESOLVED
Closed: 11 years ago → 9 years ago
Resolution: --- → WONTFIX
That's completely silly! Should one go back to Flash?
gstreamer is unused as of version 44. It's only used in 43 to play mp3. We have no need for gstreamer anymore as we have better alternatives.

and no, you don't need flash
OK, so I've de-dupped bug 1190612, which is about the impossibility to play Vimeo videos under Debian/unstable. The status of this bug 1190612 should be revised, taking into account these better alternatives.
(In reply to Jean-Yves Avenard [:jya] from comment #52)
> gstreamer is unused as of version 44. It's only used in 43 to play mp3. We
> have no need for gstreamer anymore as we have better alternatives.

Thanks for clarifying. So ESR45 will be able to play MP4 (and more) even on distros that ship GStreamer 1.0, right?
if you have the right packages installed. yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: