omxbufferpool: refactor to allow memory sharing

One big restriction of the OMX buffer pool has always been
that the GstMemory objects were flagged with NO_SHARE.
This was because the buffer pool needed to be sure that when
a buffer returned to the pool, it would be safe to release the
OMX buffer back to OpenMAX.

With this change, this is no longer a restriction. What this
commit introduces is a new allocator that allows us to track
the GstMemory objects independently. Now, when a buffer returns
to the pool, it is not necessary for the memory to be released
as well. We simply track the memory's ref count in the allocator
and we return the OMX buffer back when the memory's ref count
drops to 0.

The reason for doing this is to allow implementing zero-copy
transfers in situations where we may need to copy or map a
certain region of the buffer. For instance, omxh264enc ! h264parse
should be possible to be zero-copy by using an OMX buffer pool
between them.

1 files changed, 2 insertions, 1 deletions

diff --git a/omx/gstomxbufferpool.h b/omx/gstomxbufferpool.h
index a09c825..bc5ac60 100644
--- a/omx/gstomxbufferpool.h
+++ b/omx/gstomxbufferpool.h
@@ -30,6 +30,7 @@
 #include <gst/video/gstvideopool.h>
 
 #include "gstomx.h"
+#include "gstomxallocator.h"
 
 G_BEGIN_DECLS
 
@@ -65,7 +66,7 @@ struct _GstOMXBufferPool
   GstOMXPort *port;
 
   /* For handling OpenMAX allocated memory */
-  GstAllocator *allocator;
+  GstOMXAllocator *allocator;
 
   /* Set from outside this pool */
   /* TRUE if the pool is not used anymore */