Are SHM buffers with padding acceptable in waylandsink

General Discussion
1

We have a usecase with decoder and display where the decode and display run in two different processes. We use socket plugins for IPC.

Pipeline1: v4l2dec→socketsink
Pipeline2: socketsrc→waylandsink
NOTE: socketsrc and socketsink plugins described here are our custom plugins.

We use fd_allocator to wrap the fd in our socketsrc plugin.
So in waylandsink the SHM path is choosen to render the buffer.( subprojects/gst-plugins-bad/ext/wayland/gstwaylandsink.c · 1.28.2 · GStreamer / gstreamer · GitLab )

We noticed that in subprojects/gst-plugins-bad/gst-libs/gst/wayland/gstwlshmallocator.c · 1.28.2 · GStreamer / gstreamer · GitLab only the plane 0’s offset is used to consturct the wayland buffer. In our case the decoder’s output buffer has some padding after Y plane. UV plane starts at a different offset than default. So we see a green patch at the top of display (the padding between Y and UV plane).

The question we now have is: Is this a valid case?
Should buffers with additional padding use DMA allocator only. Or is there a way to have this working with SHM as well?

@ndufresne

2

The Wayland shm protocol does not allow padding, only dmabuf protocol allows that. To fix your problem, simply replace your custom socketsrc/sink with the upstream unixfdsink/unixfdsrc, this implementation already support passing over DMAbuf (not only fdmemory), and will also transmit the GstVideoMeta which is the meta holding the padding information.