[gst-devel] audio/raw vs float

zaheer at grid9.net zaheer at grid9.net
Mon Mar 19 14:19:16 CET 2001


Why don't we rename audio/raw to audio/int and also have audio/float and
audio/fixed (and whatever else).

Most filters would generally work on one or another, and the ones that
work on "some" or "all", would be able to handle it in and know which type
during caps negotiation.

The channels labels are IMO a very good idea. 

Regards

Zaheer

On Mon, 19 Mar 2001, Erik Walthinsen wrote:

> On Mon, 19 Mar 2001, Steve Baker wrote:
> 
> > 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.
> >
> > 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.
> 
> I tend to agree here.  audio/raw is generally assumed to be integer, and
> trying to merge the properties between integer and float doesn't look fun.
> The properties you suggest seem like they should cover everything, but
> it's worth doing some web searches for things like SMPTE and AES/BEU
> standards, even M$'s pages (they have some interesting stuff on
> multi-channel formats within the WAV structures already in Windoze).
> 
> One other thought I had is that it might be very useful to include channel
> labels as properties.  For instance, if you bother, you might label one
> stream with channel 0 as 'left' or 'L' and channel 1 as 'right' or 'R'.
> Other labelings include M,S (mid-side), L,C,R,Ls,Rs,S (5.1 surround),
> M,X,Y,Z (low order ambisonics), etc.  These could simply be properties
> such as:
> 
>   "label0", GST_PROP_STRING ("L"),
>   "label1", GST_PROP_STRING ("R"),
> 
> This could introduce the problem of explaining to the props system the
> difference between properties that have to match, and those that don't.
> Then again, it might be good to force a match for labels like these, so
> you don't mix an L,R pair with a M,S pair.  Thoughts?
> 
>       Erik Walthinsen <omega at temple-baptist.com> - System Administrator
>         __
>        /  \                GStreamer - The only way to stream!
>       |    | M E G A        ***** http://gstreamer.net/ *****
>       _\  /_
> 
> 
> _______________________________________________
> 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