[gst-devel] Capabilities API functions

[zaheer at grid9.net]

On Wed, 14 Mar 2001, David I. Lehn wrote:

> * Thomas Nyberg <thomas at codefactory.se> [20010314 00:43]:
> > It would be nice to make some standard of what properties should exist
> > and how they should be created/stored/used.
> > It would be nice to have a
> > const GList *gst_pad_cap_get_depth(pad); 
> > that returns a list of all depth that pad can handle.
> > Which could be just a wrapper for a
> > gst_pad_get_cap(pad, "depth");
> > or something likethat. The easier API, and the less work needed to
> > use it, the merrier it is :)
> > 
> > It is better to have a few ugly gst_pad_cap_get functions than to
> > have ugliness all over the place.
> > 
> 
> I thougth one of the main points of the core is to not have specific
> details of the data types it's processing.  Which means no special
> macros or functions for media specific things.  Isn't using strings
> sufficient?  This stuff is called at a low frequency so performance
> really isn't an issue.
> 
> All these functions are going to have to be translated to scripting
> language bindings at some point.  It's best to try and keep the core
> simple for this.  Handling strings will be easier than maintaining lots
> of specialized enums and structs and functions.

The problem with the caps is that u could have caps for a pad such as
below:

mime types: "audio/raw", "audio/adpcm", "audio/gsm"
depth: 8,12, 13-16
numchannels: 1-2, 4, 8, 16
sample rate: 400, 8000-16000, 22100, 44100-48000
etc.

Here you have a semi-complex capabilities info, that you need to query and
set with a mix of ranges and static values for some fields.

If you are in a gst_elementX_sinkpad_negotiate_caps method and you have
received that caps, and you want to return the caps if it contains:
"audio/adpcm" as a mimetype, 4 in numchannels and 12000 in samplerate.

Do you want this function and every other negotiate function to be a
couple of hundred lines long because the capabilities API has one
query function: const GList* gst_caps_get(const guchar* cap);

Because then every negotiate function will need to know about ranges, and
have to iterate through lists and other nasty things they shouldn't have
to do.

I believe the API should be simple but comprehensive.  In the scenario
above, all the negotiate function would have to do is:

if (gst_caps_query_mimetype(caps, "audio/adpcm") &&
    gst_caps_query_channels(caps,4) &&
    gst_caps_query_samplerate(caps,12000))
{
  return caps;
}
else
{
  return NULL;
}

I would much rather write the above in my plugin than iterate through
lists, figure out ranges and other things to get what could be done in a
handful of lines.

Regards

Zaheer