mmaldec: be more tolerant against MMAL not returning decoded output
authorwm4 <nfxjfg@googlemail.com>
Wed, 23 Sep 2015 18:27:25 +0000 (20:27 +0200)
committerLuca Barbato <lu_zero@gentoo.org>
Sun, 4 Oct 2015 17:34:04 +0000 (19:34 +0200)
commit39f01e346cab464ef6c0d4ec58cc13b7123e60d8
tree764df326624c7030e678b9cc68f52f230f05bca4
parent65db4899fa8790049bec3af16ecdb75dd81051fd
mmaldec: be more tolerant against MMAL not returning decoded output

In some situations, MMAL won't return a decoded frame for certain input
frames. This can happen if a frame fails to decode, or if a packet does
not actually contain a complete frame. In these situations, we would
deadlock (or actually timeout) waiting for an expected output frame,
which is not ideal. On the other hand, there are situations where we
definitely have to block to avoid deadlocks. (This mess is a
consequence of trying to map MMAL's asynchronous and flexible
dataflow to libavcodec, which is more static and rigid.)

Solve this by doing a blocking wait only if the amount of buffered data
is too big. The whole purpose of the blocking wait is to avoid excessive
buffering of input data, so we can skip it if it appears to be low. The
consequence is that libavcodec can gracefully return no frame to the
API user.

We want to track the number of full packets to make our heuristic work.
But MMAL buffers are fixed-size, requiring splitting large packets. This
is why the previous commit is needed. We use the ..._FRAME_END flag to
remember packet boundaries, but MMAL does not preserve these buffer
flags when returning buffers to the user.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
libavcodec/mmaldec.c