Hi there,
I was trying to test OV5693 sensor with V4L2 bypassing ISP on Jetson TX2 with the R27.1 release and I am getting empty frames. As far as I understood from the updated documentation and the forum https://devtalk.nvidia.com/default/topic/955467/jetson-tx1/the-omnivision-ov4689-camera-driver/post/4970947/#4970947 we no longer need to recompile the kernel defining VI bypass in order to grab frames directly from V4L2.
gstreamer pipeline with nvcamerasrc works just fine
gst-launch-1.0 nvcamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvoverlaysink -ev
same goes for
nvgstcapture
But whenever I try to access V4L2 directly using
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --stream-count=1 -d /dev/video0 --stream-to=ov5693.raw
or
./yavta /dev/video0 -c1 -n1 -s1920x1080 -fSRGGB10 -Ftest.raw
or even
nvgstcapture --camsrc=0
I get nothing.
hexdump -C test.raw
returns
00000000 ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f |.?.?.?.?.?.?.?.?|
*
003f4800
Am I missing something?
Thanks a lot in advance!
Cheers,
Artem
_av
May 29, 2017, 5:37pm
3
does nvgstcapture write a file?
As far as I can see, nvgstcapture writes a file only if you enter
j
while it is running. In CSI mode it does produce images, in V4L2 mode it crashes instantly.
Files written by yavta and v4l2-ctl are identical.
_av
May 30, 2017, 1:00pm
5
j keypress seems to create a jpg file
I am just wondering how to capture a video file with the onboard camera.
it should be something like
nvgstcapture -m 2
or
nvgstcapture -m 2 -k 0
However, It won’t create a videofile that way, as it seems to me.
1 and 0 keypress seem to initiate a video recording at stop it correspondingly
Now it works!
I am just wondering if there could somehow auto correction of white and whatever autocorrection be applied.
Reference: http://developer2.download.nvidia.com/embedded/L4T/r24_Release_v2.0/Docs/L4T_Tegra_X1_Multimedia_User_Guide_Release_24.2.pdf?ZcecQWvOukxSr5ID2PGCupAZKfGjBv6_IL8dD3zKJWBluj7M-w0Atp1xpwYj58NqV23P1pglJOYWW_KAcixIj8zMctVsN2AznQQTWEALFVZrc4tvvO0kK7uHd3LfISoV1iWJ3folJtG1XwMGKA6AQYQsjIpqHC4Uz0qWM9Cy5PsQs4QIos-hPA94jSlbE1qczLAtYBw
You can enter video capture mode either with
nvgstcapture -m 2
or by typing
mo:2
while nvgstcapture is running. Use keys:
1 to start
0 to stop recording into a file.
_av
May 30, 2017, 1:42pm
7
Thank you!
It works!
Do you know how to apply image correction ?
There are some of the options in the doc you have quoted earlier.
Dear nVidia,
can you add anything onto the topic?
Hi there,
I was trying to test OV5693 sensor with V4L2 bypassing ISP on Jetson TX2 with the R27.1 release and I am getting empty frames. As far as I understood from the updated documentation and the forum https://devtalk.nvidia.com/default/topic/955467/jetson-tx1/the-omnivision-ov4689-camera-driver/post/4970947/#4970947 we no longer need to recompile the kernel defining VI bypass in order to grab frames directly from V4L2.
gstreamer pipeline with nvcamerasrc works just fine
gst-launch-1.0 nvcamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvoverlaysink -ev
same goes for
nvgstcapture
But whenever I try to access V4L2 directly using
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --stream-count=1 -d /dev/video0 --stream-to=ov5693.raw
or
./yavta /dev/video0 -c1 -n1 -s1920x1080 -fSRGGB10 -Ftest.raw
or even
nvgstcapture --camsrc=0
I get nothing.
hexdump -C test.raw
returns
00000000 ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f |.?.?.?.?.?.?.?.?|
*
003f4800
Am I missing something?
Thanks a lot in advance!
Cheers,
Artem
hello Artemi,
the reason why dump the raw file with V4L2 cannot read is due to memory format update.
there’s memory pixel format update for TX2. it was T_L8 for TX1, and T_R16_I for TX2 now.
please waiting for next public release document for more details.
thanks
Artemi
June 12, 2017, 12:48pm
11
Hi JerryChang,
thanks for your reply!
It is still unclear to me how memory format could affect hexdump in the way it would return a blank file. Or did you mean V4L2 can’t read the data from RAM because of memory format, hence blank file being produced? Which release document you are refering to?
Thanks!
Regards,
Artem
hello Artemi,
right, the memory format do not affect the hexdump.
if you read the whole hexdump, the “FF 3F” should be exist in the image header, and some meaningful values following that.
moreover, please try to view the raw dump files by 7yuv, select RGGB16bit and corrected the image resolution, and modify Bits to 14 to view a better picture.
Which release document you are refering to?
I mean the next public release of the Tegra Linux Driver Package Documents
Artemi
June 13, 2017, 6:49am
13
Hi JerryChang,
as I have mentioned above, there is no meaningful output in the hexdump. Every line is as shown below - it contains only FF 3F.
00000000 ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f |.?.?.?.?.?.?.?.?|
*
003f4800
Tried it with 7yuv, but the result was as expected. There is NO data in the produced file.
Regards,
Artem
JerryChang:
hello Artemi,
right, the memory format do not affect the hexdump.
if you read the whole hexdump, the “FF 3F” should be exist in the image header, and some meaningful values following that.
moreover, please try to view the raw dump files by 7yuv, select RGGB16bit and corrected the image resolution, and modify Bits to 14 to view a better picture.
Which release document you are refering to?
I mean the next public release of the Tegra Linux Driver Package Documents
hello Artemi,
did you see any suspect failure messages while doing the raw capture?
could you please have another try to capture the raw files by using default settings. thanks
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1 --stream-to=test.raw
Artemi
June 19, 2017, 8:40am
15
Hello JerryChang,
capture completes with no errors. It is confirmed with < for each frame captured.
nvidia@tegra-ubuntu:~$ v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --stream-count=1 -d /dev/video0 --stream-to=ov5693.raw
<
nvidia@tegra-ubuntu:~$ v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1 --stream-to=test.raw
<
nvidia@tegra-ubuntu:~$ hexdump ov5693.raw
0000000 3fff 3fff 3fff 3fff 3fff 3fff 3fff 3fff
*
03f4800
nvidia@tegra-ubuntu:~$ hexdump test.raw
0000000 3fff 3fff 3fff 3fff 3fff 3fff 3fff 3fff
*
03f4800
Regards,
Artem
JerryChang:
hello Artemi,
did you see any suspect failure messages while doing the raw capture?
could you please have another try to capture the raw files by using default settings. thanks
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1 --stream-to=test.raw
hello Artemi,
i would like to double confirm below things with you,
thanks
which JetPack version you used to reproduce this issue.
may i know which sensor board you were using?
is vi-bypass path workable? (for example. nvgstcapture-1.0 or gst-launch-1.0)
do you had other TX2 supported sensor module for cross verification?
Artemi
June 19, 2017, 12:14pm
17
Hello JerryChang,
JetPack 3.0 with L4T 27.1
Out-of-the-box OV 5693
Both nvgstcapture and gstreamer with nvcamerasrc work fine.
Not yet. I have ordered this module e-CAM30_CUTX1 - 3.4 MP Jetson TX2/TX1-KameraPlatine but it will take a while until it gets here.
Hope to hear from you soon.
Regards,
Artem
hello Artemi,
sorry for late reply,
we’re able to reproduce this issue with ov5693.
could you try to dump more frames to check if the issue only exist in the 1st frame?
for example.
v4l2-ctl --set-fmt-video=width=2592,height=1944,pixelformat=RG10 --stream-mmap --stream-count=5 -d /dev/video0 --stream-to=ov5693.raw
Artemi
July 11, 2017, 1:19pm
19
Hello JerryChang,
the frames past the first one are indeed not empty, but I am still not able to see anything reasonable.
Right now it looks like this:
https://ibb.co/cc5zAF
Any ideas?
Cheers,
Artem
JerryChang:
hello Artemi,
sorry for late reply,
we’re able to reproduce this issue with ov5693.
could you try to dump more frames to check if the issue only exist in the 1st frame?
for example.
v4l2-ctl --set-fmt-video=width=2592,height=1944,pixelformat=RG10 --stream-mmap --stream-count=5 -d /dev/video0 --stream-to=ov5693.raw
hello Artemi,
it’s cause by the update of the stride alignment from 64 to 256.
the tool you’re using (7yuv) can only adjust stride alignment maximum to 128, hence you’re not able to read the reasonable result.
you could change it back just modify the TEGRA_STRIDE_ALIGNMENT.
R27.1/kernel/kernel-4.4/drivers/media/platform/tegra/camera/vi/core.h