PyroWave in 1.4.14-beta.1
PyroWave is an experimental intra-frame codec implemented with Vulkan compute. It trades substantial bandwidth for fast decoding and independent frames. HEVC remains a sensible starting point when the link or device has less room.
Which client does what?
Section titled “Which client does what?”| Client | Released 1.4.13 | 1.4.14-beta.1 |
|---|---|---|
| Nova Android stable | PyroWave disabled | Stable and beta remain separate apps |
| Nova Android beta | Experimental PyroWave | Feature-gated decoder availability; SDR 4:2:0/4:4:4 depends on supported decode modes |
| Nova Linux x86_64 | Separate experimental PyroWave Flatpak | Decoder in the standard bundle, with a lazy readiness probe; SDR 8-bit 4:2:0 |
| Steam Frame | No public ARM64 asset | Experimental native development, not a qualified shipping target |
| Other Moonlight clients | Cannot decode PyroWave | No compatibility is implied by normal GameStream pairing |
Auto never selects PyroWave. Choose it by name. Spaces do not carry PyroWave. Linux has no PyroWave HDR or 4:4:4 path; Android HDR capability also needs host and decoder agreement, and end-to-end HDR is not qualified here.
A Vulkan version alone is insufficient. The decoder checks the required features and a usable path. For example, a Shield TV without the required 8-bit storage and timeline semaphores cannot use this codec. Read the device’s reason and choose another codec instead of forcing it.
Set the picture before the bitrate
Section titled “Set the picture before the bitrate”Start with an ordinary SDR stream. Set resolution, frame rate and chroma mode first, then review the corresponding recommendation. High frame rate and 4:4:4 cost more bandwidth; copying a figure from a different mode is misleading.
The beta.1 handheld model targets 31 dB, while the room-viewing model uses 35 dB. Those are quality-model inputs, not network guarantees or measurements of the game. A calibrated 1080p120 4:4:4 handheld estimate is roughly 200–230 Mbps of request bitrate. Fine detail, motion and the link still need a real check.
Recommendation, manual pin and live rate are different
Section titled “Recommendation, manual pin and live rate are different”- Automatic increases and Use recommended stop at 300 Mbps. Advice above that is still meaningful, but the automatic action does not apply it in full.
- Android beta manual pins can reach the host’s advertised maximum, up to 500 Mbps on the matching host. If that capability is absent, the compatibility limit remains 300 Mbps. A high maximum is permission to request a rate, not evidence that the network or decoder can sustain it.
- Linux Play Setup offers discrete starting-rate choices, including PyroWave presets through 300 Mbps and Also use recommended. A saved custom rate can be higher. The live slider and 10 Mbps step buttons use the host’s advertised manual maximum, up to 500 Mbps, while the recommendation remains capped at 300 Mbps. The starting-rate picker does not have Android’s arbitrary exact-entry editor.
- Live host bitrate writes use encoder units. A request rate is not always the encoder’s video rate: audio, error correction and applicable caps can change the split. Read the advertised units before comparing numbers.
A matching host exposes the unit split and caps. Without that split, H.264 and HEVC can keep known encoder/video units. PyroWave request conversion needs known advice assumptions; unknown units stay read-only. Nova does not invent a conversion. An unavailable measurement is not zero, and a recommendation is not the actual media rate.
Give the transport room
Section titled “Give the transport room”Prefer wired gigabit Ethernet end to end, including the client’s adapter. Leave room for audio, error correction and network overhead. A 100 Mbps adapter is a poor match even for modest PyroWave settings. Wi-Fi may work for a particular mode and link, but a high signal indicator does not prove sustained delivery. Do not use someone else’s “2500 bitrate” figure without checking its units; 2500 kbps is 2.5 Mbps, whereas 2500 Mbps exceeds a gigabit link.
If a stream struggles, first try lower resolution, lower frame rate, 4:2:0 or HEVC. Repeatedly raising or cutting a rate cannot repair a host that is failing to supply frames. Doctor keeps network evidence separate from host starvation; its report does not change Live Tuning’s loss policy in this release.
Check the stream that is actually running
Section titled “Check the stream that is actually running”Confirm PYRO in Nova’s live codec reading. Then inspect the host capture and encoder evidence. A cached GPU probe, a selected Vulkan encoder and an active GPU-native capture path are different facts.
A CPU capture copy can feed a GPU encoder. Conversely, a working decoder does not turn host shared-memory capture into DMA-BUF capture. Nova’s capture caption and Polaris Doctor describe the reported active path; do not ignore a warning because an earlier probe passed.
If a device or host fails readiness, keep the named reason. There is no silent fallback to another codec, and no fallback to a different monitor just to make Host Virtual Display launch. A KDE HDR display captured through KMS can still produce a format the codec cannot accept; HEVC or AV1 may be the appropriate HDR route instead.
See the stable reference for the bitstream and host requirements, Nova Linux for the beta’s controls, and Doctor for diagnostics.