On Mon, 27. Apr 16:28, Andriy Gelman wrote: > Hi Ming, > > Thanks for looking over the patch. > > On Thu, 09. Apr 07:13, Ming Qian wrote: > > Lgtm, > > > > But if don't prevent enqueue frame buffer of capture port, unlikely to > > happen this case. > > The problem happens when all the capture packets/frames are buffered > internally > by ffmpeg (i.e. the buffer state is V4L2BUF_RET_USER). > > I see it on the s5p-mfc even with your patch: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200316020208.27547-1-ming.q...@nxp.com/ > > > And I think we can get a proper num_frame_buffers by g_ctrl > > V4L2_CID_MIN_BUFFERS_FOR_CAPTURE and V4L2_CID_MIN_BUFFERS_FOR_OUTPUT. > > > > The values for V4L2_CID_MIN_BUFFERS_FOR_CAPTURE and > V4L2_CID_MIN_BUFFERS_FOR_OUTPUT are the minimum values for the hardware device > and are lower than our defaults. I don't think we should use the minimum > values > because the frames/packets may be buffered. > > There is another option to request additional buffers via > CREATE_BUFS ioctl, but it's not supported by all hardware (thanks to ndufresne > on #v4l for suggesting). I feel adding this ioctl should be a separate patch > and we > still need a warning if it's not supported. > > 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".
