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

[Derek Buitenhuis]

On 11/03/2020 03:28, Dai, Jianhui J wrote:
> 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).

That was my point. As an API user, I *do not want* the headache of a non-deterministic amount of delay,
both from a debugging standpoint, and a usability standpoint. Purposely adding non-determinism in this
way gets a NAK from me, for whatever my opinion is worth on this list...

(Aside: Having a calculable and deterministic is important for frame-accurate seeking (using
e.g. a packet-to-frame map), since you *cannot* just 'decode until $timestamp', since monontonic timestamps
aren;t a guaranatee in reality (e.g. MPEG_-TS)).

> 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).

Also aside: It is not useful to measure frame delay in time. It's also not, IMO, maningful to use
in-flight (wallclock) time.

> The const frame latency cannot be met.

[...]

- Derek