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)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: manday, Unassigned)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
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.
Comment 1•11 years ago
|
||
As noted in that bug, this is effectively a dupe of bug 806917, which is going through yet another period of dormancy.
Updated•11 years ago
|
Component: Untriaged → Video/Audio
Product: Firefox → Core
Updated•11 years ago
|
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
No longer depends on: 973274
Depends on: 973274
Comment 5•10 years ago
|
||
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.
Comment 6•10 years ago
|
||
(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)
Any news about this ? I'd like to use nightly builds with gstreamer 1.0 :)
Comment 8•10 years ago
|
||
I think bug 1034957 is a blocking issue before we can enable gstreamer 1.x.
Depends on: 1034957
(In reply to Florian Bender from comment #6) > How's the guilt trip going? ;) Bug 973274.
Flags: needinfo?(edwin)
Comment 12•9 years ago
|
||
This should be done now, since Debian stable (Jessie) now ships GStreamer 1.0. No reason to use GStreamer 0.10 anymore.
Comment 13•9 years ago
|
||
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.
Comment 14•9 years ago
|
||
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 ?
Comment 15•9 years ago
|
||
but gstreamer 1.x and 0.10.x are parallel installable, so that isn't indicative of a problem.
Comment 16•9 years ago
|
||
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.
Comment 17•9 years ago
|
||
(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.
Comment 18•9 years ago
|
||
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
Comment 19•9 years ago
|
||
(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?).
Comment 20•9 years ago
|
||
(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.
Updated•9 years ago
|
Version: 25 Branch → Trunk
Comment 21•9 years ago
|
||
is there any more information about when the test machines will be updated?
Comment 22•9 years ago
|
||
Is that test machines issue still blocking this?
Comment 23•9 years ago
|
||
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 24•9 years ago
|
||
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)
Updated•9 years ago
|
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.
Comment 26•9 years ago
|
||
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
Comment 27•9 years ago
|
||
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)
Comment 28•9 years ago
|
||
Also, you need to change mach bootstrap accordingly (files in python/mozboot/mozboot).
Comment 30•9 years ago
|
||
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
Comment 32•9 years ago
|
||
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/
Comment 33•9 years ago
|
||
(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.
Comment 34•9 years ago
|
||
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.
Comment 35•9 years ago
|
||
(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.
Comment 36•9 years ago
|
||
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.
Comment 37•9 years ago
|
||
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)
Comment 38•9 years ago
|
||
I'm starting to think that maybe it's more a problem with libva and the radeon open source drivers...
Comment 39•9 years ago
|
||
(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
Comment 40•9 years ago
|
||
(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.
Comment 42•9 years ago
|
||
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.
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: Playback
Comment 43•9 years ago
|
||
So, did anyone manage to build it successfully on build servers?
Updated•9 years ago
|
Priority: -- → P5
Comment 44•9 years ago
|
||
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
Updated•9 years ago
|
Attachment #8672632 -
Flags: review?(ajones)
Comment 45•9 years ago
|
||
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.
Comment 46•9 years ago
|
||
(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?
Comment 47•9 years ago
|
||
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).
Updated•9 years ago
|
Attachment #8672632 -
Flags: review?(ajones) → review+
Comment 48•9 years ago
|
||
(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?
Comment 49•9 years ago
|
||
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.
Comment 50•9 years ago
|
||
gstreamer is going in bug 1234092
Status: NEW → RESOLVED
Closed: 11 years ago → 9 years ago
Resolution: --- → WONTFIX
Comment 51•9 years ago
|
||
That's completely silly! Should one go back to Flash?
Comment 52•9 years ago
|
||
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
Comment 53•9 years ago
|
||
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.
Comment 54•9 years ago
|
||
(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?
Comment 55•9 years ago
|
||
if you have the right packages installed. yes
You need to log in
before you can comment on or make changes to this bug.
Description
•