Hi @DoomMonkey
I have been having the same issue since mid-July. I am still waiting for an update on controlling the same camera on the same VIM4 NPU. (see Issues with recording custom video + audio when using `v4l2-ctl` and `gst-launch-1.0` - #15 by omarc)
These are my findings/workarounds so far:
- The device /dev/media0 seems to be a virtual device generated at kernel level by aggregating the different subdevs. This device do not offer a direct interface with
v4l-ctl. - The devices /dev/video6* do not control or show an updated value of the camera parameters but can be used as a source in a
gst-launch-1.0pipeline. - The devices
/dev/v4l-subdev3 /4show the updated values of the camera as the camera is being used for recording or streaming (viagst-launch-1.0) - Changing the exposure, gain, and brightness in the
v4l-subdevdevices does not impact the video recording, as these values are automatically updated when starting the camera viagstreameroropencv. - It seems the WDR ignores all controls and updates the values as it adapts to the light conditions. I have not found a way to disable the WDR (or to understand it in the current code base).
- I have updated over different OS and common-drivers releases, from 22.04 to 24.04, from Fenix 1.6.9 to the current Fenix 1.7.1, but the issue still persists.
“Workarounds”
- Another user could change the camera controls, but in a VIM4 (without the NPU). The user does that by launching a GStreamer pipeline at startup and using a custom client to gather the frames and stream them. I have tried to do the same in the VIM4 NPU. Launching the pipeline is fine, but changing the camera controls (via
v4l-ctl -d /dev/v4l-subdev4 --set-ctrl exposure=35000) will freeze the gstreamer startup pipeline, and it will get locked until a reboot. User @steely-glint has kindly shown me a demo and helped me to tackle an alternative. - As I am developing an urgent project, I followed Khadas’ advice and changed the control values in the driver source code (and re-compiled it using their Fenix tools). Although the values can be hardcoded, the recording sometimes fails as there is something done, I assume, with the WDR that makes the recording record many artifacts when the camera is exposed to abrupt light changes. This workaround will work in most cases but does not disable other modules (such as WDR, FPS calculation, and something called adaptive mode in the code) that affect the video recording (or streaming).
I am looking forward to @numbqq updates, as this issue has been there for a long time. This camera is also an issue on the Edge2 pro platform.