After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777841 - waylandsink: fix buffer size when copying to pool
waylandsink: fix buffer size when copying to pool
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal normal
: 1.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2017-01-27 16:07 UTC by Fabien Dessenne
Modified: 2017-02-22 09:36 UTC
See Also:
GNOME target: ---
GNOME version: ---

waylandsink: consider buffer size (2.47 KB, patch)
2017-01-27 16:07 UTC, Fabien Dessenne
none Details | Review
[v2] waylandsink: consider buffer size (2.42 KB, patch)
2017-01-30 10:11 UTC, Fabien Dessenne
none Details | Review
[v3] waylandsink: consider buffer size (2.37 KB, patch)
2017-02-16 17:39 UTC, Fabien Dessenne
committed Details | Review

Description Fabien Dessenne 2017-01-27 16:07:23 UTC
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
Comment 1 Nicolas Dufresne (ndufresne) 2017-01-27 17:13:24 UTC
Review of attachment 344429 [details] [review]:

I think this is correct, just move out the assignment out of the loop please.

::: ext/wayland/gstwaylandsink.c
@@ +649,3 @@
       sink->video_info.offset[i] = vmeta->offset[i];
       sink->video_info.stride[i] = vmeta->stride[i];
+      sink->video_info.size = mem->size;

Written this way, it looks wrong, as you endup overriding over and over with the same value. I think for anything shm we already ensure there is only 1 mem, so the code is right, I would just pull that out of the loop.
Comment 2 Fabien Dessenne 2017-01-30 10:11:38 UTC
Created attachment 344519 [details] [review]
[v2] waylandsink: consider buffer size

Move size assignment out of the loop, as suggested by Nicolas
Comment 3 Fabien Dessenne 2017-02-16 17:39:34 UTC
Created attachment 345977 [details] [review]
[v3] waylandsink: consider buffer size

Removed "Signed-off-by"
Comment 4 Nicolas Dufresne (ndufresne) 2017-02-22 09:23:19 UTC
Review of attachment 345977 [details] [review]:

Looks good.
Comment 5 Nicolas Dufresne (ndufresne) 2017-02-22 09:26:59 UTC
Commited in master e2dffab9bee8611b0daa818806f36541bfedde26
Comment 6 Nicolas Dufresne (ndufresne) 2017-02-22 09:36:43 UTC
In 1.10 as fb2e63c468321a1691e06c5aad22df7559e1bd54