Did you try increasing the -num_capture_buffers option? It may solve your
problem.
1. We can't increase the num_capture_buffers indefinitely.
2. There is a ring buffer in driver, so the number of frames who is stored in
the ring buffer may be a large value, This depends on the speed of the input
and output. So it's likely that when output port is done, there are a large
count of frames who have not been decoded, if the capture port prevent qbuf to
driver, there will no frame buffer to store the decoded frame.
There is currently a check that sets ctx->done=1 when all the capture buffers
are dequeued (v4l2_context.c:300), and this patch would prevent it (although
it's not needed if an eos event is received).
Yes, but I think it's not appropriate to judge whether the capture port is done
by checking all the capture buffers are dequeued.
Best regards,
Ming Qian
Tel#:86-512-6805-6630
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Andriy Gelman
Sent: Thursday, April 9, 2020 9:21 AM
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] 回复: [EXT] Re: [PATCH] avcodec/v4l2_buffers: don't
prevent enqueue capture buffer to driver
Caution: EXT Email
On Tue, 17. Mar 10:28, Ming Qian wrote:
> Yes, I have meet some hang issue on nxp's imx platform.
> On nxp's imx platform, there is a stream buffer in the v4l2 decoder driver.
> So driver may cache some frames in driver, if without this patch, after the
> draining is set to 1, the v4l2 capture buffer won't be enqueued to driver any
> more, it leds to hang.
Did you try increasing the -num_capture_buffers option? It may solve your
problem.
There is currently a check that sets ctx->done=1 when all the capture buffers
are dequeued (v4l2_context.c:300), and this patch would prevent it (although
it's not needed if an eos event is received).
Perhaps Mark/Aman could also comment?
Thanks,
Andriy
>
> ________________________________
> 发件人: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> 代表 Andriy Gelman
> <andriy.gel...@gmail.com>
> 发送时间: 2020年3月16日 20:07
> 收件人: FFmpeg development discussions and patches
> <ffmpeg-devel@ffmpeg.org>
> 主题: [EXT] Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_buffers: don't
> prevent enqueue capture buffer to driver
>
> Caution: EXT Email
>
> On Mon, 16. Mar 10:02, Ming Qian wrote:
> > the draining is set when the output port is finished, but it doesn't
> > mean the capture port is finished.
> > especially for decoder, there may be a stream buffer to store
> > several frames.
> > so the decoder still need capture buffer even if the draining is set.
> >
> > Signed-off-by: Ming Qian <ming.q...@nxp.com>
> > ---
> > libavcodec/v4l2_buffers.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> > index dc1b9eaf24..02f23d954b 100644
> > --- a/libavcodec/v4l2_buffers.c
> > +++ b/libavcodec/v4l2_buffers.c
> > @@ -222,7 +222,7 @@ static void v4l2_free_buffer(void *opaque, uint8_t
> > *unused)
> > if (!atomic_load(&s->refcount))
> > sem_post(&s->refsync);
> > } else {
> > - if (s->draining) {
> > + if (s->draining &&
> > + V4L2_TYPE_IS_OUTPUT(avbuf->context->type)) {
> > /* no need to queue more buffers to the driver */
> > avbuf->status = V4L2BUF_AVAILABLE;
> > }
>
> It makes sense, but did you have some dropped frames without this?
>
> Thanks,
> --
> Andriy
--
Andriy
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=02%7C01%7Cming.qian%40nxp.com%7C844f51e7c2ab4305258208d7dc244e50%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637219920796329565&sdata=8H9G2dDXCnmfKpndO8FHcwlSjS%2F4QJMj0PAEhQMygH0%3D&reserved=0
To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with
subject "unsubscribe".
_______________________________________________
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".
