mmaldec: fix problems with flush logic
Don't try to do a blocking wait for MMAL output if we haven't even sent
a single real packet, but only flush packets. Obviously we can't expect
to get anything back.
Additionally, don't send a flush packet to MMAL in the same case. It
appears the MMAL decoder will sometimes hang in mmal_vc_port_disable()
(called from ffmmal_close_decoder()), waiting for a reply from the GPU
which never arrives. Either MMAL disallows sending flush packets without
preceding real data, or it's a MMAL bug.
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index e2c2e57..a749b89 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -445,8 +445,6 @@
uint8_t *start;
int ret = 0;
- ctx->packets_sent++;
-
if (avpkt->size) {
if (ctx->bsfc) {
uint8_t *tmp_data;
@@ -472,6 +470,14 @@
}
size = buf->size;
data = buf->data;
+ ctx->packets_sent++;
+ } else {
+ if (!ctx->packets_sent) {
+ // Short-cut the flush logic to avoid upsetting MMAL.
+ ctx->eos_sent = 1;
+ ctx->eos_received = 1;
+ goto done;
+ }
}
start = data;
@@ -641,7 +647,8 @@
// excessive buffering.
// We also wait if we sent eos, but didn't receive it yet (think of decoding
// stream with a very low number of frames).
- if (ctx->frames_output || ctx->packets_sent > MAX_DELAYED_FRAMES || ctx->eos_sent) {
+ if (ctx->frames_output || ctx->packets_sent > MAX_DELAYED_FRAMES ||
+ (ctx->packets_sent && ctx->eos_sent)) {
// MMAL will ignore broken input packets, which means the frame we
// expect here may never arrive. Dealing with this correctly is
// complicated, so here's a hack to avoid that it freezes forever
