[gst-devel] audio/raw vs float
Wim Taymans
wim.taymans at chello.be
Mon Mar 19 17:26:27 CET 2001
On 19 Mar 2001 09:55:41 +0100, Steve Baker wrote:
> We have the option of including floating point audio in the definition of
> audio/raw data:
> http://www.tartarus.org/~richard/gst-plugin-writers-guide/cha-basic-types.ht
> ml
>
> This would probably only require the inclusion of a boolean to specify
> whether the data is int or float. In this case the width would specify
> whether the float is 32 bit or 64 bit.
>
> However this is starting to get a bit messy since law, endianness(?), signed
> and depth become meaningless in a float context.
>
> So, what if we create a new mime type audio/float with these properties:
> format - an enum including standard 32 bit and 64 bit formats. New formats
> can be included in future releases.
> lower-bound - usually -1.0 (sometimes 0.0)
> upper-bound - usually 1.0
> rate - The sample rate of the data, in samples per second.
> channels - The number of channels of audio data.
What about this:
audio/raw
"subtype", "float32_foo_bar"
"rate"
....
and
"audio/raw"
"subtype", "int_signed_le"
"rate", ...
the subtype determines what other properties can be present etc..
This would not only reduce the number of properties (using subtypes) but
it will also
avoid a potential explosion of (bogus/non registered/non official) mime
types.
Wim
>
> I think it is justified to have a seperate mime type for audio float data
> since plugins that support both int and float will have to duplicate
> functionality for both types anyway.
>
> cheers.
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list