OUTDATED
--------


A type properties system might look like following:


1) Type definition includes the properties and their ranges:

audio/mp3
	layer:		1 - 3
	bitrate:	8 - 320

audio/raw
	format:		bitfield (using asound.h definitions)
	depth:		8 - 32
	rate:		4000 - 96000
	channels:	1 - n
	interleave:	boolean

video/raw
	format:		32-bit FOURCC
	bpp:		1 - 32
	width:		1 - n
	height:		1 - n
	framerate:	32-bit float

etc.


2) An element can specify what subtypes it can deal with by creating a list of property tables:

mpg123: audio/mp3
	layer:		1 - 3
	bitrate:	8 - 320

osssink:
	format:		S8, S16, etc.
	depth:		8 - 16
	rate:		8000 - 48000
	channels:	1 - 2
	interleave:	true

And you could list several of these, so for instance if the card only supports 8-bit at up to 22KHz in
mono, you can remove S8 from the above list and add a second entry:

osssink:
	format:		S8
	depth:		8
	rate:		8000 - 22050
	channels:	1
	interleave:	false (irrelevant)

The obvious problem with these examples is that the rate isn't really 8000 - 48000, it's 8000, 11025,
16000, 22050, 44100, and 48000.  However, we may be able to leave these to pad connect time.


struct _type_definition {
  char *mime_type;

  ....

  GData *properties;
}

gst_type_add_property_int(_type *type,gchar *propname,int min,int max) {
  struct _type_prop_int prop_int;
  GQuark quark = g_quark_from_string(propname);

  prop_int->id = quark;
  prop_int->min = min;
  prop_int->max = max;
  g_datalist_id_set_data(type->properties,quark,&prop_int);
}