v4l2videodec: Does not reusing the right buffer index when doing dmabuf import on capture

[ND] For decoders that produces primary buffer (same as reference frames), this will have the side effect of confusing the driver. Some information about references like motion vectors may be lost, and the output will get corrupted. It is impossible with the v4l2bufferpool, this is the last bit of the original code in that element that must go away.

seem some issue within dmabuf-import for capture ? (gst_v4l2_buffer_pool_process for capture dmabuf import ,in this case , gstreamer do not bind v4l2 buffer index and fd)

i have a use case , v4l2videodec capture-io-mode=dmabuf-import ! XXXVideoSink

i add proposal allocation function in XXXVideoSink plugin, that will proposal dma fd for v4l2videodec plugin, the flow work, but that sometimes result in **corruption of decoded frames **

the reason is v4l2 decoder need fd should bind with v4l2 buffer index, but gstreamer Gstv4l2bufferpool seem not ensure that, if not, this may result in corruption of decoded frames

i notice in this line, gstreamer will dqbuf v4l2 buf, get fd_0 from it , and acquire another dma fd from downstream bufferpool, and qbuf this new fd_1 into same v4l2 index. https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/v4l2/gstv4l2bufferpool.c#L1973

according to v4l2 spec, we have this, spec seem need binding between fd and v4l2 buffer index https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html

The backing memory of CAPTURE buffers that are used as reference frames by the stream may be read by the hardware even after they are dequeued. Consequently, the client should avoid writing into this memory while the CAPTURE queue is streaming. the client should make sure that each CAPTURE buffer is always queued with the same backing memory for as long as the CAPTURE queue is streaming.

is there any comment about this issue？ or any comment about gstv4l2bufferpool.c flow for capture-io-mode=dmabuf-import ?