Valveは米国時間2026年9月21日、SteamクライアントβのRemote Playに実験的な映像コーデック「Pyrowave」を追加した。手動設定できるビットレートは100〜500 Mbit/s。Valveによれば、他の配信コーデックの5〜10倍の帯域を使うため、少なくともGigabit Ethernetでホストとクライアントをルーターへ直接つなぐことを勧めている。映像をさらに小さくするのではなく、家庭内LANの余った帯域で符号化と復号の待ち時間を買う設計だ。

Pyrowaveが狙うのは、ネットワーク遅延そのものを消すことではない。前後の映像を参照する予測や、データを細かく詰める複雑な処理を省き、GPUが一気に処理できる形へ寄せる。したがって効果を左右するのは、コーデックの速さだけでなく、回線、受信側GPU、表示装置まで含む配信経路全体である。

AD

Steamが選んだ「帯域で時間を買う」β

PyrowaveはWindowsとmacOSのSteam βで利用できる。Linuxでは、システム設定から実験的なSteamRT3クライアントを有効にする必要がある。モバイル向けSteam Linkアプリへの対応は今後の予定だ。既定では無効であり、Remote Playの詳細なクライアント設定から利用者が選ぶ。

Pyrowaveの自動モードでは、見た目の品質に合わせて各フレームを一定の大きさに調整する。フレームレートが上がれば、1秒に送るフレーム数が増えるため必要帯域も増える。品質スライダーで通信量を上下でき、ネットワークの上限を直接決めたい場合は自動ビットレートを切り、100〜500 Mbit/sを指定する。

200 Mbit/sを60 fpsで送るなら、単純計算で1フレーム当たり約3.33 Mbit、約417 kBになる。開発者Hans-Kristian Arntzenは、従来型のゲーム配信をおよそ10〜20 Mbit/s、Pyrowaveが狙う領域を100 Mbit/s超、未圧縮の1080p60・YUV 4:2:0を約1.5 Gbit/sと説明している。Pyrowaveは未圧縮映像より大幅に小さいが、一般的な動画圧縮より帯域を惜しまない中間地点に立つ。

この選択肢は、インターネット越しの配信を広く置き換えるためのものではない。ValveがGigabit Ethernetを挙げる通り、主戦場は帯域に余裕のある家庭内ネットワークである。

速さの正体は圧縮処理の引き算

Pyrowaveはフレーム内符号化だけで完結する方式（intra-only）を採る。H.264、HEVC、AV1のような一般的な動画コーデックは、前後フレームの似た部分を予測し、変化した情報を中心に送ることで通信量を抑える。Pyrowaveは時間方向の予測を使わず、動画を独立した静止画の連続として扱う。圧縮率は下がるが、前後関係を待つ必要がなくなる。

一枚の画像は、離散ウェーブレット変換（DWT）によって低周波成分と方向別の高周波成分へ5段階で分けられる。フィルターにはJPEG 2000でも使われる不可逆CDF 9/7を採用した。さらに、出現頻度を利用してデータを詰めるエントロピー符号化を使わず、変換後の係数をビットプレーンとして単純に並べる。GPUで並列処理しやすい代わりに、通信量が膨らむ。

設計上の選択 得るもの 支払うもの Steamで見える条件
前後フレーム予測を使わない フレームごとの独立性、待ち時間の削減 時間方向の圧縮効率 100〜500 Mbit/s
エントロピー符号化を省く GPUでの高い並列性 さらに大きなデータ量 他方式の5〜10倍という帯域説明
各フレームの上限を先に決める バッファを増やしにくい一定サイズ 複雑な場面では量子化が強くなる 品質スライダーと自動ビットレート

Pyrowaveは圧縮率を最大化する機能を意図的に捨て、GPU並列性、固定時間のサイズ制御、フレーム独立性を得る。Valveの100〜500 Mbit/sという設定範囲は、この設計交換を利用者側へ露出したものである。開発者は、32×32係数ブロックごとに何ビットを捨てれば画質がどれだけ変わるかを評価し、画像全体の上限内へ配分する。開発者の試験では、出力は目標値の約10〜20 byte以内に収まったという。

AD

一枚ずつ完結することが損失に強い理由

フレームが独立していれば、一枚の破損が後続フレームへ連鎖しない。前のフレームを参照する方式では、参照元が壊れると、その影響が次のキーフレームまで残ることがある。Pyrowaveは次のフレームを新しい静止画として復号するため、時間方向の傷をそこで切れる。

公開ビットストリーム案は、ウェーブレット係数を32×32のブロック単位で独立して記録する。パケット損失でブロックが届かなければ、その係数をゼロとして復元する。高周波成分の欠損なら、影響は画面の一部が一時的にぼける形になり得る。一方、画像の大まかな構造を担う最低周波数帯の欠損は深刻であり、仕様案もそのパケットへ選択的な誤り訂正を加える余地を示している。

つまり、Pyrowaveは損失をなくすのではなく、損失の影響を空間と時間の両方で閉じ込めようとする。再送を待てば遅延が増える配信では、この性質に意味がある。ただし、低周波成分まで頻繁に落ちる回線で良好な映像を保証するものではない。

ビットストリーム案は現時点でdraftと明記され、変更され得る。公開READMEには損失耐性の単位を64×64とする説明も残る一方、詳細仕様は32×32係数ブロックを定義している。安定した外部規格としてではなく、Steam βとともに動いている実装として見るべき段階だ。

0.1 ms級という数字をどこまで信じられるか

Arntzenが2025年6月に公開した測定では、AMD Radeon RX 9070 XTとRADVを使い、圧縮しにくいとした1080p・YUV 4:2:0素材を0.13 msで符号化し、復号は100マイクロ秒未満だった。別のゲーム素材は約80マイクロ秒、4K・YUV 4:2:0の素材は0.25 msで符号化した。現行READMEはさらに、1080pの符号化・復号を約0.1 ms未満、4Kを約0.2 ms未満と掲げる。

ただし、これらは開発者による特定GPU、ドライバー、素材での測定である。Steam Remote Playがホストから表示まで何ms短くなるかを測った独立試験ではない。H.264、HEVC、AV1との画質比較でも、相手側をフレーム内符号化だけ、上限厳守の固定ビットレート、最速モードへそろえている。開発者自身が通常の配信では採らない設定だと断っており、一般的な運用でPyrowaveの画質が常に上回るとは言えない。

200 Mbit/s超・60 fpsの自己評価では、並べて拡大しなければ圧縮痕を見分けにくかったという。一方、ウェーブレット圧縮は高周波成分を強く削ると、ブロック状の乱れよりもぼけや輪郭周辺の波打ちとして劣化が出る。映像の種類と設定で見え方は変わる。

高い帯域は色の精度にも使える。HDRはホストとクライアントの双方が対応すれば自動で選ばれる。YUV 4:4:4は色差を間引かないため、ゲーム画面全般よりも文字、細線、4Kデスクトップの読みやすさで利点が出やすい。処理時間と帯域をさらに使うため既定では無効であり、必要な環境だけで選ぶ機能だ。

AD

有線LANでも速くならない場合がある

Valveは映像配信の総遅延を、符号化からネットワーク転送と復号を経て表示に至るまでの合計としている。Pyrowaveが直接削れるのは主に最初と3番目だ。Wi-Fiの混雑でパケット待ちが増えている、テレビ側の表示処理が遅い、あるいは500 Mbit/sに近い通信で経路が詰まるなら、コーデックが0.1 ms級でも操作感はほとんど変わらない。帯域を増やした結果、ネットワーク遅延が増える可能性さえある。

公開APIはバージョン0.5.0で、メジャーバージョン1に達するまではAPIとABIが安定しないと明記する。直接GPUを扱う経路はVulkan 1.3世代のサブグループのサイズ制御、16ビット整数シェーダー、8ビットのストレージバッファーアクセスなどを要求する。開発者はデスクトップGPUと多くのモバイルGPUを対象にできるとしており、計算処理が弱いモバイルGPU向けには従来の描画処理を使う復号経路も用意した。ただし、Steamが内部でどのGPUを許可し、機能不足時に何へ切り替えるかは公表していない。

試すなら、Remote Playのパフォーマンスグラフを有効にし、同じゲーム、解像度、フレームレートで従来のコーデックとPyrowaveを比べる。見るべき数字は総遅延だけではない。符号化から表示までの各段階で、どこが変わり、どこが残ったかである。画質も静止画ではなく、草木や粒子、細かなUI文字など圧縮が苦手な場面で確かめたい。

Pyrowaveの価値は、すべてのRemote Playを置き換えることではなく、家庭内の有線LANで余っていた帯域を、コーデック時間の短縮へ振り向けられる点にある。安定版入りを判断する材料は、端末別の対応表と、同じ画質・回線で測った総遅延、消費電力、パケット損失時の比較がどこまで示されるかだ。