[gst-devel] Capabilities API functions

Wim Taymans wim.taymans at chello.be
Wed Mar 14 18:01:52 CET 2001


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


> 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
     an audio part or something.
  gst_caps_get_int (caps, "channels")
  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.



> 
> Regards

Wim

> 
> Zaheer
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel





More information about the gstreamer-devel mailing list