On September 21, 2026 (US time), Valve added an experimental video codec called "Pyrowave" to Remote Play in the Steam client beta. The manually configurable bitrate ranges from 100 to 500 Mbit/s. According to Valve, because it uses 5 to 10 times more bandwidth than other streaming codecs, it recommends connecting both host and client directly to the router via at least Gigabit Ethernet. Rather than shrinking the video further, the design spends the surplus bandwidth on a home LAN to buy back encoding and decoding time.
What Pyrowave targets isn't eliminating network latency itself. It strips out complex processing like inter-frame prediction and fine-grained data packing, shifting the work into a form GPUs can process all at once. Consequently, the actual effect depends not just on the codec's speed, but on the entire delivery path—the network connection, the receiving GPU, and even the display device.
Steam's choice: a beta that buys time with bandwidth
Pyrowave is available in the Windows and macOS Steam beta. On Linux, users need to enable the experimental SteamRT3 client from system settings. Support for the mobile Steam Link app is planned for the future. It's disabled by default, and users select it from the detailed Remote Play client settings.
In Pyrowave's automatic mode, each frame is sized to match the desired visual quality. As the frame rate increases, more frames are sent per second, which raises the required bandwidth accordingly. A quality slider lets users adjust the amount of data transmitted, and if they want to set the network ceiling directly, they can turn off automatic bitrate and specify a value between 100 and 500 Mbit/s.
For a simple calculation: sending 200 Mbit/s at 60 fps works out to roughly 3.33 Mbit, or about 417 kB, per frame. Developer Hans-Kristian Arntzen describes conventional game streaming as running around 10-20 Mbit/s, the range Pyrowave targets as over 100 Mbit/s, and uncompressed 1080p60 YUV 4:2:0 video as approximately 1.5 Gbit/s. Pyrowave is significantly smaller than uncompressed video, but it occupies a middle ground that spends far more bandwidth than typical video compression.
This option isn't meant to broadly replace streaming over the internet. As Valve's mention of Gigabit Ethernet suggests, the primary battlefield is home networks with bandwidth to spare.
The secret to speed: subtracting from the compression process
Pyrowave uses an intra-only encoding approach that works within individual frames alone. Common video codecs like H.264, HEVC, and AV1 reduce data volume by predicting similarities between adjacent frames and transmitting mainly the changes. Pyrowave doesn't use temporal prediction at all, treating video as a sequence of independent still images. This lowers the compression ratio, but eliminates the need to wait on relationships between frames.
Each image is split into low-frequency components and directionally-oriented high-frequency components across five stages using a Discrete Wavelet Transform (DWT). The filter is the lossy CDF 9/7, the same one used in JPEG 2000. Furthermore, rather than using entropy coding—which packs data based on frequency of occurrence—the transformed coefficients are simply arranged as bitplanes. This makes the data easier to process in parallel on a GPU, at the cost of inflating the data volume.
| Design Choice | What's Gained | What's Given Up | Conditions Visible in Steam |
|---|---|---|---|
| No inter-frame prediction | Frame-by-frame independence, reduced latency | Temporal compression efficiency | 100-500 Mbit/s |
| No entropy coding | High GPU parallelism | Even larger data volume | Described as 5-10x the bandwidth of other methods |
| Predetermined cap per frame | Fixed size, harder to buffer excessively | Stronger quantization in complex scenes | Quality slider and automatic bitrate |
Pyrowave deliberately abandons features that maximize compression ratio in exchange for GPU parallelism, fixed-time size control, and frame independence. Valve's 100-500 Mbit/s configuration range is the user-facing expression of this design trade-off. The developer evaluates, for each 32x32 coefficient block, how many bits can be discarded and how that affects visual quality, then allocates the budget within the overall image's cap. In the developer's tests, output reportedly landed within about 10-20 bytes of the target value.
Why completing each frame independently resists data loss
When frames are independent, corruption in one frame doesn't cascade into subsequent frames. In methods that reference previous frames, damage to the reference source can persist until the next keyframe. Because Pyrowave decodes the next frame as a fresh still image, it can cut off temporal damage right there.
The public bitstream draft records wavelet coefficients independently in 32x32 blocks. If a block fails to arrive due to packet loss, that coefficient is reconstructed as zero. Loss of high-frequency components might manifest as temporary blurring in part of the screen. On the other hand, loss of the lowest-frequency band—which carries the image's overall structure—is more serious, and the draft specification leaves room for adding selective error correction to those packets.
In other words, Pyrowave doesn't eliminate loss but attempts to contain its impact both spatially and temporally. In streaming scenarios where waiting for retransmission would increase latency, this property has real meaning. However, it doesn't guarantee good video quality on connections where even low-frequency components are frequently lost.
The bitstream draft is explicitly marked as "draft" at this stage and subject to change. While the public README still describes the loss-resilience unit as 64x64, the detailed specification defines 32x32 coefficient blocks. This should be viewed not as a stable external standard, but as an implementation still evolving alongside the Steam beta.
How much can we trust figures in the sub-0.1 ms range?
In measurements Arntzen published in June 2025, using an AMD Radeon RX 9070 XT and RADV, encoding hard-to-compress 1080p YUV 4:2:0 material took 0.13 ms, while decoding took under 100 microseconds. A different game asset took about 80 microseconds, and 4K YUV 4:2:0 material was encoded in 0.25 ms. The current README further states that 1080p encoding and decoding take under approximately 0.1 ms, and 4K under approximately 0.2 ms.
However, these are developer measurements using a specific GPU, driver, and set of source materials. They are not independent tests measuring how many milliseconds are actually shaved off the total latency of Steam Remote Play from host to display. In visual quality comparisons against H.264, HEVC, and AV1, the competing codecs were also configured to intra-only, strict fixed-bitrate, and fastest-mode settings. The developer explicitly acknowledges these aren't settings typically used in normal streaming, so it can't be said that Pyrowave's image quality always surpasses that of standard operation.
In the developer's own self-assessment at over 200 Mbit/s and 60 fps, compression artifacts were reportedly hard to distinguish without zooming in side-by-side. On the other hand, when wavelet compression heavily discards high-frequency components, degradation tends to appear as blurring or ringing around edges rather than blocky distortion. How this looks in practice varies by video content and settings.
High bandwidth can also be spent on color precision. HDR is automatically selected when both host and client support it. YUV 4:4:4, which doesn't subsample chroma, offers benefits particularly for text, thin lines, and readability on 4K desktops rather than for general gameplay footage. Because it consumes even more processing time and bandwidth, it's disabled by default and is a feature to select only in environments that need it.
Even wired LAN doesn't always mean faster performance
Valve treats total streaming latency as the sum of encoding, network transfer, decoding, and finally display. What Pyrowave directly reduces is primarily the first and third of these. If Wi-Fi congestion is causing increased packet delay, if the TV's display processing is slow, or if the network path is congested near 500 Mbit/s of traffic, then even a sub-0.1 ms codec will barely change the perceived responsiveness. Increasing bandwidth could even raise network latency as a side effect.
The public API is at version 0.5.0, and it's explicitly stated that the API and ABI won't stabilize until major version 1 is reached. The pathway that directly handles the GPU requires Vulkan 1.3-generation features such as subgroup size control, 16-bit integer shaders, and 8-bit storage buffer access. The developer states this can target desktop GPUs and many mobile GPUs, and has also prepared a decoding path using conventional rendering for mobile GPUs with weaker compute capabilities. However, Valve hasn't disclosed which GPUs Steam internally permits, or what it falls back to when a feature is missing.
If you want to try it, enable Remote Play's performance graph and compare a conventional codec against Pyrowave using the same game, resolution, and frame rate. The number to watch isn't just total latency. It's about identifying, at each stage from encoding to display, what changed and what stayed the same. Image quality should also be checked not on still frames but in scenes that are typically hard to compress, such as foliage, particle effects, and fine UI text.
Pyrowave's value lies not in replacing all Remote Play use cases, but in redirecting bandwidth that was going unused on a home wired LAN toward shortening codec processing time. What will determine whether it graduates to stable release is how thoroughly Valve can present a device-by-device compatibility chart, along with comparisons of total latency, power consumption, and packet-loss behavior measured at equal image quality and network conditions.