As reply in another thread, the sequence of output frames still follows standard, like display order POC in H264. Big enough frame cache can guarantee deterministic delay in some extent, but not always (decoding time > caching time).
E.g. in FF_THREAD_FRAME 4320x2160 30fps video streaming, 4 threads, the frame caching is 99ms (33ms x 3frames) If the cpu-decoding-execution-time is 80ms ~ 120ms (dependent on video frame content). The const frame latency cannot be met. Thanks, Jianhui Dai -----Original Message----- From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Derek Buitenhuis Sent: Tuesday, March 10, 2020 10:40 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency On 10/03/2020 09:36, Jianhui Dai wrote: > Avoid constant N frames latency in video streaming. > > Signed-off-by: Jianhui Dai <jianhui.j....@intel.com> > --- > libavcodec/pthread_frame.c | 17 ++--------------- > 1 file changed, 2 insertions(+), 15 deletions(-) In addition to the points already raised (and which I agree with) about calculable N frames delay vs unknowable delay (which affects frame accurate seeking), I have one other point/question: Does this not make the delay non-deterministic depending on which threads finish first? - Derek _______________________________________________ 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".
