[Bug 707534] New: BufferPool don't buffer GstMemory in 1.x

[GStreamer (bugzilla.gnome.org)]

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

           Summary: BufferPool don't buffer GstMemory in 1.x
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: olivier.crete at ocrete.ca
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: wim.taymans at gmail.com,
                    rob.krakora at messagenetsystems.com
            Blocks: 682770,699382,699517,705678,706083
     GNOME version: ---


In 1.x, the GstBufferPool only keep track of the GstBuffer structures, not of
the GstMemory, so they don't keep track of the underlying memory, it also means
that the buffers that are released back into the buffer pools may contain
completely different memory from what they originally had. This causes numerous
bugs (#699517, #706083, #699382, #705678, #682770, etc). This also forces
v4l2src to set all the memory as NO_SHARE, forcing useless copies, etc.

I propose to make GstBufferPools track GstMemory independently from the
Buffers.

My approach is multi-step:

1. We need GstMemory to have a dispose method like GstBuffer. The problem is
that to make it useful, we need to attach some userdata to the GstMemory,
sadly, the GstMemory structure is not extensible. So I propose a nasty hack
where the subclasses of GstMemory provide the storage and register an offset
into the GstAllocator.

2. I made the GstBufferPool keep track of the GstMemory and set itself has the
dispose handler, when a buffer is released, it will now do
gst_buffer_remove_all_memory() to allow the memory to return to the pool.

3. I added the possibility for GstAllocators to keep track of all memory they
have allocated and a method on the allocator to wait until all that memory has
been released.

4. I added a method to GstBufferPool to say if they require their memory back
before being de-activated and I modified GstBaseSrc (as an example) to do a
drain query before deactivating the pool if required.

I also made dmabuf not a singleton (API change, this bit should probably go in
before 1.2 is released), this way, it can keep track of the allocated memory. I
haven't tested dmabuf as it means testing on a 

I also implemented all of this in v4l2src as an example:

1. Added a Allocator for V4l2 in MMAP mode (not DMABUF).

2. Removed the GstV4l2Meta, instead attaching this info (struct v4l2_buffer) to
the GstMemory using qdata. I can't put it into the GstV4l2MmapMemory because
one could also be using the GstDmaBufAllocator. This means I significantly
refactored v4l2bufferpool to track GstMemories as well as GstBuffers.. The v4l

3. Added code to wait for all buffers before trying to do REQBUFS(0)

4. Implemented calling the drain query if required.

Branches:
http://cgit.collabora.com/git/user/tester/gstreamer.git/log/?h=memory-pool
http://cgit.collabora.com/git/user/tester/gst-plugins-base.git/log/?h=memory-pool
http://cgit.collabora.com/git/user/tester/gst-plugins-good.git/log/?h=v4l2-alloc

This is not merge-ready, it needs more testing and is not fully documented, but
I'd appreciate everyone's opinion on the approach. Wim's release-pool style
query (from bug #682770 comment #14) where draining the pipeline is not require
woudl be better, but drain works as a first step, making a better query can be
done later without breaking API.

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