[gst-devel] Signal processing in Gstreamer

[David Schleef]

On Wed, Jun 28, 2006 at 12:39:42PM +0200, ensonic wrote:
> Just write a normal element that :
> - initialy loads the dsp code to the dsp,
> - sends incomming data to the dsp,
> - invokes processing and
> - pushes result data from the dsp to the next element
> 
> This will basically work. The drawback is that if you have two dsp based
> elemnts one after the other, you could avoid copying the result out of the
> dsp memory, but this needs some work on gstreamer. Maybe subclassing
> GstBuffer or some additional fields on caps.

I've thought a lot about this kind of stuff, and it seems to work quite
well for the developer to invent a new caps that fits the particular
application.  In one case, I created video/x-gl-texture for passing
around OpenGL textures.  In my observation, these alternate buffer
domains are only useful in special applications, and should remain
private to the packages that need to use them.

The 0.10 model is a bit lacking in the sense of using GStreamer to
handle connections between a bunch of elements, but all (or many) of
the elements do processing on another CPU, and don't require explicit
scheduling.  Perhaps Wim can comment on this more.



dave...

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux