[gst-devel] Short-term plans

[Thomas Vander Stichele]

> For instance, I know that if you were to repeatedly add elements to the
> schedule, PLAY them and delete them, you'll quickly exhaust your cothread
> supply, because it doesn't release them.

seems like something I would really need if I need to write a mixer that
is going to run for months on end ;)

> Other issues center around thread-safety.  We need to determine what
> pieces of code can be run simultaneously with other pieces of code.  Of
> course, for thorough testing of this we need constant access to a
> dual-processor or better machine.  We'll have to figure that out at
> RidgeRun somehow, and/or enlist taaz, who's always been a supporter of
> test suites <hint>.

I have a dual PentiumIII/700 sitting on my desk which by day goes mostly
unused (at night it creates mix blocks for a provider).  So I'm willing to
do my part if I can understand it ;)

> After this is settled, the release has been made, and there's been some
> general cleanup, it comes time to do two things: switch to glib 2.0 and
> gobject, and restructure CVS.  These can happen somewhat in parallel,
> since the glib switch only touches gst/, and the restructuring only
> touches plugins/ and libs/.

I think I have a decent proposal for the plugins dir structure; I'll test
it on the current set of plugins and compare it to Wim's proposal from
three months ago and see how it holds, then I'll mail it to the list.

> Other things to plan for:
> 
> event system
> reworked player core
> new edittor
> remoted containers
> ...more plugins!

I'm thinking of a proposal to add a new type of pad to elements used to
control other elements; arguably this could be implemented through the
normal src/sink structure (which diagramatically goes left to right) but I
think that would ignore the core difference between this "control" pad and
src/sink pads.  Elements should be able to work without control pads, but
not without src/sink.  Control pads then would run top/bottom through
elements.  A good example would be a level detector/AGC chain :

		+---- level
		I       I
audio -- tee ---+	I
		I	I
		+---- volume ------- audio sink

In this case, a "level" plugin would take raw/audio on it's sink pad and
put out "raw/curve" or something on it's control out. (so level acts as a
sink in this respect)

"volume" would take raw/audio on it's sink, put out raw/audio on it's src,
and the audio would be processed based on the envelope coming in through
control/in.

I'm not quite sure if it would be better to insert a *pure* control
plugin, AGC, in between level and volume, which would act on the curve and
spit out a *wanted* volume envelope to volume element.  I would think this
would be better and it would allow for easy implementation of effects that
transform actual gain into desired gain.

It would also work for equalizers if the volume plugin would for example
take in multiple control pads.

Right now, I have a level plugin which just spits out a guess of RMS at
various points to stdout, which can then be fed to gnuplot.  But more
could be done with it, and control pads would be a good way to do it IMO.

Now my question of course : is this possible in gstreamer ? is it hard to
do ? Is it desirable ? Has it been thought of before and scrapped already
?

Please let me know.

Thomas

<-*-                      -*->
You know the shape my breath will take before I let it out
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/