Update the video menu for time code.

[nageru-docs] / gettingstarted.rst

diff --git a/gettingstarted.rst b/gettingstarted.rst
index 68edc81605f53f7e8ab53412c9d72514cf6100d4..e2e37005d7bbbc607110019e807cbd0bec03c085 100644 (file)
--- a/gettingstarted.rst
+++ b/gettingstarted.rst
@@ -3,7 +3,7 @@ Getting started
 
 Welcome to Nageru! For simple use, you can jump right in and make yourself
 comfortable (at least if you have the :doc:`hardware requirements <hardware>`
 
 Welcome to Nageru! For simple use, you can jump right in and make yourself
 comfortable (at least if you have the :doc:`hardware requirements <hardware>`

-in place and have `compiled it <compile>`), but if you prefer a gentler introduction,
+in place and have `compiled it <compile>`_), but if you prefer a gentler introduction,

 this is the place.
 
 
 this is the place.
 
 


@@ -123,10 +123,12 @@ The video menu contains the following elements:
     You can achieve the same effect as this option by sending
     SIGHUP to the Nageru process.
 
     You can achieve the same effect as this option by sending
     SIGHUP to the Nageru process.
 

+  * **Open frame analyzer:** See :doc:`analyzer` for more information.
+

   * **Change x264 bitrate:** See :doc:`streaming` for more information.
 
   * **Change x264 bitrate:** See :doc:`streaming` for more information.
 

-  * **HDMI/SDI output device, HDMI/SDI output resolution:** See :doc:`hdmisdi`
-    for more information.
+  * **HDMI/SDI output device, HDMI/SDI output resolution, Display time code:**
+    See :doc:`hdmisdi` for more information.

 
   * **Exit:** Exits Nageru, obviously.
 
 
   * **Exit:** Exits Nageru, obviously.
 


@@ -172,6 +174,16 @@ The options presented are as follows:
    cards that can handle it in hardware), but a simple option (“Scan”)
    is available to try all modes in turn until a signal is received.
 
    cards that can handle it in hardware), but a simple option (“Scan”)
    is available to try all modes in turn until a signal is received.
 

+ * **Input interpretation:** Choose how the Y'CbCr values in the input signal
+   are to be interpreted. *Auto* will choose whatever is correct (as per the
+   appropriate standards) for the current video mode, but occasionally,
+   devices will get this wrong, and you will need to change this setting
+   to get correct colors. You can use the *--input-ycbcr-interpretation=*
+   command-line option to achieve the same effect.
+
+   See :doc:`analyzer` for figuring out if you need to change this.
+   If unsure, leave it unchanged.
+

  * **Use as audio source:** See the :doc:`audio <audio>` page for more
    information. For simple audio only; unavailable in multichannel mode.
 
  * **Use as audio source:** See the :doc:`audio <audio>` page for more
    information. For simple audio only; unavailable in multichannel mode.