[gst-devel] audio/raw = 16 bit int?

[Wim Taymans]

On 09 Mar 2001 18:47:48 +0100, Owen Fraser-Green wrote:
> Hi,
> 
> > yes, but only when we have caps negotiation working. The properties you
> > attach to
> > a pad can then be anything you want. You also will have to create a
> > converter that does
> > the float to int conversion so that common cards can handle the data.
> 
> Would it not be better for all audio/raw to be float and leave the 
> responsibility of converting, say a 16-bit WAV source to float up to the 
> source element then have the audio sink only accept 32-bit float (yes, this 
> would be unneccessary conversion but would provide more benefits in the 
> long run)?

I don't think so, many audio decoders are fastest with 16bit raw samples
(mp3, 
vorbis, wav, etc..). I agree we should have converter elements to
convert from and to the
more accurate representations. Anyway there is no reason why there can't
be several
audio formats (float, int...) as long as the conversion elements are
there they can all talk
to eachother.

> 
> Then the conversion would happen in gstaudiosink and co. I guess I just 
> feel with 20- and 24-bit cards becoming common it should be the sources' 
> responsibility to upscale to some theoretical max (i.e. 32-bit) and the 
> sinks' responsibility to downscale it to what the sound driver wants. Then 
> all the filter elements in between only need to understand one common 
> format.
> 
> I'm sure you're about to tell me that this exactly what the new caps 
> negotiation is going to do anyway. It seems I'm usually a step behind with 
> my questions. Still, I'll catch up soon I hope :)

Currently the properties of the media you're handling is descibed with
metadata. We use
a .h file to describe the audio format and we have to attach the
metadata to all the buffers
we handle. This is both slow and inflexible.

With caps negotiation, the media properties will be attached to the pads
using properties (no
more structs in a .h file). The media type is completely defined by the
plugin. When a
property of a pad changes, the negotiation process is started, which
will basically check if
the peer pad can handle the new format. If it can't, the connection is
broken and the app is
responsible for inserting a conversion element.

This also means that we don't have to define a struct or a fixed set of
properties at all. the
pads can figure out themselves if they can understand eachother. this
approach is still
experimental but I think it's for more flexible in the end.

Wim

> 
> Regards,
> Owen
> 
> ---------------------------------------------------------------------------
>      Owen  Fraser-Green             "Hard work never killed anyone,
>      owen at discobabe.net              but why give it a chance?"
> ---------------------------------------------------------------------------
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>