[gst-devel] Capabilities API functions

[zaheer at grid9.net]

On 14 Mar 2001, Wim Taymans wrote:

> On 14 Mar 2001 10:51:37 +0000, zaheer at grid9.net wrote:
> > 
> > 
> > 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.
> > 
> 
> a caps structure can only have one mime type. This makes sense because
> the 
> properties are only valid for specific mime types. In  the above example
> you would
> have to describe the caps as a chained list of:
> 
> 
> mime types: "audio/raw"
>    depth: list (8,12, range(13-16))
>    numchannels: list (range (1-2), 4, 8, 16)
>    sample rate: list (400, range (8000-16000), 22100, range (44100-48000))
> mime type: "audio/adpcm"
>    depth: list (8,12, range(13-16))
>    numchannels: list (range (1-2), 4, 8, 16)
>    sample rate: list (400, range (8000-16000), 22100, range (44100-48000))
> mime type: "audio/gsm"
>    depth: list (8,12, range(13-16))
>    numchannels: list (range (1-2), 4, 8, 16)
>    sample rate: list (400, range (8000-16000), 22100, range (44100-48000))
> 

Thanks for that, its cleared it up :)

> 
> > 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 was thinking about:
> 
>    gst_caps_get_mime (caps) to get the caps, you can then strcmp it or
> check if it has

that looks fine
makes it:

if (g_strcmp(gst_caps_get_mime(caps,"audio/raw")==0)

if u wanted only audio/raw


>      an audio part or something.
>   gst_caps_get_int (caps, "channels")

what if its a range of channels or a list of channels and channel ranges
That won't work...

Of course when audio stream is going thru then you'd only have one
possible value, but at the beginning when youre setting up caps this wont
suffice.

 
>   etc...
> 
> I'm not sure we can dynamically create those shortcut functions using
> macros or
> something.
>   
> 
> > 
> > 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.
> 

Zaheer