Pixels at right end of lines are garbled when capturing with v4l2, not when using argus

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
23

Hello Shane,

have the developers reproduced the problem ?

24

@phdm
Please try the preferred_stride like below example.

v4l2-ctl -c preferred_stride=[4128 | 4160]

25

Hello Shane,

thank you for your suggestion.
Unfortunately it does not solve the problem. It has absolutely no visible effect.

I also moved to jetpack-5.1.2, but it does not solve the problem either.

Do you have news from the developers ?

26

Developer suspect the stride is too smaller cause the problem.

27

Hello Shane,

I had tested with your original proposal : 4128. That did not help. Now with your revised proposal,

‘v4l2-ctl -c preferred_stride=4160’ SOLVES THE PROBLEM for the 4128-wide images :)

which preferred_stride should I set for the 2472-wide images. What’s the formula ?

28

Seeing that 4160 is the first multiple of 64 above 4128, I have tested with the first multiple of 64 above 2472 (which is 2496). THAT SOLVES THE PROBLEM for the 2472-wide images.

Thank you, Shane

This should probably be computed by the VI driver. What’s your opinion ?

29

Here’s the calculation for preferred_stride.

preferred_stride= ALIGN_UP（width*bytes_per_pixel,64）

30

That should go in vi5_fops, isn’t it ?

31

Should be in channel.c and apply to bytesperline in vi5_fops.c

32

Do you have a patch proposal ?

I would gladly test it.

33

I don’t think that could be a good idea. Using v4l2-ctl to set it would be a good way.

34

Hello Shane,

let me disagree : this is clearly a bug in the vi driver. As such it must be fixed in the vi (or vi5 or vi6) driver.

PS: why is this conversation not tagged as ‘nvbugs’ ?

35

The alignment is VI HW limitation. And the VI driver provide the preferred_stride for the flexibility to set it.

36

It’s the mission of the driver, not of the user, to be aware of the HW limitations. It’s good that ‘preferred_stride’ property if available for testing purpose, but that’s not a solution, only a workaround.

37

OK, I would suggest to modify TEGRA_STRIDE_ALIGNMENT that could be a solution.

tegra_camera_core.h	26 #define TEGRA_STRIDE_ALIGNMENT 1
38

Hello Shane,

Applying your suggestion, the following patch solves the problem

diff --git a/include/media/tegra_camera_core.h b/include/media/tegra_camera_core.h
index 788cf77dc..0a534d47b 100644
--- a/include/media/tegra_camera_core.h
+++ b/include/media/tegra_camera_core.h
@@ -23,7 +23,7 @@
 /* Width alignment */
 #define TEGRA_WIDTH_ALIGNMENT  1
 /* Stride alignment */
-#define TEGRA_STRIDE_ALIGNMENT 1
+#define TEGRA_STRIDE_ALIGNMENT 64
 /* Height alignment */
 #define TEGRA_HEIGHT_ALIGNMENT 1
 /* Size alignment */

Thank you !

Isn’t it a bit overkilll as is impacts v2 and vi4 too ?

39

Suppose this modification will change the byteperline no matter for vi2/vi4,
however I don’t think that could cause any issue for vi2/vi4.

BTW, could you help to modify the 32 to check the result.

Thanks

40

Setting TEGRA_STRIDE_ALIGNMENT to 32 is not OK for the 4128 pixels wide images. For the 2472-wide images it works by chance, because aligning 2472 to the next multiple of 32 gives a multiple of 64 (2496).

42

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