Nightjar 4.12.0 is mostly for Linux. The GPU renderer draws each frame straight into the window, HDR streams present as HDR10 on desktop compositors that offer it, NVIDIA and Intel full-chroma pictures stay on the GPU, and PyroWave can decode on a separate compute queue (a new setting, off by default). On Android, Adaptive refresh can only be turned on where the screen supports it. Everything works with Rubylight and other Moonlight hosts.
What's new
- Adaptive refresh (VRR) can be turned on only where Android 16 and the screen support adaptive refresh; elsewhere the setting is greyed out, also in PC and game settings, and the stream no longer shows a VRR note. Your saved choice is kept for when the screen supports it.
- Ready the decoder for folding moved from Debug to Streaming, next to Dual screen.
- Linux: HDR streams on a desktop whose compositor offers HDR10 present as HDR10 PQ (BT.2020) instead of scRGB, like moonlight-qt. The launcher and SDR streams keep their previous output until an HDR stream switches the window to HDR10; after that they draw through HDR10 too, until the renderer is made again. Where the HDR10 output cannot be made, Nightjar falls back to scRGB for the rest of the run and says so in the log.
- Linux: the HDR10 output passes the host's mastering metadata to the compositor. Metadata whose peak luminance is not above its minimum (such as all zeros) is not passed on.
- Linux with NVIDIA: where NVDEC decodes (no Vulkan video decoding for the stream), CUDA now copies each picture straight into the GPU renderer's Vulkan images instead of through system memory, also on drivers without Vulkan video decoding or DMA-BUF import. NVDEC on another GPU than the renderer's is refused up front, with both GPUs named. When the copy cannot be used, the log says why, a toast says the pictures go through memory, and they do as before. The toast asking for a newer NVIDIA driver is gone.
- Linux with Intel graphics: full chroma (4:4:4) streams decode in hardware with VAAPI when the GPU renderer is used. The decoder's single-plane 4:4:4 pictures go straight into the renderer's Vulkan images instead of being refused. Where they cannot be mapped, the log says why and 4:4:4 is not offered, as before.
- Linux: the GPU renderer draws each frame straight into the window's swapchain instead of a back buffer that was then copied to it, one full-frame copy less per picture. Screenshots, HDR10 output's PQ pass, and the launcher's frames while live glass is being timed keep the back buffer.
- New setting "Decode PyroWave on a compute queue" in Video, under PyroWave decoder, off by default: PyroWave's GPU decoder decodes on a separate compute queue where the graphics card has one; without one it changes nothing. Measured on a Radeon 780M laptop it brought no clear gain, and the client it comes from removed it because it delayed presentation on Wayland, so it stays off. On Linux it applies from the next start. Each stream's log says which queue PyroWave decodes on and why.
Tested. The desktop client passed its unit tests (over 1640) and clippy on Linux, and the Windows and Android checks. PyroWave on a compute queue was measured on a Radeon 780M laptop (1080p60, 60 s legs, ABBA): 10.41 against 10.51 ms median and 11.91 against 11.95 ms p95 from receive to present, within the spread between legs, with shown fps slightly lower, so it stays off. The Linux HDR10, swapchain, NVIDIA and Intel 4:4:4 paths have not run on Linux GPU hardware yet. The Windows build scanned clean with Microsoft Defender before and after its first launch, which opened the main window.