It is currently not possible to play mp3s with gstreamer without first researching which plugin is required. I therefore propose a new USE flag depending on gst-plugins-ugly, as it is apparently preferred for mp3 support at this time.
Should be disabled with a USE=bindist then imho, if added
You can already have mp3 support setting "lame" USE flag. What more gstreamer mp3 decoders are currently being packaged in gentoo? If there are more than lame, what would be the "best" one?
According to http://gstreamer.freedesktop.org/documentation/plugins.html the lame plugin is deprecated and for encoding only. Gentoo packages mad and ffmpeg mp3 decoders for gstreamer, with mad preferred by upstream at this time. There are currently flags for both of these but the problem is mp3parse from ugly is required for seek support, which isn't pulled in by anything.
It was more a question to gstreamer team since they better know what splitted ebuilds provides each plugin, for example, I don't know what ebuild is providing mp3parser (as I can see with "equery files gst-plugins-ugly", looks like it's not being provided by this package in gentoo)
Well, maybe you are referring to /usr/lib64/gstreamer-0.10/libgstmpegaudioparse.so ?
(In reply to comment #5) I suspect so. According to the docs mp3parse is an element of mpegaudioparse in ugly.
+ 28 Jan 2011; Pacho Ramos <pacho@gentoo.org> gst-plugins-meta-0.10-r5.ebuild: + Add mp3 USE flag per bug #351568. + I wasn't getting this as gst-plugins-ugly is in my systems due banshee and "dvd" USE flags
The handling of this seems wrong. gst-plugins-ugly package only provides this related to mp3: Plugin Details: Name: mpegaudioparse Description: MPEG-1 layer 1/2/3 audio stream elements Filename: /usr/lib64/gstreamer-0.10/libgstmpegaudioparse.so ... mp3parse: MPEG1 Audio Parser <--- this xingmux: MP3 Xing muxer A parser isn't enough to playback mp3. When I play a random mp3 with gstreamer, the following notable elements get used by playbin2: mp3parse mad audioconvert audioresample volume So you need also gst-plugins-mad for playing back MP3. That is, it's wrong to have separate USE flags for mad and mp3. mad is just the name of an open source mp3 decoder (media-libs/libmad, wrapped by gst-plugins-mad). Please remove the double USE flag for this. I'm unsure which should pull those in then. Also, gst-plugins-ugly dependency is rather bad for bindist, but hey, so is gst-plugins-mad. FYI, this is how I found out what elements get loaded by playing back mp3 with my set of plugins installed: GST_DEBUG=GST_ELEMENT_FACTORY:3 gst-launch-0.10 playbin2 uri=file:///path/to/mp3/file This is how I find out what package installed a certain element, mp3parse in this example: gst-inspect-0.10 mp3parse |grep Filename |awk '{ print $2 }' |xargs qfile -e
Thanks a lot :-D One last doubt: I think we should get rid of "mad" and "lame" USE flags in favor of "mp3" because lame gst-plugin is shown like "deprecated" and "mad" is preferred, then, I don't think we should pull lame plugin in with meta, do you agree?
mad is a MP3 decoder and lame is an encoder. gst-plugins-lame is not deprecated at all. However gst-plugins-lame lame plugin provides two elements - lame (rand marginal) and lamemp3enc (rank primary). The lame element is deprecated, but lamemp3enc is not, quite the contrary - it's the primary means to _encode_ mp3 with gstreamer. Further about the mp3 parsers situation after some consultation: While mp3parse should NOT be needed for seeking (mad supports seeking for some backwards compatibility reasons, usually a parser would be needed for it), it is still quite advisable to have it. Having it helps with or adds support for things like bitrate estimation, index building, notification, consistent handling of accurate seeks, reverse playback, etc. One other thing - once we have gst-plugins-bad-0.10.21 bumped, the mpegaudioparse element (will be provided by audioparsersbad plugin shipped by >=media-libs/gst-plugins-bad-0.10.21) is preferred over mp3parse. And once that is adjusted in -meta sometime after the bumps (we are working on those), at some point it may be gotten to a quality where it moves to yet another package (into gst-plugins-ugly or gst-plugins-good probably), and we need to keep an eye out for adjusting to that. Oh, and to avoid confusion, some terminology explanation - gstreamer provides plugins and elements. A plugin is basically like one of the .so files in /usr/lib/gstreamer-0.10. An element is one concrete element that goes into a pipeline. One plugin provides one or multiple elements. Sometimes there are elements that are named the same as some plugin, for example, lame plugin provides (deprecated) lame element and (primary) lamemp3enc element. And more confusingly: mpegaudioparse _plugin_ from gst-plugins-ugly provides the mp3parse element, while in the newer gst-plugins-bad-0.10.21 the audioparsersbad plugin will provide the mpegaudioparse _element_ which will be the preferred mp3 parser :)
+ 31 Jan 2011; Pacho Ramos <pacho@gentoo.org> gst-plugins-meta-0.10-r5.ebuild: + Merge 'mad' and 'mp3' USEs as both plugins are needed for proper mp3 parsing. + Thanks a lot to Leio for explanation. + For now I have left 'lame' USE flag as-is, but I though that maybe one option could be to add a 'encode' USE flag (another global one) and, then, if both (mp3 and encode) are set, lame plugin is pulled in. What do you think?
(In reply to comment #11) > + 31 Jan 2011; Pacho Ramos <pacho@gentoo.org> gst-plugins-meta-0.10-r5.ebuild: > + Merge 'mad' and 'mp3' USEs as both plugins are needed for proper mp3 > parsing. > + Thanks a lot to Leio for explanation. proper mp3 decoding or playback, not parsing, but not important :) I see you chose "mp3" as the universal USE flag to use. Not sure which is the better option myself, I guess we can leave it at that for now. My impression is that most things in-tree tend to use USE=mad for such stuff, but I may be mistaken. Not sure why there's two different global USE flags for this either, I doubt that things that can use mad have an alternative to choose when given USE="mp3 -mad". But that's something separate to ponder, and not on this bug :) > For now I have left 'lame' USE flag as-is, but I though that maybe one option > could be to add a 'encode' USE flag (another global one) and, then, if both > (mp3 and encode) are set, lame plugin is pulled in. > What do you think? I think I need to find the time to implement missing-plugins support. But maybe, until we have separate metas for encoders. Then encoding applications can depend on gst-plugins-meta[encode] maybe. I'd spend my time on the alternative metas or missing-plugins though, than tweaking this one
(In reply to comment #12) > proper mp3 decoding or playback, not parsing, but not important :) Ups > I see you chose "mp3" as the universal USE flag to use. Not sure which is the > better option myself, I guess we can leave it at that for now. My impression is > that most things in-tree tend to use USE=mad for such stuff, but I may be > mistaken. From my point of view "mp3" is known for most of people (for example, I have mp3 in my make.conf but not mad since I was not aware of what was "mad" until a few days) >Not sure why there's two different global USE flags for this either, > I doubt that things that can use mad have an alternative to choose when given > USE="mp3 -mad". But that's something separate to ponder, and not on this bug :) > > > For now I have left 'lame' USE flag as-is, but I though that maybe one option > > could be to add a 'encode' USE flag (another global one) and, then, if both > > (mp3 and encode) are set, lame plugin is pulled in. > > > What do you think? > > I think I need to find the time to implement missing-plugins support. > But maybe, until we have separate metas for encoders. Then encoding > applications can depend on gst-plugins-meta[encode] maybe. > I'd spend my time on the alternative metas or missing-plugins though, than > tweaking this one > OK, will leave this for now then. Thanks for your help
