[gst-devel] bufferpools, filter templates

[Baker, Steve]

> Hey folks. Some thoughts:
> 
> I've been moving to try and use interleaved float data for my 
> app.  I'd
> like to update passthrough (the example plugin designed to be 
> used with
> filterstamp) to allow float data as well as int. Any objections
> (thomas?)?

In my ideal world there shouldn't be an interleaved float datatype. I wanted
to think of float audio as an abstracted ideal which didn't have to worry
about the complications of mixing multi-pad non-interleaved audio with
single-pad interleaved audio.  The only reason I could think of to support
interleaved float audio is if there is a file format out there which uses it
- and I don't know of any.

There have been long threads on Linux-Audio-Dev about why non-interleaved
float is the only type that a "professional audio" app should ever need to
support.

Having said all that I wouldn't want to stop you from adding support - as
long as you had a good reason for using interleaved float audio in the first
place.

The only conversion that is supported in int2float and float2int elements is
interleaved-int <--> multi-pad-float.  These elements are doing
{de}interleavering and int/float conversion in one step.  If you wanted to
write a pure float {de}interleaver then this might be a good one to base it
on.  Remember that the interleaver element needs to handle incoming buffers
which might not be of equal length.
 
> I've also been looking into bufferpools.  I'd like for passthrough to
> use bufferpools so that it is easier for someone new to gst 
> to create an
> efficient filter. It seems to me like there are two kinds of 
> chain-based
> filters: those that can operate on a buffer and pass that same buffer
> along, and those that must create a new buffer of some 
> different length.
> For the first case, I would just gst_pad_push() the in_buffer, like
> identity does. In fact, exactly like identity. For the second, I would
> create a bufferpool that would be returned by the sink pad's
> get_bufferpool() function. Hopefully the sink's peer element would be
> smart enough to grab a buffer from the pool. On the src side, I would
> get a buffer using gst_pad_get_bufferpool() on the source pad, or
> malloc() one if that failed. Really, using bufferpools in the whole
> pipeline so that no malloc()ing occurs is the ideal.
> 
> I am just learning about this today, so if folks with more experience
> have any comments, I'd like to hear them. I would call the first case
> 'passthrough', and the second case '
> 
> well I don't know what I would call the second case. 'modify' perhaps.
> These plugins would not do anything to the data, and would just be
> useful to filterstamp.
> 

Actually, the int2float/float2int elements are 'modify' plugins and they
currently use a default bufferpool implementation based on GMemChunks (which
avoids unnecessary mallocs).

All it took to use the default bufferpool was:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/plugins/f
ilters/intfloatconvert/float2int.c.diff?r1=1.3&r2=1.4

and the default bufferpool implementation can be seen here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/gst/gstbu
fferpool.c.diff?r1=1.7&r2=1.8

I would be happy if you used gst_buffer_pool_get_default in a passthrough
example.

cheers