[gentoo-dev] Gstreamer plugins setup

[gentoo-dev] Gstreamer plugins setup

[foser]

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

Re: [gentoo-dev] Gstreamer plugins setup

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Foser,

Thanks for the informative write-up on what has happened with
gst-plugins lately.  It's nice to see that kind of thing happening on
this list.

foser wrote:	[Thu Sep 25 2003, 02:17:50PM EDT]
> Leaves us with option (3), my preferred choice. 

I like (3) best also.

> 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. 

IMHO, this is perfectly sufficient mitigation for the disadvantages of
(3).

> Any suggestions/improvements/questions ?

I don't have any suggestions.  Looks like you've done a complete
analysis and arrived at well-reasoned conclusions.  Nice work.

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]