[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