RamazanKara/nightjar v4.10.0

Nightjar 4.10.0

on GitHub

Nightjar 4.10.0 brings Dual screen mode and faster decoding. A device with a second screen can stream the same game on both. On Android, frames reach the decoder and the screen with fewer copies. On Linux, HDR and 10-bit pictures stay on the GPU, also on PCs with two GPUs. And a decoder that falls behind is no longer mistaken for network loss. Dual screen mode needs Rubylight 3.11.0 on the PC; everything else works with older Rubylight and other Moonlight hosts.

Highlights

• Dual screen mode. On a device with a second screen, a second stream of the same game runs on it, at that screen's own size or a fixed resolution. Sound, controllers and the microphone stay with the first screen. On the desktop, the second stream opens full screen on the other monitor. Thanks to @umbertomarotta (#82).
• Linux keeps pictures on the GPU. VA-API pictures go straight into the GPU renderer, so HDR and 10-bit streams (Steam Deck included) no longer copy every frame through memory.
• Decoder drops are not network loss. A decoder too slow for the stream gets its own "Decoder drops" line. Loss, automatic bitrate and the stream doctor count only what the network lost, and pacing no longer holds frames behind a decoder backlog.
• Fewer copies on Android. PyroWave and the new streaming engine hand frames to the decoder in place, and the Vulkan renderer lets the GPU wait for each decoded frame.
• Faster recovery on desktop. HEVC and AV1 on D3D11VA, VA-API and software decoding ask the PC to stop referencing a lost frame instead of waiting for a full key frame.
• Honest hardware decoding. Nightjar checks what the hardware decoder can decode before the stream starts. AV1 that a device can't decode streams HEVC instead of H.264, and Nightjar says so.
• Flatpak fixes. The Flatpak reaches the power menu, network status and RealtimeKit, and stream threads get their priority through the desktop portal.
• Glass that reads. The stream menu, dialogs, keyboards and statistics share one glass and stay readable over bright games.

Android

• PyroWave: each frame goes from the network to the decoder without the two copies it took before.
• With the new streaming engine, the other codecs' frames also reach the decoder with one copy fewer. "Video data straight to the decoder" in Debug turns this off.
• The Vulkan renderer lets the GPU wait for each decoded frame instead of a CPU thread, where the device supports it.
• Android's performance hints now report the CPU time the renderer used, not the time it waited.
• With "Prioritize stream traffic" on, the classic streaming engine's decoder thread now gets the decoder's priority on every decoder, so a busy phone delays frames less.
• A frame the decoder refused no longer makes smooth pacing wait for it.
• HEVC and AV1 get their own decoder's slice and submit settings.

Windows and Linux

• A GPU that can't decode HEVC Main10 or AV1 is no longer offered them, so the PC streams a format the hardware decodes. Before, Nightjar would decode on the CPU, or for AV1 not at all.
• AV1 or HEVC chosen on a device that can't decode it now streams the next best codec it does decode, and Nightjar says which. That's HEVC Main10 for HDR and 10-bit, and HEVC 4:4:4 for 4:4:4, instead of dropping to H.264 8-bit. With full chroma on, Nightjar also says when the stream runs on HEVC instead of AV1.
• If the hardware decoder gives up mid-stream, Nightjar says so, names it on the overlay and moves to the next decoder. It no longer decodes on the CPU under the hardware decoder's name.
• A frame the decoder couldn't turn into a picture, or decoded damaged, now asks the PC for a fresh picture, so artifacts no longer stay until the next scene change.
• Windows: the stream's receive, decode, audio and control threads get a raised priority. "Prioritize stream traffic" now shows on Windows too.
• Streams with 10-bit color start a little faster: the 4:4:4 decoder check runs only when 4:4:4 is on.

Linux and Flatpak

• On the GPU renderer, VA-API pictures are mapped into its Vulkan device instead of being read back and uploaded. Where VA-API can't decode the stream, Vulkan video does, also without the trip through memory. If the mapping can't be set up, the log says why and the pictures go through memory as before.
• On PCs with two GPUs (integrated graphics beside a graphics card), VA-API on the OpenGL renderer now decodes on the GPU that draws the stream instead of whichever GPU the system lists first, so its pictures reach the screen without a trip through memory. The log names the GPU and why.
• Turning on HDR, upscaling, PyroWave, 4:4:4, 10-bit SDR or full chroma no longer needs a restart: the stream switches from OpenGL to the GPU renderer on its own. A new Renderer setting under Debug picks Automatic, OpenGL or GPU (Vulkan).
• An HDR stream refused on a display with HDR on now names what the renderer couldn't do.
• The Flatpak can reach the system services it asks for: logind (power menu), NetworkManager (link speed and Wi-Fi roaming) and RealtimeKit. Before, it had no system bus.
• Stream and controller threads are raised through the desktop portal or RealtimeKit when the system refuses it directly, including the Flatpak on Bazzite and SteamOS.
• The route to the PC is found without the ip tool. In the Flatpak this brings back Wi-Fi pacing on the Steam Deck and VPN-sized packets, and a wired route reads "wired" with its link speed.
• V4L2 decoders on ARM handhelds and boards hand over each picture with its own frame instead of one frame late.

Look and controls

• The stream menu is easier to read over a bright or HDR game, above all on devices without live blur such as the Shield TV.
• Dialogs over a stream, both on-screen keyboards, the statistics and the controller editor wear the same glass as the stream menu. Keys are solid caps, and a keyboard's opacity setting fades only its panel.
• Slider values are readable while you move them, shown above the thumb so your finger doesn't hide them.
• On a TV, the statistics overlay stays one column along the left edge instead of running off the screen.
• VRR on a TV whose top refresh rate only comes at a smaller resolution keeps a 4K stream at 4K and asks the PC for the rate the screen shows.

Fixes

• The stream doctor leaves out the first two seconds and counts a single slow moment once, so the first picture or a switch to HDR no longer blames the PC.
• Problem reports also hide MAC addresses written with dashes, and keep "4:4:4" and times readable.
• The log says when the GPU renderer couldn't be made and Nightjar drew with another one.

Debug settings

Optimisations that didn't measure better on our devices stay available, off by default.

• Android: "Speed up frame hand-off", "Ready the decoder for folding", "PyroWave early screen image", "Decoder priority for receiving".
• Desktop: "Slices for software decoding".
• Linux: "Vulkan video first" and "Vulkan video recovery".

Tested. On a Retroid Pocket 6, 1080p120 at 40 Mbps from Rubylight on an RX 7900 XT, with the CPU loaded, the new streaming engine against the classic one:

• HEVC: receive to present p95 2.41 to 2.21 ms, decoder drops 0.30 to 0.20 %.
• H.264: receive to present p95 2.54 to 2.18 ms, decoder drops 0.41 to 0.13 %.
• Idle, the two engines are within 0.1 ms.

On the same device:

• The Vulkan renderer's GPU wait cut decode-to-present p95 from 1.92 to 0.95 ms.
• PyroWave's in-place hand-off took 0.09 to 0.16 ms off each frame's submit.

On an Intel NUC (Iris Plus 655) running the Flatpak, mapping VA-API pictures into the GPU renderer:

• 4K60 HEVC: 60 fps at 36 % CPU against 50-60 fps at 110-116 %, decode p95 9.4 against 24-26 ms.
• 4K HDR Main10: 47 against 29 fps.

On Windows (D3D11VA, HEVC 1080p60 at 50 Mbps, 25 % loss past error correction), reference frame invalidation:

• 19 % fewer key frames.
• 20 % more frames reaching the decoder.
• 29 % fewer gaps.
• No cost without loss.

On a Galaxy Z Fold7 at HEVC 1080p120:

• The new engine's receive to present was p50 0.81 / p95 2.22 ms, against 1.33 / 2.60 for the classic one.
• The Vulkan renderer's GPU wait cut receive to present p95 from 3.79 to 2.33 ms.

Dual screen mode on a Retroid Pocket 6 with a simulated second display, against Rubylight on the RX 7900 XT:

• Two streams run side by side, each with its own resolution and bitrate changes.
• Leaving the second screen keeps the first, and leaving the first ends both.
• A Wi-Fi drop reconnects both.