On Thu, 2018-05-10 at 11:00 -0400, Josh Doe wrote:
Hi Josh,
> I've got a bunch of plugins in gst-plugins-vision for machine vision
> camera acquisition libraries, most of which have the capability to
> expose camera properties that are discovered at run-time. Common
> items include exposure, gain, pixel format, ROI, etc, but there can
> also be device specific properties that can't be known ahead of time.
> Obviously this doesn't work with the way GStreamer handles properties
> of elements.
That's not really a GStreamer limitation, but a GObject one.
> Is anyone else doing this? My first thought was just to have a
> dynamic-properties property, which would then be a GObject containing
> all the run-time discovered properties. Perhaps I should expose
> standard properties like exposure and gain simply as element
> properties.
gst-libav and some library wrapper plugins create new classes with
properties on the fly, but not sure that's really the best solution for
you.
> In my particular case, properties can be nested in groups, something
> which GObject properties don't capture, but perhaps I could use a
> double dash to separate levels, though that's not very elegant.
Do you need the list of properties to be discoverable/listable at
runtime by the application? Or is it enough to say they just have to
"know" what's supported based on the camera used?
If listability is not needed, you could add a property of type
GstStructure, and then pass typed key=value pairs like that.
You could also make your own get-property/set-property/list-properties
thing via action signals.
Cheers
-Tim
--
Tim Müller, Centricular Ltd -
http://www.centricular.com_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
