Fix wording about border colors

[nageru-docs] / hdmisdi.rst

diff --git a/hdmisdi.rst b/hdmisdi.rst
index 064fe85aef8c90cbc6ddf75ec846c31b6d1b14d6..f6f032cf48a29df3c27cb9e6a4b8359a2242d6d2 100644 (file)
--- a/hdmisdi.rst
+++ b/hdmisdi.rst
@@ -164,6 +164,8 @@ Audio and video queue lengths do not need to match exactly; the two streams
 and for HDMI/SDI output.
 
 
+.. _measuring-latency:
+
 Measuring latency
 .................
 
@@ -194,13 +196,21 @@ lowest and highest will be printed. Do note that the measurement is still done
 over a single *output* frame; it is *not* a measurement over the last 100
 output frames, even though the statistics are only printed every 100th.
 
+For more precise measurements, you can use Prometheus metrics to get percentiles
+for all of these points, which will measure over all frames (over a one-minute
+window). This yields more precise information than sampling every 100 frames,
+but setting up Prometheus and a graphic tool is a bit more work, and usually not
+worth it for simple measurement. For more information, see :doc:`monitoring`.
+
 Another trick that can be useful in some situations is *looping* your signal,
 ie., connecting your output back into your input. This allows you to measure
 delays that don't happen within Nageru itself, like any external converters,
 delays in the input driver, etc.. (It can also act as a sanity check to make
 sure your A/V chain passes the signal through without quality degradation,
 if you first set up a static picture as a signal and then switch to the loop
-input to verify that the signal stays stable without color shifts e.g. [#]_)
+input to verify that the signal stays stable without color e.g. shifts [#]_.
+See the section on :doc:`the frame analyzer <analyzer>` for other ways of
+debugging signal integrity.)
 
 For this, the *timecode output* is useful; you can turn it on from the Video
 menu, or through the command-line flag *--timecode-stream*. (You can also