Created attachment 409896 [details] gst-plugins-mpg123-1.4.5.ebuild Hello. Currently gstreamer in Gentoo can decode MP3 files only via media-libs/libmad through media-plugins/gst-plugins-mad. Upstream also offers MP3 decoding via media-sound/mpg123 through the appropriate plugin [0], which is a part of gst-plugins-bad collection. Here is a simple ebuild to add this plugin in Gentoo. [0]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-mpg123audiodec.html
Created attachment 409898 [details] gst-plugins-meta-1.0-r3.ebuild gst-plugins-meta ebuild needs some changes to allow users select their preferred MP3 plugin for gstreamer. I've used gst-plugins-meta-1.0-r3.ebuild as a reference and added 'mpg123' USE flag, which pulls gst-plugins-mpg123 instead of gst-plugins-libmad. gst-plugins-libmad is still the default option for MP3 support. However, a pair of USEs can be added to pull each plugin independently. I just went with the simplest non-breaking solution.
Created attachment 409900 [details] metadata.xml
These ebuilds are tested and work on my amd64 machine. I am able to playback MP3 files through gstreamer without libmad installed on my system.
Created attachment 409902 [details, diff] gst-plugins-meta-1.0-r3.ebuild.patch
Created attachment 409904 [details, diff] metadata.xml.patch
>can decode MP3 files only via ... No, there's also media-plugins/gst-plugins-libav
Also media-plugins/gst-plugins-lame MAY be able to decode.
(In reply to xpue from comment #6) > >can decode MP3 files only via ... > No, there's also media-plugins/gst-plugins-libav Thanks for clarifying this. I was looking only at the mp3 USE deps and this page: http://gstreamer.freedesktop.org/documentation/plugins.html
(In reply to xpue from comment #7) > Also media-plugins/gst-plugins-lame MAY be able to decode. Hmm, can you give more info how this can be achieved or point to the relevant piece of doc? Because looking at http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/gst-plugins-ugly-plugins-lamemp3enc.html it seems that lame plugin sits under GstAudioEncoder and does not have decoding abilities.
(In reply to Coacher from comment #8) > (In reply to xpue from comment #6) > > >can decode MP3 files only via ... > > No, there's also media-plugins/gst-plugins-libav > > Thanks for clarifying this. I was looking only at the mp3 USE deps and this > page: http://gstreamer.freedesktop.org/documentation/plugins.html JIC playback was tested via `gst-launch-1.0 -v filesrc location='test.mp3' ! mpegaudioparse ! mpg123audiodec ! pulsesink` command, so no libav was involved.
Created attachment 420950 [details] gst-plugins-mpg123-1.6.2.ebuild
Created attachment 420952 [details] gst-plugins-meta-1.6.1.ebuild Updated proposed ebuilds to 1.6.x.
Created attachment 440592 [details] gst-plugins-meta-1.6.3.ebuild
Created attachment 440594 [details] gst-plugins-mpg123-1.8.2.ebuild
Created attachment 440596 [details] metadata.xml
I disagree with library specific USE flags, they should be feature based. I think we should have USE=mp3 ensure the preferred mp3 decoder is installed, anything else can always be installed outside the meta when you want to fine-tune. gst-plugins-libav, gst-plugins-mpg123 and gst-plugins-mad should have software mp3 decoders. Lame is encoder only. The preferred by upstream mp3 decoder is the one with the highest rank for the element (gst-inspect-1.0 <element name>; Rank line), while supporting all the formats. mpg123 was promoted out of -bad into -ugly by now, but has rank MARGINAL. mad has rank SECONDARY. I think avdec_mp3 is MARGINAL as well. So the highest rank is for mad, which is what we pull in with USE=mp3. Yes, you probably get gst-plugins-libav pulled in for some other codec in your USE, and that in turn will support mp3 decoding as well, but it's not the preferred element for it - gst-plugins-mad is right now. But I don't want to make decisions about -meta, I always leave that up to others in gnome team (which maintains this meta as primary afaik). In any case, you can always disable USE=mp3 on -meta and emerge gst-plugins-mpg123 yourself. The attached gst-plugins-mpg123 ebuild is missing minimum version requirement for mpg123 and a depend on >=gst-plugins-base-$PV:1.0 as gstaudio is linked to.
(In reply to Mart Raudsepp from comment #16) > I disagree with library specific USE flags, they should be feature based. I > think we should have USE=mp3 ensure the preferred mp3 decoder is installed, > anything else can always be installed outside the meta when you want to > fine-tune. I don't mind having libmad as the default mp3 decoder, but please allow to switch to mpg123 _without_ disabling mp3 USE for gst-plugins-meta then. > The preferred by upstream mp3 decoder is the one with the highest rank for > the element (gst-inspect-1.0 <element name>; Rank line), while supporting > all the formats. > mpg123 was promoted out of -bad into -ugly by now, but has rank MARGINAL. > mad has rank SECONDARY. > I think avdec_mp3 is MARGINAL as well. > So the highest rank is for mad, which is what we pull in with USE=mp3. This rank AFAIU indicates how well gstreamer devs support one library vs another. If we look at underlying libraries, then libmad is abandoned since 2004, while mpg123 already has several releases in 2016. Clearly mpg123 has better support by its upstream. Also on my system libmad produces quiet, but detectable static noise, while mpg123 doesn't. I don't want to decode anything with libmad. > The attached gst-plugins-mpg123 ebuild is missing minimum version > requirement for mpg123 and a depend on >=gst-plugins-base-$PV:1.0 as > gstaudio is linked to. Minimum required mpg123 version is 1.13, which is removed from tree for some time now. I don't think it's necessary to require this obsolete minimum version. Thank you for noticing gstaudio, I'll update the ebuild accordingly.
(In reply to Coacher from comment #17) > > The attached gst-plugins-mpg123 ebuild is missing minimum version > > requirement for mpg123 and a depend on >=gst-plugins-base-$PV:1.0 as > > gstaudio is linked to. > Minimum required mpg123 version is 1.13, which is removed from tree for some > time now. I don't think it's necessary to require this obsolete minimum > version. It is good to note these down in ebuild as found in configure.ac (and filing upstream bug when adjusting it to be higher due to wrong upstream dependency). It's an unwritten (or maybe written somewhere) ebuild policy in gnome and gstreamer projects :) > Thank you for noticing gstaudio, I'll update the ebuild accordingly. -- Regarding which plugin to prefer, I intended to ask upstream what they think and why they have mad as higher rank if the upstream state is as you say, if I were to end up dealing with the -meta afterall :)
Created attachment 441102 [details] gst-plugins-mpg123-1.8.2.ebuild Added gst-plugins-base dependency, which provides the required libgstaudio.
Created attachment 441104 [details] gst-plugins-mpg123-1.8.2.ebuild Add minimum mpg123 version constraints.
Created attachment 441106 [details] gst-plugins-meta-1.6.3.ebuild I've taken into account points made in https://bugs.gentoo.org/show_bug.cgi?id=558444#c16 and https://bugs.gentoo.org/show_bug.cgi?id=588762#c3 and changed mp3 dependency block to mp3? ( >=media-plugins/gst-plugins-mad-${PV}:1.0[${MULTILIB_USEDEP}] >=media-plugins/gst-plugins-mpg123-${PV}:1.0[${MULTILIB_USEDEP}] ) This way libmad plugin is preferred as in upstream, but users won't have to disable mp3 USE to get mpg123 plugin used instead. Please note that I removed gst-plugins-ugly dependency from mp3 USE as it was required for mpegaudioparse (https://bugs.gentoo.org/show_bug.cgi?id=351568#c8), which was moved to gst-plugins-good since.
gstreamer team, please make this happen. It's been almost a year for such a simple addition.
Also note there's a trailing space in gst-plugins-meta/metadata.xml
Created attachment 441108 [details] gst-plugins-mpg123-1.8.2.ebuild Add minimum gst-plugins-base version constraints.
Put the -meta stuff where it belongs please. Bug 588762
Comment on attachment 441106 [details] gst-plugins-meta-1.6.3.ebuild (In reply to Mart Raudsepp from comment #25) > Put the -meta stuff where it belongs please. Bug 588762 Done: https://bugs.gentoo.org/show_bug.cgi?id=588762#c5
Pushed with 1.8.3 bumps in tree.
(In reply to Gilles Dartiguelongue from comment #27) > Pushed with 1.8.3 bumps in tree. Thanks, but you've missed [1] gst-plugin-base dependency. The attached ebuild has this dependency. It's required for libgstaudio. $ readelf -d /usr/lib/gstreamer-1.0/libgstmpg123.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libgstaudio-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgstbase-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgstreamer-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libmpg123.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] Please fix. Or should I open another bug? [1]: https://github.com/gentoo/gentoo/commit/f0f35736249a00b3785ac87457d37bd9f859afcb
It is not missing. The plugin depends on gst-plugins-bad which depends on base.
Err -ugly in this case but it's the same for all plugins. They depend on their pack to make dependencies simpler to manager.
(In reply to Gilles Dartiguelongue from comment #29) > It is not missing. The plugin depends on gst-plugins-bad which depends on > base. I see, thank you for the explanation.
