Steamリモートプレイに新コーデック「Pyrowave」、帯域5〜10倍で遅延を削る

データ量を削るのが普通のストリーミング用コーデックで、Pyrowaveは真逆を行く。帯域はふんだんに使い、その代わり遅延を削る。そんなコーデックがSteamのリモートプレイに入ったにゃ。

9月22日に配信されたSteamクライアントのベータ版（プレビュー／ベータチャンネル）で、リモートプレイに実験的なビデオコーデック「Pyrowave」が追加された。更新内容はSteam Deckのお知らせ欄にあるベータ版クライアントの更新告知に載っていて、詳しい説明はValveのリモートプレイ担当者がSteam Remote Playのディスカッショングループに投稿している。

VKD3D-Proton開発者がPyrowaveを作った

Pyrowaveを作ったのはHans-Kristian Arntzen氏。Direct3D 12をVulkanの上で動かす「VKD3D-Proton」の開発者として知られる人物で、コーデックのソースは氏のGitHubリポジトリで公開されている。

公式の説明で目を引くのは、帯域の使い方をはっきり書いているところだね。主なポイントを訳して引用するとこうなる。

公式の解説より・日本語訳（主な項目だけ）

• 高帯域：ほかのストリーミング用コーデックの5〜10倍の帯域を使う。コンピューターは少なくともギガビットのイーサネットでルーターに直接つなぐのが望ましい
• 低遅延：GPUでフレームのエンコードとデコードを行い、ネットワーク環境が良ければエンドツーエンドの遅延をきわめて小さくできる
• YUV 4:4:4とHDRに対応：HDRはホストとクライアントの両方が対応していれば自動で選ばれる。YUV 4:4:4は帯域と処理時間を少し多く使うので初期状態ではオフ。デスクトップを配信するときや、4Kの画面で文字を読むときにはオンにするとよい
• ビットレート：通常は画質を基準に自動で調整され、品質スライダーで上下できる。自動をオフにすれば100Mbit/s〜500Mbit/sの範囲で固定値を指定できる

H.264やH.265、AV1のような一般的なコーデックは、ネット越しの動画配信で通信量を減らすために作られてきた。圧縮を強くすればデータは小さくなる代わりに、エンコードとデコードに時間がかかる。家の中の有線LANのように帯域が余っている環境なら、圧縮を軽くして速さを取るほうが理にかなう、という考え方なんだと思う。

遅延の合計は「エンコード＋ネットワーク＋デコード＋表示」の4つの足し算になる。公式の投稿では、配信中にリモートプレイ設定のパフォーマンスグラフを表示すれば内訳を確認できるとしたうえで、「環境によっては新しいコーデックの恩恵がないかもしれない」とも書かれている。万能の上位互換というより、条件がそろった環境向けの選択肢として出てきた形だね。

Pyrowaveは初期状態では有効になっていない。リモートプレイの詳細なクライアント設定から自分でオンにする仕組みだよ。

• Windows / macOS：Steamのベータ版で利用可能
• Linux：Steamのベータ版で、システム設定から実験的な「SteamRT3」版クライアントを有効にしたときに利用可能
• モバイル端末向けSteam Linkアプリ：対応は「近日」予定

告知の直後は、ディスカッショングループで「設定に項目が出てこない」という声が相次いでいた。その後、担当者が更新後のビルドの情報を示し、Steamを更新し直したら項目が現れたという報告も続いている。試すときは、ベータ版が最新の状態になっているかをまず確認したい。

Moonlightに勝てるのか、Redditが議論する

この更新はRedditのr/Steamでも取り上げられた。最初に出てきたのは、そもそも何の話なのかという素朴な疑問だった。

これって、PCから別の機器にストリーミングするような話？ いまいちよく分かってない。

これに対しては、家庭内のLANでのストリーミング向けだと答える返信がつき、さらに別の人がコーデックの立ち位置をかみくだいて説明している。

家庭内での低遅延ストリーミングを想定した、高ビットレートのコーデックだよ。ほとんどの動画コーデックは、ネット越しの配信で通信コストを下げるために、配信業界によって作られている。これはその隙間を埋めるコーデックなんだ。

「有線だけ？」「Quest 3でのVRにも使える？」という質問も飛んだ。公式の説明は有線を「推奨」しているだけで、無線を禁じてはいない。VRのストリーミングについては、今回の告知では何も触れられていないにゃ。一方で、「リモートプレイはインターネット越しでも使える通常の仕組みの一部」とする返信もあった。仕組みとしてはその通りだけど、100Mbit/s以上を前提にしている以上、Pyrowaveが本領を発揮するのは実質的に家の中のネットワークだと見ておくのが無難だね。

盛り上がったのは、Sunshine／Apollo（配信する側のPCで動かすホスト）とMoonlight（受け取る側のクライアント）の組み合わせとの比較だった。遅延の少なさで評判のツール群で、Steam標準のリモートプレイから乗り換えた人も多い。

Valveのストリーミングが、性能面でMoonlight／Apolloに追いついてくれたらうれしい。

それこそが今回の狙いなんだと思う。

ここ数か月のプレビュー／ベータ版で、少なくともかなり近いところまで来ていた。1年前よりは確実に良くなっている。Steamとの統合やコントローラーのプロファイルがあるから、いまはたまに引っかかるくらいなら我慢できる。前はとてもそうは思えなかった。

一方で、厳しい声もある。性能以前に、細かい設定項目が足りないという指摘だ。

もう一度試してみるかも。Steamのストリーミングには、MoonlightやSunshineにある基本的な便利機能が抜けていると感じていた。たとえばホスト側のディスプレイを消したままにする、コーデックを細かく選ぶ、標準的でない解像度で配信する、といったこと。

さらに強い調子で「まともに動かない。見た目も動作も悪く、Sunshine／Apollo＋Moonlightしか選択肢がない」と書き込んだ人もいた。これには「今回のはまさに画質と性能を良くしようとする取り組みなのでは？」と返されている。不満の中身と今回の更新の方向が、ちょうど重なっていたわけだね。

最後に話題になったのが仮想ディスプレイだ。

仮想ディスプレイを追加してくれたらいいのに。それだけでMoonlight／Apolloのほうがはるかに上になっている。

これには、以前のSteamクライアントのベータ更新を示す返信がついた。そこには、WindowsでSudoVDAという仮想ディスプレイドライバーに対応したと書かれている。該当の告知を確認すると、SudoVDAを入れて詳細ホストオプションでメインのディスプレイに選ぶと、クライアント側の表示設定に合わせた仮想ディスプレイをSteamが自動で作る、という内容だった。

知らなかった、ありがとう！ ただ最後のところが気になる。Moonlightだと仮想ディスプレイの解像度を簡単に変えられるのが気に入っていて、いつもSteam Deckの出力に合わせたいわけじゃないんだ（うちのPCだと4Kは常に回せるとは限らないから）。

仮想ディスプレイは用意されつつあるけれど、細かく自分で決めたい人にとってはまだ物足りない。そんな温度感だね。

低遅延のコーデック、HDRと4:4:4の色、仮想ディスプレイと、Moonlight派が挙げてきた差は、ベータ版の中でひとつずつ埋まり始めている。残っているのは、Steam Linkアプリへの対応と、スレッドで名前が挙がった細かな設定項目になりそうだにゃ。