Bug 103063

Something's wrong with either Weston's I420/SHM import path (wouldn't be surprised if it was that), or GStreamer's usage of the same. This works around it, with obvious performance consequences:
gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,format=(string)RGB ! waylandsink

First, it would be interesting to validate how GStreamer is rendering the buffer. It should be laid out, in order:
Y plane: offset == 0, stride == (width * 1), i.e. 1bpp, size == (stride * height), i.e. full height
U plane: offset == size[Y], stride == (width/2 * 1), i.e. 1bpp but half width, size == (stride * height/2), i.e. half height
V plane: offset == offset[U] + size[U], stride == (width/2 * 1), size == (stride * height/2), i.e. half width/height

If GStreamer is rendering correctly, this comes in to Weston at libweston/gl-renderer.c's gl_renderer_attach_shm(). In the YUV420 case (aka GStreamer's I420), this sets up the textures as described above. It then uploads the content in gl_renderer_flush_damage(), where it uploads according to the parameters set in attach_shm.

It looks from a quick inspection of the code that this is done correctly (i.e. dividing by hsub/vsub to halve the dimensions of the U/V planes), but it would be good to validate the parameters passed to glTex(Sub)Image2D() for the upload, after validating GStreamer's buffer layout.

Weston fix: https://patchwork.freedesktop.org/patch/180767/

I test the patch and everything works fine now.

This landed in the tree a while ago.