From 478db1ec8d01d5989a0a6eb84ca45525fb8aa4f7 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" Date: Fri, 31 Mar 2017 17:47:01 +0200 Subject: [PATCH] Started writing about controlling latency. --- hdmisdi.rst | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/hdmisdi.rst b/hdmisdi.rst index 339e64c..2d0d6c4 100644 --- a/hdmisdi.rst +++ b/hdmisdi.rst @@ -101,7 +101,24 @@ tradeoffs must be made. The most important sources of latency are: The 4K series in this context include everything that have “4K” in their names, plus the Mini Recorder, Duo 2 and Quad 2 devices. -TODO: Write about queuing options. And latency measurements. And audio. +Controlling latency +................... + +Of the different sources of latency outlined in the previous section, +the only one that is really under your control (short of buying faster +or better hardware) is the input queue latency. By default, Nageru +attempts to strike a balance between reducing latency and having to +drop frames due to jitter; by looking at each queue's input length +history, it attempts to find a “safe queue limit”, above which it +can drop frames without risking underrun (which requires duplicating +frames). However, if latency is more important to you than 100% smooth +motion, you can override this by using the *--max-input-queue-frames=* +flag; this is a hard limit on the number of frames that can be kept +in the queue, on top of Nageru's own heuristics. It cannot be set lower +than 1, or else all incoming frames would immediately get dropped +on arrival. + +TODO: Write about output queuing options. And latency measurements. And audio. TODO: Write something about time codes here. -- 2.39.2