Created attachment 344429 [details] [review]
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