[Bug 777841] New: waylandsink: fix buffer size when copying to pool

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=777841

            Bug ID: 777841
           Summary: waylandsink: fix buffer size when copying to pool
    Classification: Platform
           Product: GStreamer
           Version: 1.10.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fabien.dessenne at st.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 344429
  --> https://bugzilla.gnome.org/attachment.cgi?id=344429&action=edit
waylandsink: consider buffer size

When the sink receives a buffer that is neither a wl_shm one nor a dmabuf one,
this buffer is copied to an internal wl_shm buffer before being sent to the
display.
In that case, the actual size of the received buffer (which may differ from the
one negotiated in the caps) must be used.

-----

The proposed patch fixes a crash in weston that tries to access memory.
Reproducible with a B2260 96 board and the following pipeline:
gst-launch-1.0 videotestsrc ! "video/x-raw,format=BGRx" ! v4l2video0convert !
"video/x-raw, format=NV12, width=500, height=500" ! waylandsink

v4l2video0convert calls the B2260 driver that aligns width from 500 to 504.
Hence the buffer size is 504x500x1.5 bytes (cropped to 500x500)

---

The root caus of this issue is here:

    vmeta = gst_buffer_get_video_meta (buffer);
    if (vmeta) {
      gint i;
      for (i = 0; i < vmeta->n_planes; i++) {
        sink->video_info.offset[i] = vmeta->offset[i];
        sink->video_info.stride[i] = vmeta->stride[i];

video_info is updated for .offset & .stride, but .size is not updated, so we
have unconsistent parameters.
size shall be recomputed from offset[] and stride[] (as done by static
fill_planes() from gst-libs/gst/video/video-info.c). 
But since fill_planes() cannot be called from here, the proposed patch uses
mem->size. Better ideas are welcome

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.