[gst-devel] plugin splitoff

[Andy Wingo]

Hi folks,

On Mon, 17 Dec 2001, Thomas Vander Stichele wrote:
> Hey David,
> > Is CVS module going to be called 'plugins' and own/ext/etc directly
> > under that?  Ok, but tarball should be gstreamer-plugins...tar.gz.

right. the only concern being that plugins should build on their own, so
people might end up with (say) /usr/src/plugins (if they just checked
out plugins). but that's their own fault for not using the gst-all
package (which will be forthcoming...) or not passing -d to cvs co.

i think we're all in agreement about these unstable libs -- put them in
while you have to, take them out as soon as possible. makes things a lot
easier for the packager, i would think ;). as well as the general
user...

> > > 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 ;)

you're a dork thomasvs ;-))

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

i vote for gst. 'own' sounds lame to me too.

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

the channel mixer would be cool, but it's (necessarily) more
complicated. it would take interleaved data and do a mixdown? or take
mono and dupe it into interleaved? actually, that's not all that more
complicated...

i'm starting to see your point of view taaz, these plugins would share a
*lot* of code. stereo2mono and the like could be subclasses of the
downmixer or whatever. i would be cool with keeping stereomono for now.
maybe the N to 1 code could instead share code with general
interleaver/deinterleavers instead, which are not written.

also, the current int2float algorithm deinterleaves, and a recent patch
made requests for more output noninterleaved channels than were in the
interleaved stream start duplicating channels. ie out[i] = in[i %
nchannels]. so maybe the code sharing is there. point being, we're fine
for now, imo.

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

i think taaz's point is that this lib might use multiple libs.

> > > plugins/system
> > 
> > Whoa, what is this?  Too many characters.  Most of us are unix users!
> > Let's try just 'plugins/sys/' ;)

right on :)

> 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 ;)

i'm not really for 'sys', as you could have compiled your kernel
differently. it's the same as ext to me. but i'm fine with going along
with you just to get this done.

> > 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 ;)

alsa uses alsa-lib, a user-space library, not the kernel interface. so
it's an 'ext'.

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

i could go either with gst-libs or just libs. again, let's just get this
done :)

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

still that would go in misc, whenever it gets done. doc is a bad name
for this stuff. making a misc directory would be providing room for
future development in the 'misc' category.

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

ext-libs would be more symmetric. i guess if we're really going for
something symmetric and intelligible, we do

/misc
/gst
/ext
/gst-libs
/ext-libs
/doc (in the future, once plugin docs build,)

we all know the reasons for the libs, we just need to decide on a name.

> > Overall reorg not too bad.  I guess.
> 
> Thanks ;) I'm happy we can all find some middle ground in this.

i'm pleased too :)

[discussion on CML2]

cml2 should go in gst-all. i think we are all thinking about the same
thing, really (configure offers the configurability, cml2 helps with the
choices).

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

agreed.

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

esp. since many of even our 'own' plugins depend on the libs... imo the
libs should be bundled in with -gst, the relevant ext plugins should
have their own packages that might depend on ext-libs but certainly
depend on -gst (because they might use -libs). then, in debian you would
hae a task-gstreamer that would pull in 'standard' ext libs as well as
the base packages. mho of course.

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

right

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

within the hour. hit it!

wingo.