Am Dienstag, den 30.01.2007, 10:44 +0100 schrieb ensonic:
> hi,
>
> in gstreamer/libs/gst/controller/gstcontroller.h we
have:
> /**
> * GST_PARAM_CONTROLLABLE:
> *
> * Use this flag on GstElement properties you wish to
be (eventually) handled
> * by a GstController.
> * TODO: needs to go to gstelemnt.h (to avoid clashes
on G_PARAM_USER_SHIFT)
> */
> #define GST_PARAM_CONTROLLABLE (1 <<
(G_PARAM_USER_SHIFT + 1))
>
> I would like to move this to gstelemnt.h now. Anyone
against that?
Not me at least, FWIW.
> By the means of the GST_PARAM_CONTROLLABLE apps can
detect dynamic
> parameters and also use that to generate meaningful
UIs. What I would like
> to add is
>
> /**
> * GST_PARAM_EDITABLE:
> *
> * Use this flag on GstElement properties that are user
editable (can appear
> * in a UI as an option).
> */
> #define GST_PARAM_EDITABLE (1 <<
(G_PARAM_USER_SHIFT + 2))
>
> Some examples (my opinion):
> name, sync, qos: this is stuff that the application
handles.
> buffer-time, latency-time : something a user could use
to configure a plugin
I must say that this distinction seems arbitrary. One could
argue that
"sync" belongs to the user visible case sometimes,
while "buffer-time"
should be hidden from the user in some contexts. It seems
hard to draw
a line anywhere.
> GST_PARAM_EDITABLE and GST_PARAM_CONTROLLABLE are
mutual exclusive,
> controlable implies editable.
My feeling is that this might limit the potential use of the
controller
system. As it is, it's a clever extension that allows one
to set
property values in the stream time domain. I don't see why
that would
imply "user editability" (whatever that means
exactly). Treating these
concepts as orthogonal should make things easier.
> There is still something that breaks the picture:
trigger parameters. I
> don't know if there is an analogy in video, but in
audio these are
> parameters like 'note' or percussion triggers. They
have a value, they are
> changeable at runtime, but still one would not want to
have them in a
> preset nor in a settings window (one does not *set*
them).
My guess is that there needs to be a way to indicate that a
controllable
property recommends a particular interpolating mode.
"Trigger
parameters" would then recommend the trigger
interpolator (or even
disallow other interpolating modes if they don't make
sense).
> Adding another flag seems waste to me. From the
functional point of view,
> it would be possible to misuse the mutual nature of
GST_PARAM_EDITABLE and
> GST_PARAM_CONTROLLABLE and:
> #define GST_PARAM_TRIGGER (3 <<
(G_PARAM_USER_SHIFT + 1))
>
> Of course there are many hint that one can think of. I
am working on
> designing an interface that bundles UI Hints and that
will attach metadata
> as qdata to GParamSpecs. I still would see the before
mentioned flags as
> flags, as that allows to quickly filter.
I can't see how the flag(s) allow for filtering more quickly
than
querying via an interface.
That said, I think adding a new param flag for this is
wrong. All of
the existing flags (including the added controllable flag)
describe
technical capabilities of the parameter. Meta informative
hints like
"expose this in user-configurable contexts" that
are to be interpreted
on a voluntary basis don't seem to belong there.
--
Regards,
René Stadler
------------------------------------------------------------
-------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstream
er-devel
|