[gst-devel] Capabilities API functions
zaheer at grid9.net
zaheer at grid9.net
Wed Mar 14 11:51:37 CET 2001
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
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
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
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") &&
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.
More information about the gstreamer-devel