Check the sensor cap by v4l2-ctl --list-formats-ext to make sure it support 10 bit.
I don’t think you can get the raw data by nvgstcapture! How?
Any kernel error message while use v4l2-ctl to dump data? TX1 or TX2?
I think you are not upgrade to latest BSP 28.2.1
The v4l2-ctl --list-formats-ext show the wrong support at early BSP. I believe your sensor driver only support one type of pixel format.
I’m running into a problem with reading raw data through v4l2-ctl.
My problem is that the raw data files created show 14 bits of information in the 16 bit data type saved. I get no problems when reading data and can max out my camera’s throughput at 64fps with no errors for long durations (8 hours or more). The data from the camera is sent as 10 bits with 4 packets of 8 bits followed by one 8 bit packet of 2 bits for each of the previous 4 8 bit packages. This last packet is LSBs. I’m guessing this is standard across Sony imx cameras.
Using the Nvargus/gstreamer pipeline the images look okay. I’m more worried about data being corrupted or changed.
I’m seeing this across two different cameras a IMX412 and IMX351.
Here is the v4l2-ctl argument:
v4l2-ctl --set-fmt-video=width=4656,height=1744,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=…/test.raw
To be clear if I crop the outputted data to 10 bits I get an image that is close to what I’m expecting, but again it would be almost the same with the first 8 bits as the last two are LSB’s.
This might be as simple as the data is only overwriting the 10 bits of useful information of the 16 bit packet, but getting some confirmation of how nvargus/v4l2-ctl handles 10 bit incoming data would be useful.
Where is this doc? All I have is the TLDP development guide.
After looking into this more with the help of a colleague, it looks like the raw data can be extracted by shifting it over right 4 bits. Which is what I was doing but what was weird is the left 2 bits are zeros and the last 4 bits are the first 4 bits of data repeated.