[gst-devel] plugins

Thomas Vander Stichele thomas at urgent.rug.ac.be
Sun Dec 9 02:09:02 CET 2001


Hi everyone,

people seem to agree on the fact that we need to split off the plugins
from the core in order to make the build more manageable.
People also haven't agreed yet on a good way to split up plugins.

I think that if we're not talking about it we have no hope of an agreement
;)
So we had people who wanted no subleveling at all on the one side, and
people like me (I might even have been alone ;) ) who like deep nesting.

So I thought about it some more and I think I might have an idea that can
more or less please us all.

I think a good division should make it easier for end users and "light"
developers who only want to work on one type of plugin.  It should be easy
for people to install most of what they would consider "core gstreamer",
the things they don't want to touch, and get the rest from CVS.

Case in point : I like to work on mixing, and only that.  So I really
don't care about all of the video plugins (from a development standpoint),
and I also don't care about all the audio plugins that interface with
actual file types.  I'd just like that to be done automagically.  Right
now, I have to download and compile all of gstreamer, which makes the
threshold for me to dive in extremely high.
You can easily think of other developer scenario's.  

Just think how cool it would be if we could attract lots of developers
because they only have to get one little part of the plugins cvs and use a
mainstraim gst release (source, debs or rpms) for the things they don't
work on.

Right, so getting to the point : a good division IMO answers to two
real-life needs :

a) people care about what dependencies a plugin has (ie what libs do
   they need to install)
b) people care about whether a plugin interfaces with the
   outside world (does it read and write my format) or if it treats data
   internally (I want cool effects !)

c) conveniently, most libraries only deal with either internal or external
   data (or so I hope), so b) doesn't conflict with a)

So I propose a two-level structure :

1) audio-ext audio-int
   video-ext video-int
   other-ext other-int

   these are six directories which are pretty unambiguous, as longs as
   you allow for the fact that video can also contain audio stuff (because
   no one watches video without audio), but only there where the
   underlying library also treats them as one.  (If it bothers you that
   it's called video then I have no problems with renaming it to something
   like auvid or even audiovideo.)  So if it's pure audio, it goest into
   audio-*, if it's also video it goes into video-*, and if it's anything
   else it goes into other-*.  

   Other possible directories might be mixed-*, for things that
   purposefully combine audio and video in an unstraightforward way
   (like the synaesthesia plugin, for example).
   If there is a need for it, then system might be a good dir as well,
   though since it is mostly used for video anyway it might as well go
   into video.

2) in it's right first-level dir, I would put each plugin in a directory
   based on the lib it depends on.

I think this is a manageable, straightforward an fairly unobtrusive
layout.

Here's an idea of where some of the plugins would end up according to my
view :

audio-ext/
	lame/
	mad/
	cdparanoia/
	wav/
	silence/
	vorbis/
	icecast/
	oss/
	esd/
	festival/
	arts/

audio-int/
	volume/
	audioscale/
	resample/
	stereo/
	adder/

video-ext/
	aa	
	xvideosink
	vgasink
	mpeg1video
	quicktime
	1394/

video-int/
	videoscale
	deinterlace
	colorspace
	median

other-ext/
	udp
	rtp
	gnome-vfs


I hope this somewhat convinces you of my idea ;) I think it counters most
of the arguments against my previous proposal, which were :
a) categorization of plugins was ambiguous.  Now it's simple to decide
where a plugin should go.
b) There are too many levels.  Well, now there's only one more than the
mess we're in currently.  (actually, if you think about it,
gstreamer/plugins/mad is just as deep as plugins/audio-ext/mad, and
gstreamer/plugins/filters/colorspace is even DEEPER than
plugins/video-int/colorspace).

So, let's discuss this a bit and see if we can work something out, so that
we can move forward quickly restructuring the whole thing before it spins
out of control ;)

Thomas

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
morgen wordt het beter beter voor iedereen
dan krijg ik de strop
en jij wat je verdiende
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/





More information about the gstreamer-devel mailing list