[gst-devel] audio/raw vs float

[Richard Boulton]

On Mon, Mar 19, 2001 at 08:05:04PM +0100, Wim Taymans wrote:

> 
>  "audio/raw"
>   "format", "float",
>   "layout", "IEEE"
> ...
> 
> 
>   "audio/raw"
>    "format", "int",
>    "signed", true,
>    "endian", "little"
> ...
> 
> format is the subtype because it defines what other properties
> are allowed next. Think of it as an hierarchy or a union with
> a type to denote the contents...


I like, and I dislike.  I like the plan of first having some type
information, and then a set of properties with the allowed properties
dependant on the type information.

I disklike because I don't see what advantage is gained by separating the
type into two pieces.  I have a feeling that the main reason you want to
split the type into pieces is to preserve the integrity of the first part
of the type, which is currently a mime-type; ie, something whose allowable
values are defined outside of gstreamer.


I think the big bad thing about the system of having a format paramter
which controls which other formats are available is that it makes setting
up pad properties messy.  Consider: I have a plugin which can accept
audio/raw in either float or int format.  I have to write:

GST_PAD_FACTORY_CAPS (
  "audiosink_sink",
    "audio/raw",
    "format",   "int",
    "signed", true,
    "endian", "little"
....
  ),
GST_PAD_FACTORY_CAPS (
  "audiosink_sink",
    "audio/raw",
    "format", "float",
    "layout", "IEEE"
....
  ),

If the subtype were incorporated into the main type, I would have
(convention to name the main type to be decided):

GST_PAD_FACTORY_CAPS (
  "audiosink_sink",
    "audio/raw/int",
    "signed", true,
    "endian", "little"
....
  ),
GST_PAD_FACTORY_CAPS (
  "audiosink_sink",
    "audio/raw/float",
    "layout", "IEEE"
....
  ),

This may not seem much different, but in my view its immensely nicer
because it gives you:
 * One value, recognises specially by the system, which describes the set
   of data, and which controls (together with a policy document) the
   properties that that caps may have, and what their meanings are.
 * Equality amongst the properties.  There isn't one of them which is
   especially important; since they all _look_ the same, they should _be_
   the same.
 * The ability to implement caps negotiation specially for particular
   types.  For example, to speed things up we might want to cache the
   available properties of known types by making a hash out of their
   values: to do this we need to know the type (int, pointer, bool) or
   each parameter, and if there is only one value dictating the main
   type, this becomes a lot easier.

I honestly can't see that we lose anything, either: I think the use of
mime-types is a nice idea, but not quite what we want, since too many
possible data types (spectral data, eg) don't fit neatly into a mime-type
category.
   

Incidentally, are you writing endian as a string for any particular reason?
In the current docs, I've got it as an integer, possible values 0 or 1.
Would a string make more sense?  Are there values other than big-endian and
little-endian that need to be handled?

-- 
Richard