[gst-devel] float caps

[Andy Wingo]

Howdy again,

On Sat, 2004-01-31 at 12:00, Benjamin Otte wrote:
> I'm not sure we need to seperate float caps, though it probably wouldn't
> hurt either, you can accept more than one mimetype ;)

Yeah, but given that I'm the only one arguing for different caps, and
that Dave says there's not a difference in efficiency between the two
caps, it's just easier to unify.

Your suggestions are good, except for:

> - layout (string): "interleaved" or "sequential", which would describe how
> the samples are put into the buffer on multichannel output.

This, my friend, is a horrible idea. If we are going to have multiple
channels per pad, let's not pretend like we actually have multiple pads.
If we go multi-channel, we go interleaved. DSP audio plugins will almost
always specify channels=1 in their caps, so it doesn't matter to them
anyway.

> This obviously requires converters (floatconvert, ntoone, oneton (this
> one needs to work with float, too), int2float, float2int and maybe
> buffer-frames-adapt).

Well, ok. You have int2float and float2int (which maybe can be done with
audioconvert). I'll take the hit and have oneton (which should either be
called one2n or one-to-n) and ntoone be necessary for dsp pipelines
(damn you ;). Then we're OK, except for buffer-frames-adapt, which I
hope is never necessary, ever.

> Does that make sense? Or do you see issues there?

Naw, it's ok. I still want to make state changes faster, but that's a
problem for another day.

Cheers,
-- 
Andy Wingo <wingo at pobox.com>