From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21891 invoked by uid 1002); 25 Sep 2003 18:18:06 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31002 invoked from network); 25 Sep 2003 18:18:05 -0000 From: foser To: gentoo-dev@gentoo.org Content-Type: text/plain Message-Id: <1064513870.7748.178.camel@rivendell> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 25 Sep 2003 20:17:50 +0200 Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] Gstreamer plugins setup X-Archives-Salt: 25d72c3c-1676-4595-aaa2-c959f0714621 X-Archives-Hash: eec3f02673ddcbf8ebaff91892974e5b Hi, as you might have noticed if you use a ~ profile there have been some pretty big changes to the gstreamer plugins setup. Some of the details of working with this are still under discussion, we would like to see some feedback on this. Gstreamer (http://www.gstreamer.net) is a pluggable media framework, which is since the 0.6 series officially part of the GNOME Desktop. It consists of a small core library and a set of plug-ins which put together in pipeline can do tasks ranging from ripping cd's, playing your music library to video manipulation and more to come. The Gentoo GNOME team has always been an avid fan of this promising framework, although it had and has it's problems. These issues have become more apparent now several gstreamer using applications have matured and are used by a wider audience. The plugins provided by gstreamer besides the basic ones are provided by the gst-plugins package, which contains a wide variety of plug-ins with their respective dependencies. Some of these plug-ins might not even be fully functional (anymore) or even broken. We used to provide these plug-ins as one big package, resulting in a lot of dependencies and always giving the GNOME team trouble in one way or the other. Especially the dependencies list was an annoyance, we couldn't possibly cover every plug-in with a USE flag and the ones covered by a USE flag could be broken or generate a whole list of unnecessary gnome dependencies. I personally contribute about 75% of the problems with gnome-meta emerges in this period to problems with gst-plugin dependencies (rough estimate). It was decided that we would split up the gst-plugins package into separate plug-ins, which was done and added to the portage tree when gstreamer 0.6.3 hit the shelves. This allowed us finer control over plug-ins and only add plug-ins proven to be working and stable and all this for every arch if needed. From my personal experience i can say i find gstreamer more stable now a whole set of possible broken plug-ins are not around anymore, a somewhat unexpected plus of the split-up. Every single gstreamer using application can also pull in only the dependencies needed. This is our next 'problem'. Because gstreamer is pluggable, not every plugin possible to use needs to be around for an application to work. Let's take for example sound-juicer, a cd-ripper that can output to wave, ogg, mp3 or flac format at this time. The wave plugin comes with the default gst-plugins package and for oggvorbis we have a USE flag, but for flac and mp3 we don't. Possible solutions for flac and mp3 (in this case) : 1. add as non-optional dependencies pros : * you get all possible functionality cons : * you get unneeded dependencies for a lot of users 2. make local USE flags pros : * total control cons : * even more USE flags (!) and it's a jungle already * lot of flags with packages not as clear-cut as this this case (see down) * may be uncertain what exact plug-ins could be used 3. don't add deps beyond basic ones needed to run pros : * no unneeded deps/functionality cons : * people might miss functionality without knowing it or knowing how to add it * not very gentoo-ish (?) * not all plug-in names are very explanatory There are some more things to consider : sound-juicer is a pretty clear-cut case as to what plug-ins it can use and what is needed, in a video player the number of possible plugins and (local) USE flags -as in solution (2)- may skyrocket. And gstreamer has auto-plugging ability, where with a given input media and given output sink it creates the pipeline itself selecting plug-ins as needed. There is currently no application in portage that uses this auto-plugging, but it would result in an enormous dependencies list if we go with (2), not to mention (1) defying much of the purpose of splitting it up. Option (1) is only there for completeness sake, i think it's pretty bad to solve it like that (although, the current latest sound-juicer ebuild is set-up like that because of some mis-communication / information). Option (2) i don't like because of it's over-complicating things with all sorts of USE flags and it may be very hard to exactly define plug-ins that could be used with a certain package. Leaves us with option (3), my preferred choice. We provide the user just with the basic plug-ins needed to get up and running. For example a video output plugin for a video player, cd rip (paranoia) plugin for sound-juicer, etc. The other plug-ins are up to the user to add as needed. This might be a little difficult, because it might not be very clear as to what plug-in provides what; the plug-in names might not be all that descriptive (i try to make the ebuild description more clear in those cases) and there might be more plug-ins doing one and the same thing where only one can be used by a certain application (hypothetical situation). To make this easier the GNOME team is planning to provide a web page where plug-in status and exact use of certain plug-ins are explained possibly in combination with application specific information. Users can select on basis of that page what they need. This may sound a little non-gentooish maybe, but i definitely think this is the best solution. Also we could add a series of USE-flagged dependencies to the gst-plugins package, where known working and stable plug-ins get installed providing a solid basis for a lot of applications. As said in the current gst-plugins ebuild, a lot of users should hardly ever feel the need to install extra plug-ins. So i would like to get some opinions on this, what would be the preferred way to have gstreamer applications define their plug-in dependencies ? Any suggestions/improvements/questions ? - foser PS. Not all possible plug-ins have been added this time, you can request additional plug-ins with the gnome team via bugzilla. Make sure you request _working_ plug-ins and make sure they are useful to some application currently in portage. Plug-ins you want to experiment with you can easily create in your local portage tree using one of the already available plug-in ebuilds in media-plugins as template. Questions about creating plug-in ebuilds can be directed to me on IRC or by mail. PS II. All bugs concerning gstreamer should go to bugs.gentoo.org , let us assess what is a Gentoo bug and what is a Gstreamer bug. Do not bother upstream devs with Gentoo specific problems. PS III. Currently interesting gstreamer using applications in portage include Rhythmbox, sound-juicer, totem and gst-player. Totem defaults still to the Xine back-end, because the gstreamer support isn't as advanced yet. You can select the Totem gstreamer backend by using the local 'gstreamer' USE flag. Only the latest versions in portage (all still ~) of mentioned applications use the new setup. -- gentoo-dev@gentoo.org mailing list