[gst-devel] proposal for plugins/ source tree

[Thomas Vander Stichele]

Hi all,

I realize this is a *long* mail from a relatively new gstreamer user, but
I think it at least brings up some good points.  So bear with me !

The current plugins/ directory is a mess.  I'd like to propose a new
structure with these main thoughts in mind :

* it should be easily packageable, preferably automatically
* it should allow someone to get the functionality they need, and no more
* it should be perfectly clear for developers where to put their plugins

As Hadess told me, the idea for 0.2.0 would be to select a few core
plugins and move the rest of all of the plugins out of the cvs tree.
(he also mentioned that he thought my organization was overkill, but I
think it's a necessary evil ;))
I'll also mention what I think should be done in that respect.
In any case, the 0.2.0 freeze would be a good time to restructure the
plugins dir and make it stable enough for future additions.

I think it would be a good idea to establish an "empty" directory layout
in the core gstreamer package, that all external plugin packages would
adhere to.

BASIC IDEA
----------

Plugins can be separated based on various criteria.  Here are a few that
spring to mind :
* connection with the outside world :
	"internal" plugins : do not connect to the world outside gstreamer
		on a plugin level, this probably means it has at least
		one input and one output pad
		examples : stereo2mono, volenv, ... 
	"external" plugins : connect gstreamer data to the outside world
		on a plugin level, this probably means it has a sink or a
		src pad, but not both
		examples : osssink, osssrc, icecast, ...

* basic mime type they work with :
	src and sink pads have a mime type, consisting of a basic and
	extended part.  Most of the plugins will work with only one basic
	mime type, and filters will probably also only work on one 
	basic/extended combination.
	A first division could be made based on the basic MIME type.

	"audio" would contain all plugins that have only audio/... as
	basic mime type and thus only do audio stuff
	"video"
	"image"
	"mixed" where elements combine basic mime types; examples :
		* visualization plugin for audio (audio/... -> video/...)
		* mpegvideo stream demuxer

* extended mime type they work with :

	"audio/raw" would be the basic type
	"audio/ogg" would contain effects in vorbis
		    or convertors from vorbis to the basic type
	"audio/mpeg" ...

* one problem is that a lot of plugins act as mime type convertors; so
where do you put them ? A simple rule would be :
	* if they only have .../raw, put them into the raw directory
	* if they convert between .../raw and .../(ext. type), put them
	  in the (ext. type) directory
	* if they don't convert, but are external, put them into an
	  ext. directory
	* if they combine multiple types, put them in a mixed directory

* most effect/filter type plugins should be written in the ../raw domain
  of their respective field;  specialized versions for a specific mime
  subtype could be added in the respective trees

* plugins that work with certain external libraries should be kept
  together as much as possible

* plugins could also be divided according to their actual functionality
  e.g. a noise gate or volume envelope would be an audio effect
  IMO there are to few functionalities to make a good spread of plugins,
  and they're basically arbitrary (why is colorspace in plugins/filters
  and volume in plugins/filters/effects ?)

SOURCE TREE
-----------
Taking this into account, this would IMO make a good source tree (audio is
filled in, I didn't touch video and image yet since I don't know enough
about them and this took enough time already) :

plugins/
	audio-raw/			-->   all audio/raw ONLY plugins
			raw/		-->     ... with both sink and src
			ext/		-->     ... with only sink or src
	audio-ogg/			-->   plugins with audio/ogg in them
			raw/		-->     ... converting to audio/raw
			ogg/		-->	... staying in ogg type
			ext/		-->     ... with only sink or src

	audio-mpeg/			-->   plugins with audio/mpeg in them
			raw/		-->     ... converting to audio/raw
			mpeg/		-->	... staying in mpeg type
			ext/		-->     ... with only sink or src
	audio-wav/			-->   plugins with audio/wav in them
			raw/		-->     ... converting to audio/raw
			mpeg/		-->	... staying in wav type
			ext/		-->     ... with only sink or src
	audio-mixed/			-->   plugins working on at
						least 2 mimetypes different 
						from audio/raw
			mpeg-wav/	-->     .. converting between mpeg
						   and wav
	audio-ext/			-->  plugins with only audio/raw
						sink or src, not both

	video-raw/
			raw/
			ext/
	video-mpeg1/
			raw/
			mpeg1/
			ext/
	video-mpeg2/
			raw/
			mpeg2/
			ext/
	video-mixed/
	video-ext/

	image-raw/
	mixed/


(In a previous idea, I had audio/raw/ instead of audio-raw/ and so on, but
since the audio/ subdir would only contain further subdirs, this level can
be skipped)

Applied to the current gstreamer audio plugins source tree, this would
give something like

plugins/
	audio-raw/
			raw/
				mixer/			mixer
				stereo2mono/		stereo2mono
				volenv/			volenv
				alaw/			alawencoder
							alawdecoder
			ext/
				audiofile/		afsink
	audio-ogg/
			raw/
				vorbis/			vorbisenc
							vorbisdec
			ogg/    (internal ogg conversion effects ?
				 maybe network bandwith limiter)
			ext/				(oggshout)
	audio-mpeg/
			raw/
				lame/			
				mpg123/
				mad/
				xa/
				xing/
			mpeg/
				parse/			mp3parse
			ext/
				icecast/
	audio-mixed/
			
	audio-ext/
			audiofile/			afsink



PACKAGING
---------
As a developer, one of my gripes with gstreamer is that it *by default*
automakes and compiles all sorts of video stuff, while I mainly want to
program audio.  It should be - at least for an end user - easy to select
or deselect certain plugins.

One open source tool that handles this kind of thing very nicely is apache
toolbox; please check it out at www.apachetoolbox.com.  It allows you to
select your options and modules for apache, mysql and php; there's at
least as much different modules in that as there are plugins in gstreamer.

Yet they managed to make one installer script, which you download, and
where you select all of the stuff you want, and it goes off and gets all
of the source necessary and configures and installs it automatically.

The splitting of packages should handle the following typical needs :
* I am an MPEG video developer and I only need plugins that allow me to
  work on this
* I am an audio developer and I want all of the stuff that applies to
  audio, but not video
* I want a plugins-based vorbis streamer

For a platform with the scope of gstreamer, this would be a good solution.
IMO, this would make a good package structure :

gst-core.tar.gz
	contains 
		the core source
		the core gst elements
			(disksrc/sink, tee, identity, ...)
		an *empty* plugins/ directory layout

		this core should depend as little as possible on
		installed libraries; basically, this core package would
		be able to implement the "cp" command.

gst-audio-core.tar.gz
		audio-raw/ directory tree

		this package would implement all of the basic audio
		manipulation; read/write to soundcards, volume, int/float
		conversion; ... *maybe* it should include audio-wav as well

gst-audio-ogg.tar.gz
		audio-ogg/ dir tree

		this package allows you to convert ogg data to the core
		audio type, audio/raw, as well as stream or output ogg
		data through it's external type plugins

gst-audio-mpeg.tar.gz
		...


gst-audio-all.tar.gz
		all the gst-audio-* packages combined

gst-video-core.tar.gz
		video-raw/ tree
		this would handle all of the raw video stuff (src'ing,
		sink'ing), colorization effects, stuff like that)

gst-video-mpeg1.tar.gz
gst-video-mpeg2.tar.gz
		...

gst-video-all.tar.gz

(you get the picture)

In the above-mentioned scenarios, this is what that person would have to
download :

* gst-core, gst-audio-core, gst-audio-mpeg, gst-video-core, gst-video-mpeg
* gst-core, gst-audio-all
* gst-core, gst-audio-core, gst-audio-ogg

Now, it's obvious that everyone should have gst-core, and this package
would be responsible for outlaying the plugins directory structure.
Other packages would just put their plugins in this empty tree.

The good thing of this approach is that these packages can be easily put
together using scripts, which would allow this to be done automatically.
Also, putting them back together for the end user could be handles by a
script like gstreamertoolbox.


Phew.  I hope you'll consider this idea.  Please let me know if there are
flaws in my reasoning or things you consider not do-able.

thanks,
Thomas

<-*-                      -*->
Don't change your name keep it the same for fear I may lose you again
I know you won't it's just that I am unorganized and I want to find you when
Something good happens
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/