I have enabled the overlay. The further instructions to use /dev/media0 do not work. I can display the camera using the following but the frame rate is very slow, maybe 2fps, and the color depth does not look correct.
both of those will display the camera but very slowly. Using /dev/media0 does not display anything.
Post a console log of your issue below:
mediaStreamInit[39]: media devnode: /dev/media0
mediaStreamInit[56]: ent 0, name PureThermal (fw:v1.3.0): PureTh
mediaStreamInit[56]: ent 1, name PureThermal (fw:v1.3.0): PureTh
mediaStreamInit[56]: ent 2, name Extension 3
mediaStreamInit[56]: ent 3, name Processing 2
mediaStreamInit[56]: ent 4, name Extension 4
mediaStreamInit[56]: ent 5, name Extension 5
mediaStreamInit[56]: ent 6, name Extension 6
mediaStreamInit[56]: ent 7, name Extension 7
mediaStreamInit[56]: ent 8, name Extension 21
mediaStreamInit[56]: ent 9, name Extension 254
mediaStreamInit[56]: ent 10, name Input 1
mediaStreamInit[90]: get sensor_ent fail
matchSensorConfig[105]: fail to match sensorConfig
fetchPipeMaxResolution[30]: do not find matched sensor configs
media_set_wdrMode[420]: media_set_wdrMode ++ wdr_mode : 0
My bad, I thought I had installed Ubuntu 24.04. So here are some more notes:
while under 22.04 I did try the clutterautovideosink which did run faster but I can still see something not right in the camera video. It appears as though there is some time based filtering of the video frames, almost as thought the frames add up. If you move your hand in front of the camera you can see the hand blended with the background.
I reinstalled the latest Ubuntu 24.04 and the waylandsink behaves the same as in 22.04, only showing about 4.5fps. Also displays the strange time filtering as described above.
I notice now that I am in 24.04 there is no clutterautovideosink available.
I have tried a python appsink to see if it was any faster and no, it is also about 4.5fps and with the same strange additive filtering on the frames.
I have tried other formats, UYVY, RGB, GRAY and they are all 4.5fps
I have noticed that I can get the video on /dev/video63,65,&66 why is that?
v4l2-ctrls show the following yet set-ctrl of exposure has no effect:
Ok, thank you @numbqq , this works. I see 30fps. However, I am still full of questions.
Even at this higher frame rate I can still see this kind of “ghosting” artifact as though the frames are being smeared together. Is this due to some HDR/WDR processing? If so is there a way to turn this off or to handle it differently?
Also, how do we control the exposure of this camera? It appears that v4l2-ctrl does not control the exposure when pointed at /dev/video63/65/66.
Could someone explain the relationship of the different devices /dev/video60-66 and /dev/media0?
I have not tried recording video. I have used gstreamer to directly display or I have used Python+OpenCV to capture and display. I will check a recording and report back.
So I do not see the ghosting problem in well lit or bright scenes. This makes me think it has something to do with the HDR framing. How do we control this camera, specifically the HDR controls and exposure?
When should we expect an update? I have brought up a few issues in this thread and I am curious what exactly is being fixed? The camera image blurring? The ability to control exposure and gain and other camera controls?
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.0 pipeline.
The devices /dev/v4l-subdev3 /4 show the updated values of the camera as the camera is being used for recording or streaming (via gst-launch-1.0)
Changing the exposure, gain, and brightness in the v4l-subdev devices does not impact the video recording, as these values are automatically updated when starting the camera via gstreamer or opencv.
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.
Any progress guys? @numbqq ? I had purchased 4 of the VIM4 and 3 of these camera. It would be great to know that these cameras are actually supported and useful on the VIM4.