[gst-devel] audio/raw float caps format

[Steve Baker]

As far as int audio goes:
What if someone writes an element which sits on top of pro-audio
hardware that has 24 bit audio stored in 32 bits? Thats the sort of
situation the width/depth property is for - I don't see it as a major
burden to continue supporting it.

And as for float audio:
I was under the impression that IEEE floats had no endianness issues.

As for the "slope" and "intercept" properties, wingo is right in that
all our float audio stuff will have the same slope and intercept, but
there might be (for example) scientific applications that require
different slope and intercept. Or there might be a hyper-optimised audio
plugin which changes the slope to avoid having scaling its output
buffers - leaving the scaling to some downstream element.

I don't see the harm in being explicit about these things even though
99% of the time we're using the same hard-wired int and float caps.

cheers

On Tue, 2003-06-24 at 07:48, Ronald Bultje wrote:
> One more thing,
> 
> On Mon, 2003-06-23 at 20:40, Ronald Bultje wrote:
> > I was also thinking of removing the signed/unsigned properties on int
> > audio, since 8bit audio will always be unsigned and 16bit audio will
> > always be signed. Allowing for 8bit signed or 16bit unsigned isn't
> > useful in any way...
> 
> Thinking of this some more... Why does audio/raw *specifically* have a
> width/depth property, while video/raw didn't have a rowstride property,
> and why didn't audio/raw (float) have an endianness property?
> 
> I vote for changing int-audio/raw to: audio/raw with two properties:
> layout = "guint8 or "gint16" and endianness = G_LITTLE/BIT_ENDIAN.
> 
> Ronald
-- 
Steve Baker <steve at stevebaker.org>