V4L2 on Jetson TX2

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

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

2

Same issue here

Best regards
Christian

3

does nvgstcapture write a file?

4

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.

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

6

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.

7

Thank you!
It works!
Do you know how to apply image correction ?

8

There are some of the options in the doc you have quoted earlier.

9

Dear nVidia,
can you add anything onto the topic?

10

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

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

12

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

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

14

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
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

16

hello Artemi,

i would like to double confirm below things with you,
thanks

  1. which JetPack version you used to reproduce this issue.
  2. may i know which sensor board you were using?
  3. is vi-bypass path workable? (for example. nvgstcapture-1.0 or gst-launch-1.0)
  4. do you had other TX2 supported sensor module for cross verification?
17

Hello JerryChang,

  1. JetPack 3.0 with L4T 27.1
  2. Out-of-the-box OV 5693
  3. Both nvgstcapture and gstreamer with nvcamerasrc work fine.
  4. 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

18

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
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

20

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