Why v4l2-ctl returns corrupted image (odd rows shifted), but nvargus_nvraw works OK?

I am running
nvargus_nvraw --c 0 --exp0 “0.016666,1” --file out --format “raw,jpg”
and it returns perfect image, but
v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to test.raw --verbose
returns image with good even bayer rows (0, 2, etc) except the last 16 samples are missing
and odd rows (1,3,etc) appear to be shifted left, as if the last 16 samples of even rows were moved to the next row.
My image is 720x720 10 bit bggr.

Note that occasionally I see “General error queue is out of sync with frame queue” error, but in most tests there are no errors, but image is corrupt every time.

I tried changing parameters in dts: mclk_khz, pix_clk_hz, line_length, but they make no difference.
Are there some other secret settings, which nvargus_nvraw sets, but v4l2-ctl does not?

Thank you

It could be the 64 alignment problem. Try v4l2-ctl --preferred_stride=1472
Please reference to below topic.

Hi @jhnlmn

The NVIDIA Jetson capture systems seem to have a 64 byte alignment, so there’s a limitation with the number of bytes-per-line (width * bytes) that are not divisible by 64, which it’s required to add an stride aliment to visualize the image correctly.
You can find more information in this wiki:

According to the document:

bytes: 2
bytes per line: 720 * 2 = 1440

# Not Divisible by 64
1440 / 64 = 22,5

# Stride is added to increase the bytes per line
fixed bytes per line: 23 * 64 = 1472
fixed width: 1472 / 2 = 736

# Total size of the image
736 * 720 * 2 = 105984

I haven’t tested the preferred_stride v4l2 control, but I belive it should work too.

Best Regards,

Enrique Ramirez
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com

1 Like

Thank you
preferred_stride=1472 works OK for sensor 720x720:

v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --set-ctrl preferred_stride=1472 --stream-mmap --stream-count=1 --stream-to test.raw --verbose

Is there any advantage in redefining TEGRA_STRIDE_ALIGNMENT as NVIDIA Jetson VI Stride Alignment - RidgeRun Developer Wiki suggests?

Hi @jhnlmn

The advantage of building the Kernel with the default stride alignment is that as a user, you’ll not have to specify it, but if it’s not a problem for you, it would be equivalent to use the preferred_stride v4l2 control.

This control was added recently. For old JetPack versions it was not included and the stride could only changed with the `TEGRA_STRIDE_ALIGNMENT


"This control was added recently. "

I see it was added back in 2019: tegra: camera: add preferred stride controls · LineageOS/android_kernel_nvidia_nvidia@8674121 · GitHub

And, of course, camera app should call TEGRA_CAMERA_CID_VI_PREFERRED_STRIDE with different values (depending on attached sensor) or not call at all if stride is already divisible by 64, is it right? So, fixing stride in kernel does not make sense.

I am still trying to understand all implications of different stride (AKA pitch, AKA step) values.

If I want to capture 720x720x10bpp I need to call NvBufSurfaceAllocate with width = 1440, height = 720, colorFormat = NVBUF_COLOR_FORMAT_GRAY8, layout = NVBUF_LAYOUT_PITCH, like it is done by sample 12_v4l2_camera_cuda/camera_v4l2_cuda.cpp. Is it right?
But that returns buffer with pitch = 1536 (0x600), so lines are padded not to 64 byte (which make sense from cache line and cuda warp point of view), but to 256 bytes.
Why? Who needs 256 bytes padding? And if it is padded to 256 bytes, do I need to pass 1536 instead of 1472 to TEGRA_CAMERA_CID_VI_PREFERRED_STRIDE?
Or if I pass 1472 to TEGRA_CAMERA_CID_VI_PREFERRED_STRIDE instead of 1536, will some API performance suffer?

Suppose the VIC(video convertor) need 256 alignment.

OK, but should I then pass 1536 to TEGRA_CAMERA_CID_VI_PREFERRED_STRIDE instead of 1472?
And if I do receive image with stride 1472 from V4L, will some VIC operations fail or just be less efficient?
Does it apply to all VIC operations or only some of them?

Suppose 1536 would be both good for VI and VIC.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.