[Bug 706083] v4l2src: UVC Allocated buffers wrapped in GstBuffer get orphaned by GstBuffer API

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=706083
  GStreamer | gst-plugins-good | git

--- Comment #25 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2013-09-19 20:00:17 UTC ---
(In reply to comment #21)
> Review of attachment 255308 [details]:
> 
> ::: sys/v4l2/gstv4l2bufferpool.c
> @@ +681,2 @@
>    index = meta->vbuffer.index;
> +  meta->vbuffer.bytesused = meta->vbuffer.length;
> 
> So, vbuffer.length is the size of the v4l2 buffer and vbuffer.bytesused the
> actual number of bytes used in the buffer.  So, IMHO, this should be valid. 
> The meta data obtained from the GstBuffer is used to obtain the length of the
> vbuffer.

In this case, the buffer length is what the application put into it (for
v4l2sink), which may be smaller than the allocated buffer.

> @@ +695,3 @@
> +    gst_memory_new_wrapped (GST_MEMORY_FLAG_NO_SHARE,
> +        meta->mem, meta->vbuffer.length, 0, meta->vbuffer.length, NULL,
> +        NULL));
> 
> Why not?

Again in the v4l2sink case, the application has written something in the memory
that's in the buffer, so you can't just ignore it.


> @@ +794,3 @@
> +            meta->mem, vbuffer.bytesused, 0, vbuffer.bytesused, NULL,
> +            NULL));
> +  /* with vbuffer.bytesused as the size and replace the    */
> 
> Huh?  gst_buffer_resize() is the problem.  It can replace the wrapped memory
> object referenced by the GstBuffer with a new one that meets the new size
> constraint and then the previously wrapped memory object, which wraps a v4l2
> buffer, is "lost in space".

In this case, it will only shrink the buffer, so that should never happen.

> @@ +800,2 @@
>    *buffer = outbuf;
> +  GST_V4L2_BUFFER_POOL_UNLOCK (pool);
> 
> Trying to protect the pool structure from being accessed on different thread
> times.  I am assuming that a buffer can get dequeued on another thread time.

The same buffers[x] member will only be accessed once you got the buffer back
from the kernel, so only that thread owns it at this point.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.