[gst-devel] float caps

[Andy Wingo]

Hi Benjamin,

First off, thanks for not returning my grumpiness ;) Sorry about that.
We can now return to our regularly-scheduled wingo.

I was probing my mind and wondering why I didn't want a didn't want
channels=1 or whatever. I guess the complexity of the old caps[0] made
it a PITA. Also, I feel in "pro-audio"[1] space we should encourage
uniformity. I have a pro-audio document that addresses this.
Furthermore, the whole caps system is an inefficiency wrt state
transitions when you know you're in a realm of restricted variables.
That might be paranoia, though.

One more point is that buffer-frames is a key part of ensuring the
efficiency and operability of a graph. It allows graphs that aren't
linear not have to worry about bytestream-type hacks (which are prone to
lockups in circular pipes) and just chain their buffers with efficient
function calls. It is the thing that makes multi-pad elements bearable
to write.

Nevertheless, I could prolly be convinced to introduce more caps into
the float domain, but we'd have to look at some other options first.

[0] The new caps, from what I've coded with it, looks wonderful. I 
    feel much more comfortable predicting the behavior of with the 
    new caps. It feels more Correct. Nice job, Dave :)
[1] I don't like this phrase, but I'll use it because of existing 
    practice. Same goes for "consumer". Webs we weave!

On Thu, 2004-01-22 at 18:28, in7y118 at public.uni-hamburg.de wrote:
> - If we split int2float and float2int each into two plugins, one doing channel 
> splitting/merging, the other doing the actual conversion, we could use 
> float2int and int2float with autoplugging. That would also solve the current 
> problems for the people that have been reporting them with int2float ! 
> float2int not working.

int2float ! float2int should work. Why doesn't it? Sorry if I missed
this one. It will drop all but the first channel though, in that parse
syntax.

> And yet another thing that moves us closer to conversion hell would be to 
> invent another float format.

Consider this possibility, though. It has a number of advantages:

(1) It reduces the complexity of capsnego in DSP pipelines (think many 
    many elements)
(2) It cleanly separates DSP plugins from media-processing plugins, 
    allowing simplifications or flexibilities as desired
(3) It removes the cause of these questions that seem to come up every 8
    months or so

The "consumer" format could even be called audio/x-raw-float, which
would be more general, and the dsp format audio/x-dsp-float or
something. The disadvantage would be that interoperability with the rest
of GStreamer elements wouldn't be so good. You'd have to make int2dsp or
float2dsp and their opposites.

So, as I see it, we have to make int2float and the channel splitter into
different elements anyway, for your purposes. Oneton is already done for
us of course.

The question is, should DSP plugins advertise x-raw-float caps or have
their own caps? I'm leaning towards the second. Thoughts?

Regards...
-- 
Andy Wingo <wingo at pobox.com>