On Thu, 09. Apr 00:27, Andriy Gelman wrote: > On Thu, 09. Apr 02:14, Ming Qian wrote: > > 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. > > > > I tend to agree with you. Even if eos event is not setup/supported, we should > be able to set ctx->done=1 via the EPIPE error. > > But let's wait for some more comments. >
In [1] it says that capture buffers should be enqueued back to the device while draining. I'll apply this patch on Wednesday if no one objects. [1] https://patchwork.kernel.org/patch/11110031/ "...The client must continue to handle both queues independently, smilarly to normal encode operation. This includes: * queuing and dequeuing ``CAPTURE`` buffers, until a buffer marked with the ``V4L2_BUF_FLAG_LAST`` flag is dequeued, ... " -- Andriy _______________________________________________ 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".
