gstv4l2bufferpool: Problems when checking for truncated buffer

While writing a v4l2 capture driver for a special hardware capture IP block, I ran into a problem with gstreamer when using the data_offset field of the multiplanar API. The IP core uses a special mechanism to transfer frames in hardware to a specific physical address. For certain hardware reasons, the frame starts with some kind of header data that is written to the destination memory, but must be ignored for further processing. To describe such a scenario, the data_offset field of v4l2_plane can be used. The driver implements the multiplanar capture API and dmabuf memory buffers.

But whhen I want to test the driver with gstreamer, the requested buffers are all discarded with this message: v4l2bufferpool gstv4l2bufferpool.c:2163:gst_v4l2_buffer_pool_process:v4l2src0:pool0:src Dropping truncated buffer, this is likely a driver bug

If I use a data_offset of zero, everything works fine. If I omit the reported check, everything works as expected as well. Even the data_offset seems to be handled correctly.

Since I actually expected a driver error, I tried the same setup with vivid and found that it is the same here. As the vivid driver uses a data_offset of 128 bytes when the YUYV format is selected, this module can be used to reproduce this behavior.

export GST_DEBUG=*v4l2*:4
modprobe vivid num_inputs=1 multiplanar=2
gst-launch-1.0 -v v4l2src device=/dev/videoN io-mode=4 ! video/x-raw,format=YUY2,width=320,height=180 ! fakesink

So if I didn't misunderstand anything, the check should also consider the data_offset.

Tested with version 1.22.4.