It worked OK on 35.4.1, but on 36.3.0
v4l2-ctl -d /dev/video1 --set-ctrl sensor_mode=2 --set-fmt-video=width=2592,height=1944 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to test.raw --verbose
returns this. All these lines are 32 pixels wide, which suggests that somebody forgot to flush.
But nvargus_nvraw works OK
hello jhnlmn,
it’s JP-6.0/r36.3 known issue, (line artifacts), and we’ve resolved this failure recently.
please refer to Topic 299834 for the bug fixes.
thanks
Sorry, I missed Topic 299834 in my searches because it did not mention v4l2-ctl.
It mentions “VI-Mode”, which is not defined in the docs.
So, if my own app I am calling VIDIOC_STREAMOFF/VIDIOC_QBUF/VIDIOC_DQBUF, is it considered “VI-Mode”? Is it affected?
I do not see the image problems in my app, but may be I did not look hard enough?
or, may be, the way I use V4L is different from v4l2-ctl and I am not affected?
In Topic 299834 you have 2 patches: for DTS and kernel. Are both of them necessary? I do not mind changing DTS (since it is needed for camera anyway), but until now I avoided changing kernel.
May be I should wait for a fix from Nvidia? Are there any time estimates?
Thank you
hello jhnlmn,
please see-also Camera Architecture Stack, it’s the memory handling issue with VI driver.
if you using v4l2-ctl, it could be workaround by dropping some frames, i.e. --stream-skip options.
for instance, issue gone if you try skip frames (as many as possible) to dump a raw file via v4l2.
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-skip=999 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=/tmp/frame1920x1080.raw
I don’t have schedule for next JP-6 public release yet.
please include all the fixes to address the line artifacts issue.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.