[Bug 724481] New: bufferpool: Doesn't reset buffers when releasing them to the pool

[GStreamer (bugzilla.gnome.org)]

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

           Summary: bufferpool: Doesn't reset buffers when releasing them
                    to the pool
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: slomo at coaxion.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: wim.taymans at gmail.com
     GNOME version: ---


gst-launch-1.0 videotestsrc num-buffers=2 ! y4menc ! fakesink


This gives lots of errors about zero-sized buffers. Happens because
videotestsrc uses its own video buffer pool, y4menc steals the memory of these
buffers and unrefs them. Then GstBufferPool just releases them back to the
queue, and next time a buffer is acquired we get a buffer without any memory in
videotestsrc.

Not sure how to fix that properly. First of all, how do we detect that a buffer
is invalid now? It might have different memory than before, or none at all, or
the allocation metas could've changed, or the buffer is still the same but the
memory is *also* shared with another buffer (and thus not writable), or ...

Then, what to do with such buffers? Just unref and forget them instead of
putting back to the queue? That's going to cause problems as the memory could
still be in another buffer and maybe we're not able to allocate a new buffer
until that memory is released again. Or the buffer pool really needs to get the
memory back for proper tracking of memories (meaning we actually have a memory
pool that claims to be a buffer pool...).

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