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); }