In offline transcoding mode, max latency is controllable. But in video streaming usages, we can not expect to know the max latency in advance, even decoder cannot know. Like RTSP/RTMP/DASH, the latency is variable according to network bandwidth. Let video sink or renderer in the of pipeline to control the frame caching size is more flexible.
Thanks, Jianhui Dai -----Original Message----- From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Kieran Kunhya Sent: Wednesday, March 11, 2020 11:41 AM To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency On Wed, 11 Mar 2020 at 02:59, Dai, Jianhui J <jianhui.j....@intel.com> wrote: > It does not break FFmpeg output frames management logic (e.g. > h264_select_output_frame), just enter that phase earlier. > > Perhaps my understanding is not correct. > In my opinions, render should be the one considering variable latency > issue, instead of decoder. > How does the renderer know what the maximum latency of the upstream pipeline is? 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". _______________________________________________ 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".
