超高速ゲームストリーミング向けビデオコーデック PyroWave を自作してみた

• ゲームストリーミングでは、極めて低い遅延が必須条件となる
• PyroWave は モーション予測とエントロピー符号化を排除し、極限の速度を実現している
• **離散ウェーブレット変換（DWT）**ベースの方式で、従来の DCT コーデックと差別化されている
• 32×32 ブロック単位の並列処理と高速なレート制御の実装により、GPU でのエンコード/デコードが非常に高速
• 品質評価では H.264/HEVC/AV1 などとの比較でも、特定の状況で十分な結果を示している

---

ゲームストリーミングにおける超低遅延要件と既存方式の限界

• 近年、ゲームプレイのストリーミング需要が増加する中、ネットワーク経由である機器から別の機器へリアルタイム伝送する重要性が高まっている
• DMA、レンダリング、エンコード、送信、デコード、画面出力まで、各段階で積み重なる遅延が体験全体に大きく影響する
• 従来の解決策は、H.264、HEVC、AV1 などの GPU アクセラレーション対応ビデオコーデックを使うことだった
• しかしストリーミングでは、B フレームなどの高圧縮技術を使えず、レイテンシおよびビットレートの制約が厳しくなる

設計思想：モーション予測とエントロピー符号化の排除

モーション予測の排除 – Intra-Only 方式

• 既存のビデオコーデックにおけるモーション予測を排除し、すべてのフレームを個別に扱う
• その結果ビットレートは上昇するが、エラー耐性、単純さ、品質の一貫性などで利点がある
• デジタルシネマなどでも Intra-only 方式の利用実績がある
• このためインターネット配信には不向きだが、LAN などの高帯域環境では良い結果が期待できる

エントロピー符号化の排除

• エントロピー符号化は GPU の並列処理と相性が悪いため、全面的に除外した
• ASIC 専用や特殊機器向けにしか存在しなかった領域を、ソフトウェア方式で実現した
• FFmpeg にはない超低遅延コーデックという分野を切り開いた

ウェーブレット変換（DWT）を活用した新しいアプローチ

• 既存コーデックの DCT の代わりに、**離散ウェーブレット変換（DWT）**を採用
• ウェーブレット変換は、グラフィックスプログラマになじみ深い mip-map 構造に似ている
• 画像を複数の帯域に分離し、各帯域ごとに量子化を適用する
• 高周波帯域はより強く量子化し、視覚特性を最大限に活用する
• この過程はレート制御（rate control）とも連動している

ウェーブレットベースコーデック特有のアーティファクトと限界

• JPEG のブロッキングアーティファクトの代わりに、ウェーブレットでは主にぼやけやリンギングが発生する
• 最近のゲームで見られる TAA によるぼやけ効果とも重なるため、実際には大きな問題ではない可能性がある

高速ビットストリームパッキングと並列化

• 32×32 の係数ブロックを独立して処理し、パケット損失時の影響を局所的なぼやけのみに抑える
• 8×8、4×2 の下位ブロック構成を通じて、GPU ワークグループ単位の並列処理に最適化
• ビットプレーン符号化を用いながらも、複雑なエントロピー符号化なしで生のビットデータを保存する
• SSBO 8 ビット保存など GPU フレンドリーな方式により、メモリ効率と処理速度を最大化する

正確で高速なレート制御

• 従来のエントロピー符号化方式と異なり、各ブロックごとに省略ビット数を反復的に測定・保存して適切に比率を調整する
• 全体として最適なレート・ディストーション区間を算出し、CBR を厳密に順守する
• ウェーブレット系コーデックの強みであるビットプレーンごとの早期打ち切りを、ソフトウェアでも実現している

実際の性能と効率

• 1080p 4:2:0 を基準に、RX 9070 XT GPU で 0.13ms でエンコード/デコードを完了
• DWT、量子化など各処理工程で FP16 最適化を活用し、品質と速度のトレードオフを体感できる
• 4K 映像でも、PCI-e 転送速度よりGPU で圧縮してから転送する方が速いという実験結果が確認された
• 専用ハードウェアコーデックより最大 10 倍以上高速な処理を実現した

品質評価と他コーデックとの比較

• 比較対象：FFmpeg の GPU エンコーダ（H.264/HEVC/AV1）で、Intra-only、CBR、最小遅延モード
• PyroWave は 200Mbps、60fps 条件で、目視では圧縮アーティファクトをほとんど見分けられない
• さまざまなゲームシーンに対して、VMAF、SSIM、PSNR などの客観的品質指標でも十分な結果を確保している
• 特定の指標（VMAF など）は PyroWave をやや好意的に評価する一方、PSNR などでは内部精度の影響が表れる
• 画像にぼやけや低品質なアーティファクトはあるものの、現代的なゲームビジュアルと用途を踏まえれば、実用上大きな問題はない

結論

• PyroWave は、超低遅延かつ高速処理が求められるローカルゲームストリーミング分野で革新的な代替案を提示している
• 最新の GPU アーキテクチャと組み合わせることで、並列処理と CBR 制御に特化している
• 個人的なプロジェクトではあるが、DIY 超高速ストリーミングソリューションとして満足度は高い

[GN⁺]

Hacker Newsのコメント

• BBCが開発した、イントラ専用のウェーブレットベース超低遅延コーデック VC-2 について語っている。このコーデックはロイヤリティフリーで利用でき、現時点では ffmpeg と BBC公式リポジトリに CPU ベース実装しか存在しない。自身の修士論文として CUDA アクセラレーション版を作る予定だという。昨年の GSoC で進められた Vulkan 実装はまだ満足のいくものではない。ぜひこのコーデックを見てほしいと勧めている

  • Vulkan 実装の何が不十分なのか、もう少し詳しく説明してもらえるかと尋ねている。非難する意図はなく、純粋に興味があると述べている
  • VC-2 と JPEG XS の画質差についての経験を尋ねている。一般には JPEG XS の方が高い視覚品質を提供すると聞くが、実際の使用感が気になると述べている

• この記事は、信号特性に対して許容できる歪みとトレードオフをうまく対応づけて説明した優れた例だ。コーデックを設計する立場でなく選定する立場であっても、このプロセスをたどればよい結果を得られる。超低遅延が重要な分野に興味があるなら、VSF が複数の代替コーデックの特徴を整理したレポート(リンク)が参考になる

• 私は動画エンコードについてほとんど知らないが、エンコーダがゲームエンジンと少しでも協調できれば、ビデオゲーム配信で見落とされている実用的なアプローチがたくさんあると思う。たとえば多くのレンダリングエンジンには独自用途のモーション予測バッファがすでにあり、これをエンコードにもただで使える。しかし、発明を阻む特許がありそうで、実際には難しいのではないかと残念がっている

  • H.264 の「モーションベクトル」はビット単位の画像圧縮技法にすぎず、実際の 3D ゲームで使うモーションベクトルとは異なると強調している。3D ゲームのモーションベクトルは 3D 空間内でのオブジェクト位置変化量だが、H.264 では任意の過去フレームからピクセルブロックをコピーし、差分を JPEG 風にエンコードする方式だ。このブロックコピーのため、帯域が不足すると H.264 映像が四角い断片状に壊れて見えると説明している
  • ネットワーク遅延が 2 フレームある FPS ゲームを例に、ゲームエンジンが UI と 3D ワールドビューを別々のフレームバッファとして提供すれば、クライアントでマウス入力を受けた直後に、サーバーから受け取った前フレームに対してワールドビューだけを先回りして動かせると述べている。VR ゲームはすでにこの方法で入力遅延を補っている。完璧ではないが大きな差を生み、パララックスも深度マップを使えばある程度は擬似的に実現できる
  • センサーベースの動画エンコードのように、スマートフォンの加速度計やデジタルコンパス情報を使ってエンコードのヒントを与えられる(リンク)。2D ゲームなら背景や大型前景オブジェクトのモーションベクトルを正確に提供できる。オーバーレイ、HUD、スコアボード、字幕などの 2D 要素は別の圧縮方式で送れば、ピクセルの鮮明さを高められる。HN ではこうしたアイデアに懐疑的な人が多くて意外だと述べている
  • 自分もこの点はいつも不思議に思っていた。クライアントが多少のコンポジット処理を自分で行えるはずだと思う。たとえば背景と前景を異なる周期でレンダリングしたり、HUD には優先度に応じて鮮明さ重視のコーデックを使う方法だ。Stadia は自社製ゲームを持っていたのに単純な映像ストリーミング方式だった点がいつも意外だった。おそらくさまざまな試みはしたものの、既存の動画コーデックに比べて十分な利得が得られなかったのだろうと推測している
  • 2D スプライトゲームなら、エンコーダに非常に正確なモーションベクトルを容易に渡せる。3D レンダリングゲームでは、3D オブジェクトのモーションベクトルを 2D エンコード向けに変換する作業が現実的に役立つのか確信が持てない

• LLM（大規模言語モデル）でゲーム内状況を毎フレーム数文に要約してネットワーク送信し、受信側の LLM がそのテキストからフレームを再構成するアプローチを提案している。リアルタイムは難しく損失も大きいが、圧縮率は非常に高く、最新トレンドにも合っていると述べている

  • フレーム1の例として、「あなたは西の野原に立っており、白い家の正面玄関は板で打ち付けられている。ここには小さな郵便受けがある」のように説明できると示している
  • ブロックチェーンを使ってこうした説明を送れば、改ざん不可能な記録も作れると付け加えている
  • いつかゲームが各ユーザーのコンピュータ上で直接実行される時代が来るかもしれないと期待している
  • そのアイデアは興味深いと述べている

• このコーデック方式は、自分が研究プロジェクトで使おうとしていたものとほぼ一致する。参考までに、商用プロジェクトでは特許プールの問題から、有償標準の JPEG-XS(リンク1, リンク2) も超低遅延をうたっており、より安全な選択肢かもしれないと案内している

  • JPEG-XS は超低遅延に強みがあるが、より多くの帯域を使う。自分たちは映画/TV のポストプロダクション向けリアルタイム画像ストリーミングに活用している(事例リンク)。IntoPIX の CUDA エンコーダ/デコーダと SRT の低遅延伝送方式を使っている。快適なネットワーク環境なら、全体遅延 16ms 以内の達成は十分可能だ。データセンターと都市部のポストプロダクション室、あるいは国をまたぐ 1GbE 回線でも、複数の圧縮率で利用事例がある
  • 特許プールは安全網ではないと述べている。これは特許の橋を渡るのに料金を払う必要はあるが、その先で別の特許問題が見つかればさらに支払わなければならない構造だと説明している

• VLC の創業者が超低遅延ストリーミングプロトコルを開発中だとして、インタビュー(リンク)とデモ動画(リンク)を共有している

  • この分野でのキャリアを踏まえ、ハードウェアエンコーダと H.264 の遅延は非常に低いと強調している。NVENC は付加機能（複数フレーム予測、B フレームなど）を無効にすれば、ほぼ即時にエンコードできる。高度な処理アルゴリズムや複数フレーム待ちを必要とする方式さえ避ければ、GPU レンダリング終了直後から <10ms でエンコード可能だと説明している
  • リンク先の動画は現在視聴できないと述べている

• この CODEC が HTJ2K（High-Throughput JPEG 2000）と同系統のアルゴリズムに基づいていると認識しており、もし筆者が見ていれば、HTJ2K との違いを説明してもらえると面白そうだと述べている

• ローカルネットワーク配信に絞るなら、最新コーデックの多くの機能は不要だと説明している。帯域を 100Mbps 程度確保できるなら、処理速度を速くして遅延も小さくできる。例として Microsoft DXT コーデックは最新コーデック機能をほとんど持たないが（エントロピー符号化、動き補償、デブロッキングなし）、4～8 倍圧縮でハードウェアデコードが可能なため、全体遅延の短縮に有利だと述べている。ただし、最適化してもディスプレイ自体で 30～100ms の追加遅延が発生する点を指摘している

• 開発結果は本当に驚くべきもので、いつか Moonlight や類似プロジェクトに適用される日を期待していると述べている

  • 自分も同じ考えだと述べ、時間とスキルがあれば自分でこのコーデック対応を Moonlight に追加してみたかったとしている。LAN で Sunshine/Moonlight を使って Clair Obscure のようなゲームを配信する際には、十分に低い遅延が不可欠だと言及している

• このコーデックはまだなじみが薄く専門的な分野なので、競合コーデックとの比較資料を見つけにくいという意見を引用しつつ、H.264/AVC（ゼロ遅延 ffmpeg オプション）や JPEG XS とのベンチマークが気になると述べている。ffmpeg コマンド例と詳細なエンコードパラメータまで共有している