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

[Dai, Jianhui J]

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-bounces at ffmpeg.org> On Behalf Of Derek Buitenhuis
Sent: Tuesday, March 10, 2020 10:40 PM
To: ffmpeg-devel at 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.dai at 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 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".