[Bug 775564] v4l2 1.10 Regression: white pixels with camera on Raspberry Pi & gstgl

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #6 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Here's the result of my analyses. From the trace we have.

> Got format of 320x200, format YUYV, nb planes 1, colorspace 1
> stride 640, sizeimage 133120

The S_FMT implementation in this driver is weird since the required image size
should be srtide * height =  640 * 200 = 128000.

In the most recent code, we can notice that we copy that size into the video
info structure:

> info->size = format->fmt.pix.sizeimage;

And that value will later be used for sanity check. So what happens is that
when we dequeue, the driver report the proper size:

> dequeued buffer 0x63038f20 seq:0 (ix=1), mem 0x630552f0 used 128000

But the sanity check fails.

> Invalid buffer size, this is likely due to a bug in your driver, dropping

Now, this check was added to detect short image produced upon corruption
(system not being real-time anymore). Normally this is not an issue, but there
is a bug in this driver apparently. There is also a relationship with the size
set in buffer pool. This was all to avoid userspace using buffer with that was
short allocated by the driver (which can crash the userspace app).

In this case, the driver seems to suggest that extra space is being allocated,
so maybe we can find a way to survive this driver bug.

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