[gst-devel] RFC: argument system?

[Wim Taymans]

On 13 May 2001 15:55:19 +0200, Thomas Nyberg wrote:
> On Sun, May 13, 2001 at 12:30:20AM -0700, Erik Walthinsen wrote:
> 
> > It makes me think that we may indeed want to build our own control system
> > for elements, but I'm hesitant to do that for quite a number of reasons.
> > First of all, the gtk/glib functions already exist, have a number of
> > features that are useful for more unusual plugins (see
> > http://gstreamer.net/lame-args.png for an example), and is still evolving
> > in glib 2.0.
> > 
> > Then again, we may want to consider that there are different classes of
> > controls for different classes of elements.  It could be that we use the
> > existing gtk/glib system for common arguments like those found in lame,
> > but our own system for things like mix levels, etc.  Basically anything
> > that could be changed frequently, even the existance of a given argument
> > is dynamic itself.
> > 
> > steveb's dynparms proposal may be the right way to go about this,
> > especially if it can be done efficiently and without significant code in
> > the common case (that is, less frequent changes that are still
> > time-critical).  If it's designed to be efficient at *both* dynamic
> > dimensions somehow, it would be ideal.
> > 
> 
> I agree on this, if you look at ladspa, you see a nice system for
> an application to determine which parameters that exists, and use them.
> The "ladspa-way" also offers hints, descriptions and other things for
> an application to retrieve. This is something that I believe is vital
> to add to GStreamer. The dynparams-proposal solves this problem in a
> way. The important thing is to have an easy API which is flexible
> enough.
> 
> If we are going to provide support for LADSPA, it is important that
> we have an API which we can use to set these parameters too. Dynparams
> should be able to solve this problem though, and that is why we should
> concentrate on this feature.
> 
> An application should be able to probe the parameters of an element,
> determine what each of them does, what range of values that are
> acceptable, and so on... It makes the elements more powerful than
> before, since more dynamic things can be added, more options and so
> on... <pun>I really can't see how GStreamer could do without it</pun>

I wonder if glib2.0 interfaces could help us out.

Wim

> 
> Regards,
> 
> /Thomas <thomas at codefactory.se>
> 
> -- 
> Thomas Nyberg                    thomas.nyberg at codefactory.se
> CodeFactory AB                   http://www.codefactory.se/
> Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
>