Why Steam’s Pyrowave Codec Needs 10x the Bandwidth: How It Works and What the Latency Numbers Show
Pyrowave compresses every frame on its own with GPU wavelets and no entropy coding: under 0.1 ms to encode, about 1 ms added latency in its author’s test, but 100+ Mbit/s. Who should turn it on.
TL;DR — Steam's new Remote Play codec, Pyrowave, works differently from H.264, HEVC and AV1. It compresses every frame on its own with a wavelet transform, does all the work in Vulkan compute shaders, and skips the expensive entropy-coding stage entirely. That buys extremely fast encoding: under about 0.1 ms at 1080p and 0.2 ms at 4K, according to its author. The price is bandwidth: 100+ Mbit/s instead of ~10–20 Mbit/s, which is why Valve asks for wired Gigabit Ethernet. In the author's own latency test, Pyrowave added about 1 ms over a local baseline, against about 8 ms for NVENC H.265. Those are one developer's lab numbers, not Valve's, and real networks will add more.
Already know what it is and just want it switched on? Our step-by-step guide is here: How to enable Steam's Pyrowave codec for Remote Play. This article answers the other common question: why it needs so much bandwidth, and whether the latency gain is real.
Where Pyrowave came from
- Pyrowave is not a Valve in-house codec. It was written by Hans-Kristian Arntzen (Themaister), the graphics programmer behind VKD3D-Proton, the layer that runs Direct3D 12 games on Linux and Steam Deck.
- He introduced it in a June 2025 blog post titled "I designed my own ridiculously fast game streaming video codec". The code is open source under the MIT licence on GitHub.
- Steam timeline:
- 21 Sep 2026: Steam Client Beta adds it as "experimental".
- 1 Oct 2026: a beta update raises the manual cap to 1 Gbit/s.
- 13 Oct 2026: it ships in the stable client.
How it works, in four design choices
1. Intra-only: every frame stands alone
Normal video codecs save most of their bits by describing how each frame differs from the last one (motion prediction). Pyrowave doesn't. Each frame is compressed like a still image.
- Gain: nothing depends on the previous frame. A lost packet can't smear errors across the following frames, and there is no motion search to slow the encoder down.
- Cost: you lose the biggest source of compression. Arntzen's own estimate is "100+ Mbits/s instead of ~10-20 Mbit/s."
2. Wavelets instead of DCT blocks
Pyrowave uses the CDF 9/7 discrete wavelet transform, the same filter family as JPEG 2000. H.264 and HEVC use block-based DCT instead.
- The image is split into 5 levels of detail, similar to the mip-maps games use for textures.
- High-frequency detail can be quantised harder because the eye notices it less.
- When it does break down, the artefacts look like blur and ringing, not the blocky squares of an overloaded H.264 stream.
3. No entropy coding
Entropy coding (CABAC in HEVC, for example) squeezes out the last bits but is hard to run in parallel. Pyrowave writes bit-planes almost raw, so thousands of GPU threads can encode at once.
This is the second reason the bitrate is high. The README admits the simple coding "noticeably increases bitrate at high compression."
4. Small independent blocks and a hard bitrate cap
- Coefficients are packed into small blocks that decode independently: 32×32 in the blog post, 64×64 in the current README. If one is lost on the network, that region is treated as all zeros and shows up as a small blur rather than a glitch.
- Rate control hits an exact per-frame size in a single pass, usually "~10-20 bytes under the target." That predictability is what a low-latency stream needs.
The speed numbers
From Arntzen's measurements:
| Test | Encode | Decode |
|---|---|---|
| 1080p (README) | < ~0.1 ms | < ~0.1 ms |
| 4K (README) | < ~0.2 ms | < ~0.2 ms |
| Expedition 33, 1080p 4:2:0, RX 9070 XT | 0.13 ms | under 100 µs |
| "Normal" games, 1080p | ~80 µs | — |
| ParkJoy test clip, 4K 4:2:0 | 0.25 ms | — |
For comparison, he found that just copying a raw 4K frame over PCIe took longer than compressing it with Pyrowave and copying the result. Decoding on a Steam Deck draws "barely measurable" power.
The latency test
In July 2026 Arntzen measured input-to-GPU-idle latency on a VRR monitor. That is the time from a button press until the frame showing it is finished. All figures are in milliseconds.
| Setup | Average | Median | Range | Added vs local |
|---|---|---|---|---|
| Local, no streaming (baseline) | 11.8 | 12.4 | 3.5–19.3 | — |
| Pyrowave, 1440p60, 250 Mbit/s, 4:4:4 | 12.8 | 12.8 | 5.1–21.3 | ~+1.0 |
| AMD (RADV) H.265, 4:2:0 | 14.9 | 15.2 | 6.7–22.5 | ~+3.1 |
| NVENC H.265, RTX 4070, 50 Mbit/s, 4:4:4 | 20.2 | 20.1 | 12.0–31.9 | ~+8.4 |
Read this carefully:
- It was a localhost round trip on one machine, not two PCs over a real network. Arntzen expects a real network to be bandwidth-bound and add "a few milliseconds".
- The AMD H.265 run used 4:2:0 colour while the others used 4:4:4, so it is not a like-for-like comparison.
- Most of the baseline latency comes from input polling (half a refresh cycle on average), not from the codec.
- For NVENC, the overhead is mostly encode time (over 6 ms) plus a few ms of decode, and it grows at 4K.
Bottom line: on a good wired LAN, Pyrowave takes the codec almost out of the latency budget. On Wi-Fi or a slow link, its bandwidth demand becomes the bottleneck instead.
Why Valve says "5–10× the bandwidth" and "Gigabit Ethernet"
All four design choices trade compression for speed:
| Codec style | Bitrate it needs for good game streaming |
|---|---|
| Inter-frame codecs (H.264 / HEVC / AV1) | ~10–20 Mbit/s (Arntzen's estimate) |
| Pyrowave | 100+ Mbit/s; Steam's manual range started at 100–500 Mbit/s and now goes up to 1 Gbit/s |
- Arntzen's sweet spot is "over 200mbit/s at 60 fps", around 1.5 bits per pixel, where he says artefacts are hard to see without zooming.
- Steam keeps frame size constant for quality, so 120 fps needs roughly twice the bandwidth of 60 fps.
- Turning on YUV 4:4:4 (sharper text) costs more bandwidth again.
That is why typical Wi-Fi, even Wi-Fi 6, often ends up worse with Pyrowave than with the default codec: the stream drops quality or stutters to fit. Valve's own caveat is blunt: "Your particular setup may or may not benefit from the new codec."
Who should turn it on
| Your setup | Try Pyrowave? |
|---|---|
| Gaming PC → second PC or TV box, both wired to a Gigabit router | Yes, this is what it is built for |
| Desktop work or text-heavy games on a 4K display, wired | Yes, and consider 4:4:4 |
| Steam Deck or laptop on Wi-Fi | Probably not; compare with the default codec |
| Remote Play over the internet | No; the bitrate is far beyond most home uploads |
| Steam Link phone app | Only in the app beta, and only on a strong local network |
| Linux | Only with the experimental SteamRT3 client enabled |
Is it VR streaming for Steam Frame? No. Pyrowave is for flat Remote Play. Valve's post doesn't mention VR, and VR streaming uses a separate path.
FAQ
Is Pyrowave better than AV1? Different goals. AV1 squeezes the most quality out of few bits, which is ideal over the internet. Pyrowave spends many bits to get the encode and decode times close to zero, which is ideal on a fast LAN.
Why does my stream look worse with Pyrowave? Almost always bandwidth. If the link can't sustain 100+ Mbit/s, Steam has to lower the quality. Wire both machines or switch back to the default codec.
Who made Pyrowave? Hans-Kristian Arntzen, the developer behind VKD3D-Proton. It is open source under the MIT licence, and Valve integrated it into Steam.
Is it still experimental? Yes. It shipped in the stable client on 13 October 2026, but Valve still labels it experimental and has it off by default.
Sources: Pyrowave README (GitHub), Arntzen, "I designed my own ridiculously fast game streaming video codec" (Jun 2025), Arntzen, latency measurement post (Jul 2026), Valve: "Pyrowave video codec now in beta!", MIXED, GamingOnLinux. Latency and speed figures are the codec author's own measurements.
← Back to all posts