Skip to content
  • George Kiagiadakis's avatar
    omxbufferpool: refactor to allow memory sharing · 783e58fc
    George Kiagiadakis authored and Guillaume Desmottes's avatar Guillaume Desmottes committed
    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.
    783e58fc