1 |
Hi, |
2 |
|
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. |
7 |
|
8 |
Gstreamer (http://www.gstreamer.net) 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. |
17 |
|
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). |
30 |
|
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'. |
40 |
|
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) : |
47 |
|
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 |
53 |
|
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 |
62 |
|
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 |
71 |
|
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. |
81 |
|
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. |
88 |
|
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. |
102 |
|
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. |
109 |
|
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 ? |
113 |
|
114 |
- foser |
115 |
|
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. |
124 |
|
125 |
PS II. All bugs concerning gstreamer should go to bugs.gentoo.org , 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. |
128 |
|
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. |
135 |
|
136 |
|
137 |
-- |
138 |
gentoo-dev@g.o mailing list |