Currently, USE="aac" emerge gst-plugins-meta has DEPEND+="gst-plugins-faad", but this does not supply aac/mp4 support to all gstreamer programs. For example, sound-juicer requires gst-plugins-faac, having gst-plugins-faad has no effect. Currently, no combination of USE on gst-plugins-meta will pull gst-plugins-faac. Either USE="aac" emerge gst-plugins-meta should DEPEND on both gst-plugins-faac and gst-plugins-faad or USE="aac" emerge sound-juicer should pull gst-plugins-faac Reproducible: Always
The ripping profiles used by sound-juicer et al. are actually set in either gnome-extra/gnome-media-2 (in gnome-2) or in media-libs/libgnome-media-profiles-3 (in gnome-3). I believe it would make sense for gnome-media and libgnome-media-profiles to depend on the gstreamer plugins that are required for the default audio profiles to work. The only question is whether the dependency should be controlled by USE flags, and if so, what flags should be used. I am leaning towards an obligatory dependency, or at least to enabled-by-default (profiles that are installed by default should work out of the box by default). Gnome team, opinions?
I would still go for "optional" solution. Personally, I don't have "aac" stuff installed as I never use it. Also, looks like (at least on Gnome2), sound-juicer doesn't even offer me to rip using aac if plugin is not installed
Ah, the report is framed the way that it is because the sound-juicer ebuild has: ewarn "If ${PN} does not rip to some music format, please check your" ewarn "USE flags on media-plugins/gst-plugins-meta" Having codec support enabled/disabled based on USE would be consistent with other packages.
Yeah, well we can't offer true support like this because it would be hell to maintain. The real fix, if it ever comes, will be through #241674 or something through packagekit.
Added aac, flac, mp3, speex, twolame, and vorbis USE flags to libgnome-media-profiles and gnome-media to pull in the correct gstreamer plugins. > 03 Nov 2011; Alexandre Rostovtsev <tetromino@gentoo.org> > libgnome-media-profiles-3.0.0.ebuild, metadata.xml: > Add USE flags to pull in the correct encoders used by the audio profiles > installed by this ebuild (bug #389119, thanks to James Broadhead > <jamesbroadhead@gmail.com> for reporting). No revbump; there is no change to > the files installed by this ebuild. > 03 Nov 2011; Alexandre Rostovtsev <tetromino@gentoo.org> > gnome-media-2.32.0-r1.ebuild, metadata.xml: > Add USE flags to pull in the correct encoders used by the audio profiles > installed by this ebuild (bug #389119, thanks to James Broadhead > <jamesbroadhead@gmail.com> for reporting). No revbump; there is no change to > the files installed by this ebuild. > 03 Nov 2011; Alexandre Rostovtsev <tetromino@gentoo.org> > sound-juicer-2.32.0.ebuild, sound-juicer-2.32.0-r1.ebuild, > sound-juicer-2.99.0_pre20111001.ebuild: > Update pkg_postinst message for bug #389119 (thanks to James Broadhead > <jamesbroadhead@gmail.com> for reporting).
(In reply to comment #5) > Added aac, flac, mp3, speex, twolame, and vorbis USE flags to > libgnome-media-profiles and gnome-media to pull in the correct gstreamer > plugins. > Why were they finally added to gnome-media instead of gst-plugins-meta? (Looks a bit like duplicate things for me :/)
(In reply to comment #6) > Why were they finally added to gnome-media instead of gst-plugins-meta? (Looks > a bit like duplicate things for me :/) The flags were added to gnome-media because gnome-media installs gnome-audio-profiles.schemas and so needs to pull in the plugins that are used in the audio profiles specified in the schemas file. And gnome-media[aac] depends on specific plugins instead of gst-plugins-meta[aac] because of a difference in semantics: gst-plugins-meta[aac] installs the plugins that are needed for a typical gstreamer-based media player to play AAC, while gnome-media[aac] installs the plugins that are needed to encode AAC using the specific gstreamer pipeline given that is given in gnome-audio-profiles.schemas. There are probably other reasonable ways of encoding an AAC file using gstreamer, so changing gst-plugins-meta to match gnome-media does not make sense.
That makes sense. Please fix the ewarn for sound-juicer to match. (A hyper-diligent QA'er would also grep for similar messages in other ebuilds) :)
(In reply to comment #7) > (In reply to comment #6) > > Why were they finally added to gnome-media instead of gst-plugins-meta? (Looks > > a bit like duplicate things for me :/) > > The flags were added to gnome-media because gnome-media installs > gnome-audio-profiles.schemas and so needs to pull in the plugins that are used > in the audio profiles specified in the schemas file. > > And gnome-media[aac] depends on specific plugins instead of > gst-plugins-meta[aac] because of a difference in semantics: > gst-plugins-meta[aac] installs the plugins that are needed for a typical > gstreamer-based media player to play AAC, while gnome-media[aac] installs the > plugins that are needed to encode AAC using the specific gstreamer pipeline > given that is given in gnome-audio-profiles.schemas. There are probably other > reasonable ways of encoding an AAC file using gstreamer, so changing > gst-plugins-meta to match gnome-media does not make sense. But, will all encoders use gnome-media to encode files? Wouldn't be better to add a "encode" USE flag that would pull in respective encoders for mp3, aac... and, then, use it for pulling encoders and decoders when needed by any gstreamed based app (not relying on gnome-media)?
(In reply to comment #9) > But, will all encoders use gnome-media to encode files? Wouldn't be better to > add a "encode" USE flag that would pull in respective encoders for mp3, aac... > and, then, use it for pulling encoders and decoders when needed by any > gstreamed based app (not relying on gnome-media)? Pacho, encoding and playback with gstreamer are very different problem areas. With media players that use gstreamer's playbin2, you just need *some* plugin that plays a file format. Doesn't matter which plugin. As long as at least one plugin that can play AAC is installed, gstreamer's playbin2 will detect that AAC files are playable and will load something that can play them. This is why gstreamer-based media players often don't check for dependencies for playing desired formats, and this is why gst-plugins-meta was created. With encoding, there is generally no auto-detection. The application's author provides a specific pipeline, and you need the *exact* set of plugins that are used in that pipeline. PluginS, because there is more than one of them. Because encoding pipelines contain multiple elements, which can (and often do!) belong to multiple Gentoo packages. (For example, gnome-media uses the following pipeline to encode mp3: "lamemp3enc name=enc target=0 quality=6 ! xingmux ! id3v2mux". That means it requires gst-plugins-lame (for lamemp3enc), gst-plugins-ugly (for xingmux), and gst-plugins-taglib (for id3v2mux). For video encoding, the number of stages, and the number of required plugins, is significantly greater.) And encoding application's demands are not necessarily predictable. There are different ways you can choose to encode and mux what you would think of as the same format. gst-plugins-meta works very well for gstreamer playback. It works reasonably as an end-user tool for power users who are writing a custom pipeline for a script and find they are missing a commonly used plugin. It does not really work as a dependency for packages that do encoding.
Ah you are true, thanks a lot for the full explanation :-)
