On Wed, 11 Mar 2020 at 02:29, Dai, Jianhui J <jianhui.j....@intel.com> wrote:
> 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 > Unless I misunderstand, surely this outputs frames nondeterministically? i.e you don't know that the thread which has finished is the next one that is due Not to mention the variable latency problems. Kieran _______________________________________________ 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".
