[gst-devel] Signal processing in Gstreamer

[ensonic]

On 1:34:46 am 29/06/2006 David Schleef <ds at schleef.org> wrote:
> 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.

I thought about having all caps twice, once normal and once with a special
(private) field in there. If two elements support this private field the
negotiate to this format. If this format is used the sending element keeps
real buffers in hardware-memory and the receiving element can take it from
there. In the other cases memory needs to be copied. All this can be done
effectivly by having own buffer push/free functions and choosing them after
negotiation.

>
> 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.
>
Hmm, but gst would idle wait for the results unless there is nothing else
to do.

Ciao
  Stefan