A cleanup within the MMAL code which may help JC out.
Allocate a pool on an output port.
Fill a buffer from the pool
Allocate a pool on an input port.
mmal_buffer_header_replicate the filled buffer to a header from the new pool. The new buffer header acquires the source buffer header and retains a reference to it.
Destroy the output port pool. All resources are destroyed.
Release the replicated buffer header. It'll deref into the now destroyed pool :-o
The pool doesn't have a refcount at present. It would be nice to add a refcount for all buffer headers, but there is no "alloc" function , so all apps will just call mmal_queue_get on the pool's queue (hindsight and all that).
I think we can therefore only safely do this on replicated buffers where there is a defined API on how to alloc and release the buffers.
Further cleanup (I think) - if you destroy the input port pool with any buffers having been replicated and not released, then the reference to the output port pool is NOT cleaned up. That will leave buffers in the output pool in limbo until it is destroyed.
Locking and refcounting correctly is going to be "fun".
6by9
commented
6 years ago
A cleanup within the MMAL code which may help JC out.
The pool doesn't have a refcount at present. It would be nice to add a refcount for all buffer headers, but there is no "alloc" function , so all apps will just call mmal_queue_get on the pool's queue (hindsight and all that). I think we can therefore only safely do this on replicated buffers where there is a defined API on how to alloc and release the buffers.
Further cleanup (I think) - if you destroy the input port pool with any buffers having been replicated and not released, then the reference to the output port pool is NOT cleaned up. That will leave buffers in the output pool in limbo until it is destroyed.
Locking and refcounting correctly is going to be "fun".