まさに俺が考えてたことだ。自分でこのコーデックのサポートを追加する時間と専門知識があればいいのに。Sunshine / Moonlight経由でLAN上でClair Obscureをストリーミングするのが俺の使い方で、レイテンシーはもっと良くできるはずだ。

2Dスプライトゲームなら、OMG、エンコーダーにかなり正確なモーションベクトルを提供できるよね。3Dレンダリングゲームについては、ちょっと自信がないな。レンダリングエンジンは3Dオブジェクトのモーションベクトルを持ってる（または持てる）けど、それをエンコーダーが使う2Dの世界に変換しなきゃいけない。これが合理的かどうかは分からないし…エンコーダーにとってどれだけ役立つかも疑問だな。

ゲームには通常、モーションベクトルバッファはないと思う。比較的簡単にレンダリングできるかもしれないけど、それってちょっと鶏と卵の問題だよね。

動き予測みたいなものは、ほとんどのレンダリングエンジンがそのための専用バッファを持ってるから、タダでできるよ。透過性やシェーダーアニメーションにはうまくいかないけど、後者はシェーダーが動きベクトルも計算できればうまくいくかもね。

H.264の「動きベクトル」は、奇妙なビット操作や画像圧縮のハックで、実際の動きベクトルとは関係ないんだ。 3Dゲームでは、動きベクトルはオブジェクトの3D空間における位置の前のフレームと現在のフレームの違いを指す。H.264では、「動きベクトル」は基本的に、ある任意の前のフレームからこの矩形のピクセルの塊をコピーして、その参照ピクセルとコピーの違いをJPEGのような技術（DCTなど）でエンコードするってこと。このブロックコピーが原因で、H.264の動画は帯域幅が落ちると四角いゴチャゴチャになっちゃうんだ。

最終的な圧縮は、ユーザーの入力だけを送って、向こうでゲームの状態を再構成することだね。

これについても考えたことあるよ。ほとんどのクライアントは、まだ少しは合成ができるはずだし。例えば、背景のオブジェクトを前景のキャラクターよりも低い解像度や頻度でビルボードレンダリングして送ったり、優先度をつけてHUDオブジェクトを更新したり、明瞭さを優先するCODECを使ったりとか。スタディアが自社でゲームを作ってたのに、結局はただのストリーミングビデオになってしまったのはいつも衝撃だった。レイテンシの改善はエッジに展開されたGPUとWi-Fi接続のコントローラーから来るはずだったのに。まあ、もしかしたら彼らはこういうことを試してみたけど、戦闘テスト済みのビデオCODECに対して得られる利益が少なかったのかもね。

君の言う通りだと思う。ゲームストリーミングサービスへの接続が2フレームのレイテンシを追加する場合、プレイヤーがFPSをプレイしていると仮定しよう。ゲームエンジンができることの一つは、ゲームのUIと「3Dワールドビュー」を別々のフレームバッファとして提供することだね。そうすれば、クライアントでマウスを動かすと、ソフトウェアはサーバーから来た次の2フレームの3Dワールドビューを瞬時に変換できる。VRゲームはすでにこういうことをやっていて、ゲームがVRヘッドセットの最大FPSを下回っても、頭の動きには反応できるんだ。完璧ではないけど、視差がないし、以前は視界に入ってなかった領域を表示できないけど、それでも大きな違いがあるよ。（もちろん、VRではこれが重要で、これをしないとゲーム内のレイテンシスパイクがプレイヤーに即座に乗り物酔いを引き起こすからね。もしやりたければ、深度マップを使って視差を偽装することもできるし。）

最初に始めるのにシンプルなアイデアとしては、センサーアシストビデオエンコーディングみたいなものがあるね。スマホの加速度センサーやデジタルコンパスを使って、ビデオエンコーディングにヒントを与える感じ。あと、2Dゲームでは、シンプルな横スクロールゲームが背景や大きな前景の直線的に動くオブジェクトの動きベクトルを非常に正確に提供できると思う。君のアイデアに反対してる人がこんなにいるのは驚きだよ。HNには「どうやってできるかわからないなら、できない」って考える人が多い気がする。追記：HUDや地図、スコア、字幕、メニューなどの2Dグラフィックオーバーレイも、2D圧縮データとして送信できるから、そのデータの圧縮がより良くなるかも。例えば、シンプルな形状のために、もっとシャープなピクセルパーフェクトエンコーディングが可能になるかもしれないね。

JPEG-XSは低遅延にはいいけど、帯域幅は多めに使うんだ。映画やテレビのポストプロダクションで、低遅延の画像ストリーミングに使ってるよ。 https://www.filmlight.ltd.uk/store/press_releases/filmlight-... 今はIntoPIXのCUDAエンコーダー/デコーダーを使ってて、低レベルのトランスポートにはSRTを使ってる。 decentなネットワークなら、エンドツーエンドの遅延は16ms未満にできるよ。データセンターにマシンを設置して、街の中心にあるポストプロダクション施設で使ってるお客さんもいるし、たいていは10GbEリンクを使ってる。でも、国をまたいで1GbEリンクを使って、高圧縮率で運用してる人もいるよ。

特許プールは安全にはならないよ。ただの特許トロールが橋を渡るためにお金を取ってるだけさ。橋を渡った後に、さらに別の特許トロールからの恐喝に対する保険なんて提供してないしね。

この分野で働いてきたけど、ハードウェアエンコーダーとH.264はかなり優秀だよ。NVENCは遅延がほとんどないし（そう設定すれば、フレーム予測やBフレームみたいな遅延を増やす機能を無効にすればね）。遅延を増やす要因は、より高度な処理アルゴリズムや、複数フレームを待つ必要があるスキームだよ。それを無効にすれば、エンコーダーはGPUがレンダリングをやめた瞬間からフレームの処理を始められるし、10ms未満でエンコードできるよ。

残念ながら、利用できないみたい。

それ、興味あるわ。

いつかは、ゲームがエンドユーザーのマシンでローカルに動く時代が来るかもね。

フレーム1：君は白い家の西にある開けた野原に立っていて、前のドアには板が打ち付けられてる。ここには小さな郵便受けがあるよ。

説明をブロックチェーン経由で送信して、不変の記録を残そう。