Re: [gst-devel] audio/raw float caps format

[Ronald B. <rb...@ro...>]

Hey Andy,

On Mon, 2003-06-23 at 16:36, Andy Wingo wrote:
[..]
> It dawned on me that this kind of a problem is the sort of thing caps
> are made for. What I propose doing, and have already done in my local
> copy, is to add a "buffer-frames" property to all float caps. This will
> determine the size for float buffers, in frames. If an element pushes a
> buffer that is smaller than that size, that means it will push EOS on
> the next iteration.
> 
> Applications may then set the buffer size of a whole graph by using
> connect_filtered(). While I was looking at this, I noticed that the
> "slope" and "intercept" properties are pretty useless, so I took them
> out too in my local copy. Float audio data is a realm of restricted
> variables, there's no need to offer the possibility of setting the 0dB
> level to anything other than +/-1.0.

I'm reworking the caps system currently, I'll take these changes into
account.

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...

More comments on all this are all very welcome, I want to have all this
right before I commit all my changes.

Ronald

-- 
Ronald Bultje <rb...@ro...>
Linux Video/Multimedia developer