GNOME Bugzilla – Bug 545519
[v4l2src] only exposes a limited set of properties
Last modified: 2014-12-09 21:09:42 UTC
v4l2src currently exposes mandatory properties as gobject properties and uses three interfaces for optional things: GstTuner GstColorBalance GstVideoOrientation It also implements GstPropertyProbe (for probing device-names?) The v4l2 standard defines many custom controls that would be useful to be controlled from applications. drivers can also register own custom controls. How to get the to the apps? 1.) Expose the fd. Ugly. 2.) For known properties define more interfaces. E.g. a PhotoCaptureInterface for AutoWhiteBalance,AutoExposure,... . There are new control commin all the time, so it needs constant maintenance. 3.) Create a control class on-the-fly and use it via ChildProxy 4.) <your idea here>
I think 3) might be the best solution
*** Bug 649849 has been marked as a duplicate of this bug. ***
There's generic support for arbitrary CIDs now, still a interface for making this more usable would be great ;) We should probably also implement the GstPhotography interface (no it isn't yet!). commit 0fb59275b0e6d264fa971b077cdee11362f819e1 Author: Michael Olbrich <m.olbrich@pengutronix.de> Date: Mon May 20 16:45:37 2013 +0200 v4l2: add a property for arbitrary v4l2 controls This makes it possible to set any controls that can be set with VIDIOC_S_CTRL. The controls are set when the property is set (if the device is open) and when the device is opened. https://bugzilla.gnome.org/show_bug.cgi?id=698837
I wonder how such a interface would work, any idea ? Shall I create another bug for the Photo interface ? (also would that depends on having renegotiation support, or is photo interface no changing the settings ?)
The photo iface mostly sets properties that won't require renegotiation. The main idea of the photo iface is to map the features to hardware or plug software elements. It might be so that the iface is too broad though (e.g. one has Auto-Whitebalance in hardware but not Auto-Focus).
Thanks Stefan, that reminds me that this interface is in -bad, while v4l2 stack is in good. We would have to fixate the API in order to do that, and has you said add maybe some capabilities flags if not yet there. Definatly worst a separate bug.
Let's considered this solved, since it is through what Micheal added. If someone want photo, he will need to get photo interface in -base first anyway.