]> git.sesse.net Git - nageru-docs/blobdiff - hdmisdi.rst
Document unsynchronized HDMI/SDI output.
[nageru-docs] / hdmisdi.rst
index 30fc5eef5256f8222b1d09cf782a4dc05226014e..a04c62ba3d09336680d80acb5d6936a2f75e90a8 100644 (file)
@@ -8,14 +8,14 @@ the stream on another PC, but for many uses, the end-to-end latency is
 too high, and you might not want to involve a full extra PC just for this
 anyway.
 
-Thus, since 1.5.0, Nageru supports using a spare output card for HDMI/SDI
+Thus, Nageru supports using a spare output card for HDMI/SDI
 output, turning it into a simple, reasonably low-latency audio/video switcher.
 
 
 Setting up HDMI/SDI output
 --------------------------
 
-Turning on HDMI/SDI output is simple; just right-click on the live view and
+To turn on HDMI/SDI output, right-click on the live view and
 select the output card. (Equivalently, you can access the same functionality
 from the *Video* menu in the regular menu bar, or you can give the
 *--output-card=* parameter on the command line.) Currently, this is supported
@@ -26,11 +26,23 @@ keep running just as before.
 A video mode will automatically be picked for you, favoring 59.94 fps if possible,
 but you can change the mode on-the-fly to something else if you'd like,
 as long as the resolution matches with what you've set up at program start.
-Note that whenever HDMI/SDI output is active, the output card will be the
+
+
+Unsynchronized HDMI/SDI output
+------------------------------
+
+By default, whenever HDMI/SDI output is active, the output card will be the
 master clock; you cannot change it to any of the input cards. This also means
 that the frame rate you choose here will determine the frame rate for the
 stream.
 
+In Nageru 2.1.0 or newer, you can use the flag --output-card-unsynchronized
+to counteract this (there is currently no way to do it from the GUI).
+This is for if you want just a monitor output without synchronizing
+your entire stream chain to the output card (ie., you want to keep
+some other camera as the master). Sound support is untested, and is
+probably going to crackle a fair bit.
+
 
 A note on latency
 -----------------
@@ -171,7 +183,7 @@ Measuring latency
 
 In order to optimize latency, it can be useful to measure it, but for most
 people, it's hard to measure delays precisely enough to distinguish reliably
-between e.g. 70 and 80 milliseconds by eye alone. Nageru gives you some simple
+between e.g. 70 and 80 milliseconds by eye alone. Nageru gives you some
 tools that will help.
 
 The most direct is the flag *--print-video-latency*. This samples, for every
@@ -196,6 +208,12 @@ 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,
@@ -203,7 +221,7 @@ 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 e.g. shifts [#]_.
-See the section on :ref:`the frame analyzer <analyzer>` for other ways of
+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