omxbufferpool: fix early input buffer release
authorGuillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Thu, 15 Nov 2018 10:17:59 +0000 (11:17 +0100)
committerGuillaume Desmottes <guillaume.desmottes@collabora.com>
Fri, 21 Dec 2018 16:16:31 +0000 (17:16 +0100)
commit3828d9769c74e3c66342a1f78848397982ac2f6e
treee0c992252363d9e5293f8ee1716da310b4f9d712
parentf17b12c4f9fc220924fc4daed358575b4613ba3a
omxbufferpool: fix early input buffer release

We used to track the 'allocating' status on the pool. It is used while
allocating so output buffers aren't passed right away to OMX and input
ones are not re-added to the pending queue.

This was causing a bug when exporting buffers to v4l2src. On start
v4l2src acquires a buffer, read its stride and release it right away.
As no buffer was received by the encoder element at this point, 'allocating'
was still on TRUE and so the the buffer wasn't put back to the pending
queue and, as result, no longer available to the pool.

Fix this by checking the active status of the pool instead of manually
tracking it down. The pool is considered as active at the very end of
the activation process so we're good when buffers are released during
the activation.
omx/gstomxbufferpool.c
omx/gstomxbufferpool.h
omx/gstomxvideodec.c
omx/gstomxvideoenc.c