[FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency

[Dai, Jianhui J]

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-bounces at ffmpeg.org> On Behalf Of Kieran Kunhya
Sent: Wednesday, March 11, 2020 11:41 AM
To: FFmpeg development discussions and patches <ffmpeg-devel at 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.dai at 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 at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".