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, 1 insertions, 0 deletions

diff --git a/omx/meson.build b/omx/meson.build
index b68cc55..1bcebf5 100644
--- a/omx/meson.build
+++ b/omx/meson.build
@@ -1,5 +1,6 @@
 omx_sources = [
   'gstomx.c',
+  'gstomxallocator.c',
   'gstomxbufferpool.c',
   'gstomxvideo.c',
   'gstomxvideodec.c',