Hi,
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?
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.
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
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?
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?