[gst-devel] merging elements in plugins

[Ronald S. Bultje]

Hi,

Thomas is/was working on splitting gst-plugins [0.9] in a few
submodules, 3 IIRC (base, extra, broken). So while working on that, it
may be interesting to do something else while we're at it: merging!

Dave kicked the whole thing off a while ago by proposing to merge gst/*
in one plugin. This is a good idea for many reasons:
* it decreases time spent in loading and initializing tens of dynamic
modules
* it prevent duplicate binary size in dynamic-loading code in all
plugins
* etc.

It is also a bad idea:
* winning a few bytes and losing it 10 times on 24-out-of-25 unused
element classes is a bad idea
* you'll lose even more time in element registration on plugin_init
* etc.

So, I want to take the middle road, which is merging some elements in a
single plugin, for good reasons, but not too many for no good reason.
Since this sounds pretty much like 'I'm gonna save the world but it
won't cost a penny', here's some examples:
* merge audioconvert, audioscale and volume (and maybe equalizer)
* merge videoscale, ffmpegcolorspace, and possibly some more video
filters (videocrop?)
* you could consider merging some of the plugins that are often used for
the one-multichannel-to-many-onechannel-stream and
random-to-buffer-frame-aligned "pro audio" elements such as
bufferframes, oneton, interleave, etc.
* maybe merge xvimagesink/ximagesink elements (even though they should
be separate elements, you could make them a single plugin). It's not
like you'll use them both, but they could share some code, which is also
a good thing from a maintainer's point-of-view.
* possibly see if merging v4l* and v4l2* makes sense for the same
reason?
* there's most definately more
* note that we already do this in some places, e.g. gst/videofilter/ or
gst/debug/. So it's not new at all.
* it may be worth combining some parsing or decoding elements that could
share code, too. A nice extra is that sharing elements in one plugin
means that those elements can share some functions without being
crippled by extra plugin loading time.

Why? Because it combines the good sides and prevents the bad sides
largely - since many of those elements will often (if not always) be
used in combination. Admittedly, the amount of applications that will
use both volume and equalizer is relatively small, but the amount of
applications using either of the two plus audioconvert and audioscale is
large, very large. The same goes for ffmpegcolorspace/videoscale.

Important question is, of course: who will decide what is to be merged
and what not? Well, as with everything, we will decide, where 'we' is
the maintainers. We will be the evil nazi dictators that say 'yes' or
'no' for no obvious reason, and although you will have the possibility
to ask again, our judgement will be final.

Anyone against?

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>