[gst-devel] audio/raw float caps format

[Benjamin Otte]

Some things (partly discussed in IRC):
The idea is fine with me. Maybe it would be better suited for QoS, but
until that lands, it's ok.

Two issues though:

- I'd like a generic name for the property, buffer size negotiation seems
like we would want it in a lot of places. (I'd want it in audio/x-mp3 for
example). "buffer-units", "units" or something.
- I'd like to be able to write a plugin that doesn't support this property
and just spews out buffers the size it likes (even varying sizes).
It would then be easy to write a "bufferresize" or whatever element that
reassembles the buffers to the right size, so that these two were
compatible.


Benjamin


PS: Yeah, I'd really have liked to have you at GUADEC. I'd like to meet
all you non-European Gst guys anyway. If someone has an idea of how to do
this without us poor people going broke, please tell.


On Mon, 23 Jun 2003, Andy Wingo wrote:

> Hello all,
>
> This is a message to those that work with the float audio format. If you
> are one of those, most likely you are working on some kind of audio/dsp
> project. Float audio data in such an environment is much nicer than int
> data, as you don't really have the set of variables that you do in int
> work, and the math is nicer.
>
> So it's really quite an insular world -- your data either comes from a
> ladspa plugin src or from a int2float element. For many reasons the
> preferred format for float data is noninterleaved -- that's another
> discussion I'm not going into now. However, elements with many sink pads
> run into the problem of getting the same amount of data from all pads.
> Traditionally this is done with bytestream elements, but that's just
> masking the problem that there's no way to tell plugins the size of
> buffer that you would like your whole system to use. Often, that's a
> variable the user should be able to change. This gives rise to such
> hacks as the ::buffer-size property on osssink, which sets the size of
> buffers from its internal bufferpools. Upstream plugins may then get a
> buffer from the pool, calculate its size, and use that as their internal
> buffer sizes. All very hackish.
>
> 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 writing to see if these changes affect anyone. If not, I'll commit
> them next time I get internet.
>
> On a less business-oriented note, I wish I could have been at guadec ;)
> Things are still quite nice down here, and I'm getting a lot of hacking
> done as well. But, there's no guinness on draft in Namibia :/
>
> Peace out, peoples.
>
> wingo.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>