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 _______________________________________________ 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".
