[FFmpeg-devel] [PATCH 1/2] avcodec/v4l2_m2m_dec: add a dequeue_timeout parameter

[Lynne]

24 Mar 2022, 07:14 by ming.qian at nxp.com:

> the dequeue of capture queue will be blocked until
> decoded frame available or an input buffer is ready to be dequeued.
> but it may cause death waiting in some case.
> For example, it has enqueued the first input frame,
> and then blocks at ff_v4l2_context_dequeue_frame.
> For some reason, the decoder can't decode the first frame,
> also it can't return the input buffer. The decoder needs more input data
> to decode, so the decoder is just waiting.
> This creates some kind of deadlock.
>
> And in linux/Documentation/userspace-api/media/v4l/dev-decoder.rst,
> there are some descriptor like below:
> The client must not assume any direct relationship between CAPTURE and
> OUTPUT buffers and any specific timing of buffers becoming available to dequeue.
> Specifically:
> [snip]
> - a buffer queued to OUTPUT may result in a buffer being produced on CAPTURE
>  later into decode process, and/or after processing further OUTPUT buffers,
>  or be returned out of order, e.g. if display reordering is used,
>
> And I meet a similar case, there are 16 output buffers, but only one
> buffer is queued to driver, then blocks at
> ff_v4l2_context_dequeue_frame.
> But the decoder need more frame data, otherwise it won't decode it.
>
> So I think the client should keep processing OUTPUT buffers if there are
> available buffers until the end.
>
> To resolve it, I think we can set a reasonable timeout instead of -1.
> So I add a parameter dequeue_timeout, and it works on my side.
>

Adding a timeout isn't a fix, it's a hack. Can't the driver return EAGAIN
to ask for more data, or ENOBUFS if it has nothing to decode into?
Why hasn't this been needed so far?