24 Mar 2022, 07:14 by ming.q...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
