]> git.sesse.net Git - nageru-docs/blobdiff - hardware.rst
Document unsynchronized HDMI/SDI output.
[nageru-docs] / hardware.rst
index e2da70916c9405cb3dc43c1e03e16491e13ad50d..1ff9b64fa2663ec83fc332bbbb3c8f86183446a7 100644 (file)
@@ -14,11 +14,10 @@ high-quality (as in e.g. gamma-correct fades and high-quality scaling)
 HD video without a monster CPU, but it also comes with certain caveats.
 
 In particular, Nageru's use of multithreaded OpenGL trickles bugs in
-some drivers, as most games access the GPU from only one thread;
-Mesa didn't work properly at all before version 11.2, and there are still
-bugs left as of 13.0. However, in general, Intel GPUs from the Haswell
-generation and newer should work well with Nageru as long as you stick to
-720p60 (ie., no 1080i inputs, which require deinterlacing). NVIDIA's
+some drivers. in general, Intel GPUs from the Haswell
+generation and newer should work well with Nageru, although they may
+see performance issues if you connect interlaced sources (since the
+automatic deinterlacing applied requires a fair bit of computing power). NVIDIA's
 proprietary drivers (occasionally known as nvidia-glx) are generally excellent
 and should give few issues in this regard.
 
@@ -45,7 +44,8 @@ if it is available. Currently, VA-API is the only hardware encoding method
 supported for encoding the digital intermediate, although Nageru might support
 NVIDIA's NVENC at some point in the future. In particular, this means that
 Intel Quick Sync Video (QSV), the hardware H.264 encoder present on all modern
-Intel GPUs, is supported.
+Intel GPUs, is supported. If possible, Nageru uses zerocopy from the GPU to the
+VA-API buffers in order to reduce memory transfer bandwidth.
 
 QSV is more than fast enough to keep up with 720p60 in
 realtime without eating appreciably into the power budget, but it is not
@@ -58,20 +58,12 @@ further editing or transcoding without strong generational loss.) Thus, the
 QSV stream is not intended for streaming to end users of the Internet; it will
 need to be reencoded by some external means, or you can use Nageru's x264
 support to produce a user-facing stream in addition to the digital intermediate
-(see :doc:`streaming`).
-
-By default, Nageru uses zerocopy from the GPU to the VA-API buffers in order to
-reduce memory transfer bandwidth, but this depends on EGL support (as opposed to
-the older GLX standard), and also that the GPU you are rendering to also
-supports VA-API. NVIDIA's proprietary drivers do not support either. Unfortunately,
-this is somewhat cumbersome to automatically detect before it's too late to do anything
-about it (Qt has already initialized using EGL), so on NVIDIA
-systems, Nageru will exit with an error message asking you to set *--va-display*
-to your Intel GPU manually. Simply follow the instructions printed to the terminal
-to select what looks like your Intel GPU, and Nageru will fall back to using GLX
-and transferring the memory data between the two GPUs via the CPU. (Some BIOSes
-automatically disable the Intel GPU if you have a discrete GPU installed; you
-will need to reenable it to get access to QSV, or Nageru can't run.)
+(see :doc:`streaming`). You can also use x264 to produce the recording to disk
+instead of Quick Sync, using the --x264-record-video flag. If you wish to have
+separate flags for streaming and storing to disk (e.g., to keep a digital intermediate
+on disk), and have Nageru 2.1.0 or newer, you can use the --separate-x264-disk-encode flag (and associated
+--x264-separate-disk-bitrate flags etc.). Otherwise, the same stream will go
+to the network and to disk.
 
 
 Video capture cards