[gst-devel] plugin splitoff

[Thomas Vander Stichele]

Hey David,

> * Thomas Vander Stichele <thomas at urgent.rug.ac.be> [20011216 17:13]:
> > As soon as we import this tarball in cvs as a plugins module, we'll put
> > the plumbing back in.

> Is CVS module going to be called 'plugins' and own/ext/etc directly
> under that?  Ok, but tarball should be gstreamer-plugins...tar.gz.

Yeah, that's the idea.  I suppose the dots mean version ? We agree on one
tarball ? Of course, we can write scripts to split it up, in a sensible
way preferably this time.

> > If anyone cares I can delve deeper in the how and why and why it's
> > actually fancy when we start incorporating unstable libs, but not
> > right now.

> How about now?  We should try to use system shared libs as much as
> possible.  I guess if we need to track particular versions of something
> for whatever reason we can deviate, but hopefully as just a temporary
> measure.

I agree on the libs.  As much as possible we need to use standard libs.
OTOH, there are libs which aren't stable yet, and that's a problem.
Uraeus asked us to look at how abiword does it since it works well for
them.

Cases in point are mplib and avifile. mplib seems relatively ok, but the
author himself asks that if you use mplib, you incorporate it in your own
project.  Which actually is a good idea, because his libnames (libmp.*)
actually clash with gmp, a floating point library from gnu, on which
python and some other things seem to depend.  Dobey and I have mailed the
author for this btw.

Avifile is another good example: there's no clear release up til now, only
0.6 snapshots, and the author tells me he's going to release an 0.7.0 when
his 0.6.0 snapshot series is stable anyway.

The good thing is : as soon as a library matures, we can depecrate/kill
our version, and the actual plugin can stay where it is.  We just change
the configure checks.   So that, IMO is one advantage of the current
structure.


> > plugins
> 
> This is odd... I can't think of what to complain about on this one. ;)

Personally, I'd like to call them dynlib, but that's just me ;)

> > plugins/own
> 
> Kind of trivial complaint here.. 'own' sounds lame to me.  Why not
> 'plugins/gst/'?  (indep/ too long, int/ would confuse people that these
> not meant for user use... I like gst/ the best)

gst is good for me.  Originally I had "ours" versus "theirs".  Let's all
take a vote on this one please.

> > plugins/own/mono2stereo
> > plugins/own/stereo2mono
> 
> Already had comments on merging these.  Perhaps in the future it could
> move to a generic N-1 1-N plugin.  Not sure what audio terminology is
> for that.  crossbar mixer or something: xbarmixer.  Maybe these are just
> best left as often used custom versions.

I think the right term is channel mixer.  We should try to avoid name
clashes on stuff that means something in audio as well as in video.  I'd
imagine an RGB channel mixer makes sense, so maybe we need audiochannel
and videochannel.  Either way, I leave it at stereomono based on Wingo's
comment but good suggestions are welcome so we can agree on something we
can be happy with.
 
> > plugins/ext/dvdread
> 
> Any reason to call it dvdread vs just dvd?  Yeah it happens to be using
> libdvdread right now but we might add other stuff like dvdnav or
> whatever in there too.  Just 'dvd' would cover it all and IMHO be just
> as clear.

My policy was : a separate dir for each set that depends on a given lib.
So if we use a dvdnav library, it would go in a dvdnav.  Policy on what
libs access what devices should be set in gst through classes, IMO.

> > plugins/system
> 
> Whoa, what is this?  Too many characters.  Most of us are unix users!
> Let's try just 'plugins/sys/' ;)
> 
> If I understand what you mean from the wiki, anything that accesses
> platform specific hardware or drivers goes here?

system was a last-minute decision.  There are a few plugins that seem to
depend on system headers which everyone has or should have (on my machine
they belong to kernel-headers), and not use libs.  I suppose they either
use modules, compiled-in kernel functions or maybe really generic libs.
Because of adding this at the latest time I probably missed some which
should go there, like oss.  I'll check those.  Also, your access to these
probably is dependent on what kernel you use or even what system you're
on.  The point is : stuff that accesses system devices/uses system headers
but doesn't require extra download should go here.  Originally I had them
in ext, but since you don't need libs for them, I moved them to sys.

It just means that out of the box, those plugins should compile if you
have standard development stuff.  Let's not argue too much about it, it's
slightly blurry, but let's agree that we put stuff in here that only needs
a kernel header and a kernel ;)

> That would cover arguably (some in ext now): 1394, aalib(?), esd,
> cdparanoia, sdl, xmms, gnomevfs(?), alsa, arts, artsd, dvd, oss, dv, ...
> Starts to look like list of anything with a src or sink.

Of these, I only agree on oss based on the above.  Maybe alsa, I don't
know enough about alsa, but you all can correct ;)

aalib, sdl, cdparanoia, xmms, dvdread and dv all need external libs that
need downloading.  gnomevfs and arts/artsd go even further since they
probably require other gnome/kde libs to function.

> Without really understanding what 'system' means I'd almost suggest that
> just anything that links to other libs be thrown in ext/ and drop the
> system/ thing.  I guess I need a better explaination.

If people want the sys/* stuff in ext, then that's ok.  I'd think it's a
loss of clarity, but I'm willing to go with the general consensus of
course ;)
Let's just vote on this one as well.

> > plugins/own-libs
> 
> Again, I'd prefer some name like 'plugins/gst-libs'.  But why have the
> 'own' part at all?  Why not just 'plugins/libs'?

Fine by me, up for vote ;) plugins/libs in bad though, we also have
external unstable libs we might want to include.

> > plugins/doc
> > plugins/doc/filterstamp
> > plugins/doc/capture
> 
> Are these really docs?  More like 'plugins/misc'.

This stuff is to be deleted real soon.  misc is ok, but unnessary imo.
I'm going to delete it anyway as soon as we have something decent as a
plugin template.

> > plugins/unstable-libs
> > plugins/unstable-libs/mplib
> > plugins/unstable-libs/avifile

> Hmm?  What does 'unstable' mean?  Why not just 'ext-libs'?

they're unstable as marked by the author or by us.  The fact that we
include them proves that.  Our avi-plugin has been mainly unusable because
even for us it was hard to tell what version you need.  ext-libs would be
fine for me, provided we agree on not including libs that are generally
available : have a source release and even packages.  I don't mind
unstable either, let's just decide.

> Overall reorg not too bad.  I guess.

Thanks ;) I'm happy we can all find some middle ground in this.

>  Though I still think a CML2ish
> build setup and mostly everything except gstplay and the editor in one
> tarball would do just fine.

This is still planned, and a lot could be done with it.  On the highest
level, you could select to download the core, the plugins, and the gui
apps all at once and get them all preconfigured.  It could even let you
download dependency tarballs, a bit like the Apache Toolbox.

We have now made configure.ac (in the core) relatively fine-grained.  (Two
level : a stable/experimental/broken distinction on plugins, and a
use/enable for each lib and resulting plugins).
I would want to add to this a way to also disable building of own/
plugins.  So that each plugin or set of plugins can be enabled or disabled
by autogen.sh or configure.   

Plugins can now easily be marked broken or experimental in configure.ac so
that normal builds can take place while people work on improving their
plugins.

We shouldn't take that any further using autotools; these fine grains can
be combined any number of ways using a higher-level tool like CML, which
would generate the right cmd line parameters for configure to run.

> So debs/rpms for the plugins could be something like the following with
> gstreamer prefix and some renaming of what you have:
> 
> -gst (vs -own, with all the indep plugins)
> for p in ext/: -p
> -libs
> -ext-libs (?) (vs -unstable-libs?)
> -misc (vs -doc, since -docs should really be for the main docs)


I would have to see it in practice I guess ... including all the "own"
plugins in one package seems very good.  It means people will have a base
set to experiment with.  To test basic gst functionality.

The libs, we have to see about those.

and misc or doc as it is now shouldn't even be packaged, devel only.

OK people, I think we can make this work ;)  Please send in comments, I
like them ;)

Thomas


The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
If I could be who you wanted
all the time
then I would
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/