PyroWave (wired-LAN codec)
The opt-in ultra-low-latency wavelet codec for wired links, what it is, the bandwidth it needs, and how to turn it on.
PyroWave is an opt-in video codec mode for links that can afford real bandwidth: wired Ethernet, a docked Steam Deck, a 2.5GbE LAN. It trades bitrate for latency, instead of H.264/HEVC/AV1 on the GPU's video engine, frames are compressed with PyroWave, an intra-only wavelet codec running as plain Vulkan compute. Slipstream vendors a pinned copy and runs it on both ends.
It is never selected automatically. HEVC/AV1 remain the codecs for Wi-Fi and everything else; PyroWave engages only when you pick it on the client and the host supports it. If either side can't, the session silently falls back to the normal codec ladder.
Why you'd want it
- Codec latency drops by an order of magnitude. Encode and decode each take a fraction of a millisecond of GPU compute (measured ~0.15 ms encode / ~0.07 ms decode at 1080p on an RTX 5070 Ti), versus one-to-several milliseconds per side for the hardware H.26x pipelines.
- Every frame is a keyframe. There is no GOP, no reference chain, no keyframe round-trip after packet loss, a lost frame costs exactly that frame, and the next one is already a complete picture. The whole IDR/recovery apparatus that produces loss-time stutter simply doesn't exist in this mode.
- Uniform frame sizes. The rate control hits its per-frame byte budget exactly, so the pacer sees a flat load instead of 20-40x keyframe spikes.
What it costs
Bandwidth. At the codec's ~1.6 bits-per-pixel operating point (4:2:0, SDR):
| Mode | Bitrate |
|---|---|
| 1280x800 @ 60 (Deck) | approx 100 Mbps |
| 1920x1080 @ 60 | approx 200 Mbps |
| 1920x1080 @ 120 | approx 400 Mbps |
| 2560x1440 @ 60 | approx 355 Mbps |
| 2560x1440 @ 120 | approx 710 Mbps |
| 3840x2160 @ 60 | approx 800 Mbps |
| 3840x2160 @ 120 | approx 1.6 Gbps |
Frame rate scales the rate linearly, 4:4:4 multiplies it by ~1.6, and an HDR (10-bit) session adds ~15 %. Estimate any combination:
Estimate of the Automatic bitrate a PyroWave session pins for this mode. Link bars use a practical payload ceiling (below line rate). The pin is capped at 8 Gbps; on a constrained link a host can cap it lower with SLIPSTREAM_PYROWAVE_MAX_MBPS.
Gigabit Ethernet tops out around 940 Mbps of payload, so 4K60 wants 2.5GbE and the big 4:4:4 / HDR / high-refresh modes want 5GbE or 10GbE. Do not run this over Wi-Fi, that's what HEVC/AV1 are for.
4:4:4 and HDR
PyroWave carries full-chroma 4:4:4 and HDR the same way it carries everything else, intra-only, every frame a keyframe, so the low-latency and clean-loss properties above hold in these modes too. Both are negotiated per session from your client's settings, exactly like HEVC/AV1; nothing PyroWave-specific to turn on beyond picking the codec.
- 4:4:4 (full chroma). With your client's 4:4:4 setting on, the session encodes chroma at full resolution instead of subsampled 4:2:0, sharp coloured text, thin UI lines, and red/blue edges that 4:2:0 softens. It costs ~1.6x the bitrate (chroma compresses better than luma, so it is less than the 2x the extra samples imply). Available on Linux hosts.
- HDR (10-bit, BT.2020 PQ). The Linux PyroWave path has no HDR colour conversion, so a Linux-hosted PyroWave session is SDR; stay on HEVC or AV1 for HDR, where PyroWave is the odd one out among the codec rules. 4:4:4 still works with PyroWave on Linux.
- Clients that decode PyroWave take whatever the session negotiated, 4:2:0 or 4:4:4, with no extra setup.
At the top end this gets demanding: 4:4:4 + HDR at a super-ultrawide 5120x1440@240 pins around
5.3 Gbps, which is more than a 5GbE link carries. On a link that can't keep up, either set an
explicit lower bitrate on the client or cap the host's Automatic pin with
SLIPSTREAM_PYROWAVE_MAX_MBPS, otherwise the overshoot just becomes
dropped packets.
Turning it on
- Host (Linux): nothing to do, default builds ship the codec and every Linux GPU host advertises it. AMD, Intel and NVIDIA hosts all encode straight from the capture dmabuf: the wavelet encoder owns its own Vulkan device and imports the buffer on any vendor, so there is no CPU copy on the host. (A compositor that refuses every offered dmabuf format still falls back to the CPU path, as it does for the other codecs.)
- Client:
- Steam Deck: set Settings -> Video codec -> PyroWave (wired LAN) in the session / Decky
settings, or launch with
SLIPSTREAM_PREFER_PYROWAVE=1. Wired / docked strongly recommended. - Android has no PyroWave decoder.
- Steam Deck: set Settings -> Video codec -> PyroWave (wired LAN) in the session / Decky
settings, or launch with
- Leave the bitrate on Automatic: a PyroWave session pins itself to the ~1.6 bpp rate for your mode ( approx 200 Mbps at 1080p60; ~2.6 bpp for 4:4:4, +15 % for HDR). An explicit bitrate is honored if you set one, but the adaptive-bitrate controller stays off either way, this codec has no useful low-rate regime, so under sustained loss the right move is switching back to HEVC, not degrading. The pin follows the resolution: a mid-stream resize (e.g. Match window) re-pins the rate for the new mode, so resizing a window down also cuts the bandwidth.
The stats overlay shows pyrowave as the decode path when the mode is active.
Current limits
- Linux hosts and Steam Deck (session client, including a docked Deck) today. Android has no PyroWave decoder.
- A Linux-hosted PyroWave session is SDR (see 4:4:4 and HDR above). 4:4:4 works.
HDR
How an HDR10 stream is decided end to end, the four things that must all be true, what each host and client can actually do, and how to check which link is missing.
Wake-on-LAN
How Slipstream clients wake a sleeping host, what has to have happened first, what a click does, the slipstream wake command, and how to arm the machine so the packet actually lands.