[PATCH v4l-utils v2 0/2] fix expected buffer length calculation

[PATCH v4l-utils v2 0/2] fix expected buffer length calculation

[Sarah Gershuni]

v2:

In this updated version:

- Restore single-buffer calculation using bytesperline
  Replace the multi-planar v4l2_fwht_find_pixfmt-based logic with the
  original single-buffer model, using bytesperline instead of assuming
  stride == width.

- Keep plane_bytesperline as added in v1
  The plane_bytesperline array and its initialization in
  g_fmt_setup_trace are unchanged from v1.


- Link to v1: https://lore.kernel.org/all/20260316132223.7337-1-sarah556726@gmail.com/

v1:
The current implementation assumes that stride equals image width,
which leads to incorrect buffer size calculations when padding is present.

This series fixes the issue by introducing stride-aware handling.

The previous version computed buffer sizes using per-plane
bytesperline values and v4l2_fwht_find_pixfmt, iterating over all planes.

Patch 1 introduces plane_bytesperline to store per-plane stride.
Patch 2 uses it to compute the expected buffer length.


Thanks,
Sarah

Signed-off-by: Sarah Gershuni <sarah556726@gmail.com>
---
Sarah Gershuni (2):
  add plane_bytesperline to trace_context
  use bytesperline for expected buffer length calculation

 utils/v4l2-tracer/trace-helper.cpp | 22 ++++++++++++++--------
 utils/v4l2-tracer/trace.h          |  1 +
 2 files changed, 15 insertions(+), 8 deletions(-)

-- 
2.43.0

[PATCH v4l-utils v2 1/2] add plane_bytesperline to trace_context

[Sarah Gershuni]

Add plane_bytesperline array to trace_context to store stride per plane. Update g_fmt_setup_trace to initialize the array.

Signed-off-by: Sarah Gershuni <sarah556726@gmail.com>
---
 utils/v4l2-tracer/trace-helper.cpp | 15 +++++++++++++--
 utils/v4l2-tracer/trace.h          |  1 +
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/utils/v4l2-tracer/trace-helper.cpp b/utils/v4l2-tracer/trace-helper.cpp
index 9e5747a2..6c296dbf 100644
--- a/utils/v4l2-tracer/trace-helper.cpp
+++ b/utils/v4l2-tracer/trace-helper.cpp
@@ -399,16 +399,27 @@ void g_fmt_setup_trace(struct v4l2_format *format)
 		ctx_trace.width = format->fmt.pix.width;
 		ctx_trace.height = format->fmt.pix.height;
 		ctx_trace.pixelformat = format->fmt.pix.pixelformat;
+		ctx_trace.plane_bytesperline[0] = format->fmt.pix.bytesperline;
 	}
 	if (format->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		ctx_trace.width = format->fmt.pix_mp.width;
 		ctx_trace.height = format->fmt.pix_mp.height;
 		ctx_trace.pixelformat = format->fmt.pix_mp.pixelformat;
+
+		for (unsigned i = 0; i < format->fmt.pix_mp.num_planes; i++){
+			ctx_trace.plane_bytesperline[i] = format->fmt.pix_mp.plane_fmt[i].bytesperline;
+		}
 	}
-	if (format->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+	if (format->type == V4L2_BUF_TYPE_VIDEO_OUTPUT){
 		ctx_trace.compression_format = format->fmt.pix.pixelformat;
-	if (format->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+		ctx_trace.plane_bytesperline[0] = format->fmt.pix.bytesperline;
+	}
+	if (format->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE){
 		ctx_trace.compression_format = format->fmt.pix_mp.pixelformat;
+		for (unsigned i = 0; i < format->fmt.pix_mp.num_planes; i++){
+			ctx_trace.plane_bytesperline[i] = format->fmt.pix_mp.plane_fmt[i].bytesperline;
+		}
+	}
 }
 
 void s_fmt_setup(struct v4l2_format *format)
diff --git a/utils/v4l2-tracer/trace.h b/utils/v4l2-tracer/trace.h
index a74a5f3f..7f166287 100644
--- a/utils/v4l2-tracer/trace.h
+++ b/utils/v4l2-tracer/trace.h
@@ -32,6 +32,7 @@ struct trace_context {
 	__u32 pixelformat;
 	std::string media_device;
 	__u32 compression_format;
+	__u32 plane_bytesperline[VIDEO_MAX_PLANES];
 	union {
 		struct h264_info h264;
 	} fmt;
-- 
2.43.0

[PATCH v4l-utils v2 2/2] use bytesperline for expected buffer length calculation

[Sarah Gershuni]

The current implementation of get_expected_length_trace() assumes
that the stride is equal to the image width, which can lead to
incorrect buffer size calculations when padding is present.

Fix this by using the bytesperline value provided by the driver
instead of width when computing the expected buffer length.

Keep the existing format-specific logic for formats such as NV12
and YUV420 unchanged, but base the calculation on the actual stride.

This addresses the TODO comment regarding incorrect assumptions
about stride handling.

Signed-off-by: Sarah Gershuni <sarah556726@gmail.com>
---
 utils/v4l2-tracer/trace-helper.cpp | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/utils/v4l2-tracer/trace-helper.cpp b/utils/v4l2-tracer/trace-helper.cpp
index 6c296dbf..a56e2d02 100644
--- a/utils/v4l2-tracer/trace-helper.cpp
+++ b/utils/v4l2-tracer/trace-helper.cpp
@@ -233,12 +233,7 @@ void print_buffers_trace(void)
 
 unsigned get_expected_length_trace()
 {
-	/*
-	 * TODO: this assumes that the stride is equal to the real width and that the
-	 * padding follows the end of the chroma plane. It could be improved by
-	 * following the model in v4l2-ctl-streaming.cpp read_write_padded_frame()
-	 */
-	unsigned expected_length = ctx_trace.width * ctx_trace.height;
+	unsigned expected_length = ctx_trace.plane_bytesperline[0] * ctx_trace.height;
 	if (ctx_trace.pixelformat == V4L2_PIX_FMT_NV12 || ctx_trace.pixelformat == V4L2_PIX_FMT_YUV420) {
 		expected_length *= 3;
 		expected_length /= 2;
-- 
2.43.0