[gst-devel] float caps

[David Schleef]

On Thu, Jan 29, 2004 at 09:33:37PM +0200, Andy Wingo wrote:
> 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.

I've spent some time thinking recently about creating a subclass of
GstElement specifically for pro-audio streams.  This element would
automatically handle all the caps negotiation for single-channel
float audio, and could also be a hint to the scheduler that a group
of GstProAudio elements can be scheduled as a lock-step group.

> (1) It reduces the complexity of capsnego in DSP pipelines (think many 
>     many elements)

The complexity difference between pad template caps that have 
"audio/x-raw-float, channels=1, rate=[1,MAX], endianness=1234,
buffer-frames=[1,MAX]" and "audio/x-raw-float, rate=[1,MAX],
buffer-frames=[1,MAX]" is minimal.  It would require a few
extra lines here and there.

The alternative will cause a tendancy to support audio/x-raw-float
and audio/x-raw-dspfloat in the same element.  The code required
to properly support is complex and confusing -- just look at, e.g.,
ffcolorspace, which handles both video/x-raw-rgb and -yuv.



dave...