Gentoo Archives: gentoo-dev

From: foser <foser@×××××××××××××××××.net>
To: gentoo-dev@g.o
Subject: [gentoo-dev] Gstreamer plugins setup
Date: Thu, 25 Sep 2003 18:18:06
Message-Id: 1064513870.7748.178.camel@rivendell
1 Hi,
3 as you might have noticed if you use a ~ profile there have been some
4 pretty big changes to the gstreamer plugins setup. Some of the details
5 of working with this are still under discussion, we would like to see
6 some feedback on this.
8 Gstreamer ( is a pluggable media framework,
9 which is since the 0.6 series officially part of the GNOME Desktop. It
10 consists of a small core library and a set of plug-ins which put
11 together in pipeline can do tasks ranging from ripping cd's, playing
12 your music library to video manipulation and more to come. The Gentoo
13 GNOME team has always been an avid fan of this promising framework,
14 although it had and has it's problems. These issues have become more
15 apparent now several gstreamer using applications have matured and are
16 used by a wider audience.
18 The plugins provided by gstreamer besides the basic ones are provided by
19 the gst-plugins package, which contains a wide variety of plug-ins with
20 their respective dependencies. Some of these plug-ins might not even be
21 fully functional (anymore) or even broken. We used to provide these
22 plug-ins as one big package, resulting in a lot of dependencies and
23 always giving the GNOME team trouble in one way or the other. Especially
24 the dependencies list was an annoyance, we couldn't possibly cover every
25 plug-in with a USE flag and the ones covered by a USE flag could be
26 broken or generate a whole list of unnecessary gnome dependencies. I
27 personally contribute about 75% of the problems with gnome-meta emerges
28 in this period to problems with gst-plugin dependencies (rough
29 estimate).
31 It was decided that we would split up the gst-plugins package into
32 separate plug-ins, which was done and added to the portage tree when
33 gstreamer 0.6.3 hit the shelves. This allowed us finer control over
34 plug-ins and only add plug-ins proven to be working and stable and all
35 this for every arch if needed. From my personal experience i can say i
36 find gstreamer more stable now a whole set of possible broken plug-ins
37 are not around anymore, a somewhat unexpected plus of the split-up.
38 Every single gstreamer using application can also pull in only the
39 dependencies needed. This is our next 'problem'.
41 Because gstreamer is pluggable, not every plugin possible to use needs
42 to be around for an application to work. Let's take for example
43 sound-juicer, a cd-ripper that can output to wave, ogg, mp3 or flac
44 format at this time. The wave plugin comes with the default gst-plugins
45 package and for oggvorbis we have a USE flag, but for flac and mp3 we
46 don't. Possible solutions for flac and mp3 (in this case) :
48 1. add as non-optional dependencies
49 pros :
50 * you get all possible functionality
51 cons :
52 * you get unneeded dependencies for a lot of users
54 2. make local USE flags
55 pros :
56 * total control
57 cons :
58 * even more USE flags (!) and it's a jungle already
59 * lot of flags with packages not as clear-cut as this
60 this case (see down)
61 * may be uncertain what exact plug-ins could be used
63 3. don't add deps beyond basic ones needed to run
64 pros :
65 * no unneeded deps/functionality
66 cons :
67 * people might miss functionality without knowing it or knowing
68 how to add it
69 * not very gentoo-ish (?)
70 * not all plug-in names are very explanatory
72 There are some more things to consider : sound-juicer is a pretty
73 clear-cut case as to what plug-ins it can use and what is needed, in a
74 video player the number of possible plugins and (local) USE flags -as in
75 solution (2)- may skyrocket. And gstreamer has auto-plugging ability,
76 where with a given input media and given output sink it creates the
77 pipeline itself selecting plug-ins as needed. There is currently no
78 application in portage that uses this auto-plugging, but it would result
79 in an enormous dependencies list if we go with (2), not to mention (1)
80 defying much of the purpose of splitting it up.
82 Option (1) is only there for completeness sake, i think it's pretty bad
83 to solve it like that (although, the current latest sound-juicer ebuild
84 is set-up like that because of some mis-communication / information).
85 Option (2) i don't like because of it's over-complicating things with
86 all sorts of USE flags and it may be very hard to exactly define
87 plug-ins that could be used with a certain package.
89 Leaves us with option (3), my preferred choice. We provide the user just
90 with the basic plug-ins needed to get up and running. For example a
91 video output plugin for a video player, cd rip (paranoia) plugin for
92 sound-juicer, etc. The other plug-ins are up to the user to add as
93 needed. This might be a little difficult, because it might not be very
94 clear as to what plug-in provides what; the plug-in names might not be
95 all that descriptive (i try to make the ebuild description more clear in
96 those cases) and there might be more plug-ins doing one and the same
97 thing where only one can be used by a certain application (hypothetical
98 situation). To make this easier the GNOME team is planning to provide a
99 web page where plug-in status and exact use of certain plug-ins are
100 explained possibly in combination with application specific information.
101 Users can select on basis of that page what they need.
103 This may sound a little non-gentooish maybe, but i definitely think this
104 is the best solution. Also we could add a series of USE-flagged
105 dependencies to the gst-plugins package, where known working and stable
106 plug-ins get installed providing a solid basis for a lot of
107 applications. As said in the current gst-plugins ebuild, a lot of users
108 should hardly ever feel the need to install extra plug-ins.
110 So i would like to get some opinions on this, what would be the
111 preferred way to have gstreamer applications define their plug-in
112 dependencies ? Any suggestions/improvements/questions ?
114 - foser
116 PS. Not all possible plug-ins have been added this time, you can request
117 additional plug-ins with the gnome team via bugzilla. Make sure you
118 request _working_ plug-ins and make sure they are useful to some
119 application currently in portage. Plug-ins you want to experiment with
120 you can easily create in your local portage tree using one of the
121 already available plug-in ebuilds in media-plugins as template.
122 Questions about creating plug-in ebuilds can be directed to me on IRC or
123 by mail.
125 PS II. All bugs concerning gstreamer should go to , let
126 us assess what is a Gentoo bug and what is a Gstreamer bug. Do not
127 bother upstream devs with Gentoo specific problems.
129 PS III. Currently interesting gstreamer using applications in portage
130 include Rhythmbox, sound-juicer, totem and gst-player. Totem defaults
131 still to the Xine back-end, because the gstreamer support isn't as
132 advanced yet. You can select the Totem gstreamer backend by using the
133 local 'gstreamer' USE flag. Only the latest versions in portage (all
134 still ~) of mentioned applications use the new setup.
137 --
138 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Gstreamer plugins setup Aron Griffis <agriffis@g.o>