[gstreamer-bugs] [Bug 619500] New: It is not possible to "recycle" buffers without subclassing GstBuffer object

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=619500
  GStreamer | gstreamer (core) | 0.10.29

           Summary: It is not possible to "recycle" buffers without
                    subclassing GstBuffer object
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.29
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ext-tommi.myohanen at nokia.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Created an attachment (id=161849)
 View: https://bugzilla.gnome.org/attachment.cgi?id=161849
 Review: https://bugzilla.gnome.org/review?bug=619500&attachment=161849

Patch which adds weak reference handling to GstMiniObject

Imagine a following situation: 

there is a video source element which wants to use buffer pool to recycle same
buffers over and over again (HW requires it) AND use gst_pad_alloc_buffer() to
pre-allocate the buffers from downstream (video sink) element to enable
optimized (zero-copy) video rendering. 

But, this is not possible, because source element must create its own GstBuffer
subclass in order to overwrite GstMiniObject::finalize() function for
resurrecting the rendered and unref'ed video buffers. There is no other way to
recycle the used buffers than this. And using subclassed GstBuffer prevents the
use of gst_pad_alloc_buffer() call.

There would be one hackish way do this: call pad_alloc(), store the obtained
GstBuffer pointer somewhere and steal its GST_BUFFER_DATA pointer. However,
video sink's zero-copy operation requires the pushed GstBuffers to be the same
ones which were allocated with pad_alloc(), so this wouldn't work.

I tried to solve this by adding a weak reference handling mechanism to
GstMiniObject. This way source element could just allocate the buffers with
gst_pad_alloc_buffer() and add a weak references to them. When sink unrefs a
buffer, weak reference notification callback would then resurrect the buffer
and queue it again to video device.

However, this turned out not to be reliable. Since these video buffers are
subclassed by sink element, it also has ability to resurrect them in finalize()
function. This leads into problems when source element's weak ref notification
has already been called, src doesn't want to resurrect the buffer, but sink
element decides to resurrect it. Now source element believes that buffer has
been destroyed, even it is still alive.

Another problem is that if also video sink has a pool for video buffers, then
rendered buffer will end up into this pool instead of freeing. If source
element gets notification about this and re-queues, captures and pushes a new
video frame by using this buffer, video sink might get confused because it
receives a buffer which should be still in its internal pool of unused buffers.

Attached is a patch which adds weak reference handling to GstMiniObject. It is
still WIP and contains some unnecessary debugs to keep track what's going on
there. I am not sure if this even is the right approach to try to solve this
problem, but let's consider it as a beginning of discussion.

-- 
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.