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. -- 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".
