Thanks, I will update the commit message. I test it with FFmpeg native sw H264 decoder. In previous FF_THREAD_FRAME, the latency is constant as N ( = thread_count - 1) frames. It won't sync thread state until no idle threads available, therefore N frames are cached internal, even some frames are ready for output. E.g. in RTSP 30fps streaming playback, 16 frame threads (default), the internal frame caching contributes 495ms(33ms x 15frame) latency. And the latency is the same, regardless the video resolution is 640x480 or 4320x2160.
In this patch, I attempt to check thread state and try best output frame to reduce the constant frame caching latency. Thanks, Jianhui Dai -----Original Message----- From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Carl Eugen Hoyos Sent: Tuesday, March 10, 2020 6:19 PM To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency Am Di., 10. März 2020 um 10:37 Uhr schrieb Jianhui Dai <jianhui.j....@intel.com>: > > Avoid constant N frames latency in video streaming. Please add some numbers to the commit message, if possible without using hardware acceleration. Carl Eugen _______________________________________________ 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". _______________________________________________ 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".
