omxbufferpool: refactor to allow memory sharing
authorGeorge Kiagiadakis <george.kiagiadakis@collabora.com>
Fri, 22 Mar 2019 10:11:13 +0000 (12:11 +0200)
committerGuillaume Desmottes <guillaume.desmottes@collabora.com>
Thu, 25 Apr 2019 03:39:40 +0000 (09:09 +0530)
commit783e58fc48d9556d6b9a31be1b2009f230640de4
treef3b650f923510c4aa8732bf0d8cd10286913bb56
parent3018ea584361e88b45f6627141a9ac064d6cd4bc
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.
omx/Makefile.am
omx/gstomxallocator.c [new file with mode: 0644]
omx/gstomxallocator.h [new file with mode: 0644]
omx/gstomxbufferpool.c
omx/gstomxbufferpool.h
omx/gstomxvideoenc.c
omx/meson.build