On Sun, 26. Apr 23:50, Andriy Gelman wrote: > 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. >
Applied. Thanks, -- 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".
