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 <[email protected]> On Behalf Of Derek Buitenhuis Sent: Tuesday, March 10, 2020 10:40 PM To: [email protected] 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 <[email protected]> > --- > 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 [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
