aboutsummaryrefslogtreecommitdiffstats
path: root/tests/ref/fate/bmp-rle4
diff options
context:
space:
mode:
authorwm4 <nfxjfg@googlemail.com>2015-09-23 20:27:25 +0200
committerLuca Barbato <lu_zero@gentoo.org>2015-10-04 19:34:04 +0200
commit39f01e346cab464ef6c0d4ec58cc13b7123e60d8 (patch)
tree764df326624c7030e678b9cc68f52f230f05bca4 /tests/ref/fate/bmp-rle4
parent65db4899fa8790049bec3af16ecdb75dd81051fd (diff)
downloadffmpeg-39f01e346cab464ef6c0d4ec58cc13b7123e60d8.tar.gz
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>
Diffstat (limited to 'tests/ref/fate/bmp-rle4')
0 files changed, 0 insertions, 0 deletions