What's new
Highlights
- Tear-free VRR on Windows. With Variable refresh rate on, a frame that arrives while the screen is still drawing the last one is shown whole instead of torn.
- Real VRR follows your connection. Its delay is sized from how your frames arrive, so fewer of them are off the game's rhythm on Wi-Fi.
- RTX HDR and RTX Video per game, on a PC that offers them.
- Linux: an AMD graphics card can stay at its highest clocks while streaming, with a new setting.
- Play over the internet takes video packets that arrive far out of order.
Streaming
- Windows: a new setting, Tear-free VRR, next to Real VRR, shown with Variable refresh rate on and on by default. A VRR screen starts drawing a frame the moment it is presented. A frame presented while the screen was still drawing the last one was torn, and whole only on the screen's next refresh. Nightjar now reads where the screen is in its drawing and holds such a frame until the drawing has finished, at most one refresh. Turn it off to show every frame at once, with tearing. How it works and what we measured.
- Real VRR sizes its delay from your connection: it covers the frames that arrive together, and after a late frame the ones behind it keep the game's spacing. In our Wi-Fi recordings a quarter to almost half fewer frames are off the game's rhythm, for 0.7 to 1.5 ms more delay; a clean connection is unchanged.
- PyroWave streams follow Real VRR on Android (Variable refresh rate on a screen with adaptive refresh).
- A game's own settings now offer RTX HDR and RTX Video too, on a PC that offers them. Before, only the PC's own settings did.
- Play over the internet takes video packets that arrive far out of order: up to 512 behind the newest, where it dropped any more than 64 behind.
Linux
- A new setting, High-performance GPU power while streaming (Advanced, off by default). With it on, an AMD graphics card that drives a connected display stays at its highest clocks for the whole stream, so it does not slow down between frames. It uses more power and shortens battery life. It changes nothing when the card's clocks are already set by hand, and it applies from the next stream.
macOS
- Nightjar's log names the refresh range the screen reports. On a ProMotion or Adaptive-Sync screen the environment variable
NIGHTJAR_MAC_VRR=1turns Real VRR on. It has not been measured on a screen: if you try it, tell us what you see.
Fixes
- Android, Dolby Vision: a Dolby decoder running with Qualcomm's low-latency keys is now created anew when the stream restarts it, as MediaTek's already was, and a Dolby Vision decoder that maps the picture itself is no longer checked for HDR10 metadata (from the log in Rubylight #104).
- Android: a menu that opened just as its stream ended no longer leaves its blur on the screen.
- Android: the first stream's menu hint stays beside the performance overlay when that moves or changes size.
- Desktop: starting an app by its name from the command line (
nightjar stream <PC> <app>) works on a PC that orders its apps for older clients. The names it sent carried invisible characters, so no name matched (Rubylight #106). - Desktop: pressing Enter in the Home Wi-Fi field adds the network's name.
- Desktop: a sharper cover is no longer replaced by a blurrier one that finished loading later.
- Desktop: when every decoder surface was in use and the presenter had not caught up, the decoder could fail its next frame. The oldest waiting picture is now replaced instead.
Tested. Tear-free VRR was measured from a laptop streaming HEVC over Wi-Fi to a 240 Hz VRR monitor, with the screen's drawing position recorded every 40 µs. Torn frames fell from 34.3 to 0.2% with an uneven test animation, from 1.9 to 0.0% at 120 fps, from 24.7 to 0.2% at about 72 fps and from 38.2 to 3.5% at about 57 fps, one run each. A whole frame reached the screen no later for it: at the median 1.4 against 2.3 ms, 0.5 against 0.5 ms, 1.6 against 1.4 ms and 1.9 against 2.5 ms. Real VRR's delay was replayed over our Wi-Fi recordings. Nightjar's builds and test suites pass on Android, Windows, Linux and macOS. The Linux GPU power setting, Real VRR on a Mac and the Dolby Vision decoder changes were not run on such a device here, and the reports behind Rubylight issues #103, #104 and #106 were not reproduced.