Feature Request: Create a standard/API for (camera src) elements to dynamically advertise configuration options for the application
Background
Many camera interfaces provide interfaces to change properties during runtime (e.g. v4l2-ctl), however, the properties one can control on cameras differ by the actual camera connected and might only be available during runtime. Examples are common properties such as saturation
and exposure
, and highly specific properties such as e.g. controls-laserpower
of an Intel RealSense camera
Feature Request
Elements should be able to advertise the properties that can be (dynamically) adjusted to an application, such that one can configure these properties on the element/pipeline.
Use Case
A use case is that one would like to generate a UI that allows us to control camera properties such as saturation, exposure, and so on.
Existing things
gst-photography
For cameras there already exists the gst-photography interface, but these seem to just be common properties available on (many?!) cameras.
gst-plugin-pylon 'features
gst-plugin-pylon use the gstChildProxy to dynamically advertise properties.
The pylonsrc plugin dynamically exposes all features of the camera as gstreamer child properties with the prefix
cam::
and all stream grabber parameters with theprefix stream::
Pylon features like
ExposureTime
orGain
are mapped to the gstreamer propertiescam::ExposureTime
andcam::Gain
.