Twitterで、@masafumi氏が、Google I/O での興味深いセッションについて紹介されていたので、内容を簡単にまとめてみました。私自身は専門家ではありませんので、詳しい方の突っ込み補足お待ちしています。当たり前ですが、以下はすべて私個人の見解です。
Google I/O 2019 Stadia のストリーミング技術に関するセッション: 新 masafumi's Diary
Google I/O 2019ではStadia Streaming Tech: A Deep DiveというセッションでStadiaのストリーミング技術や遅延に対する対策などの技術を紹介しています。
このセッションも動画が公開されています。
ゲームをGPU搭載したサーバで実行してクラウド上で実行してストリーミングするサービスはこれまでいくつもありましたが、Stadiaならではの部分などを判断するのによさそうですね。
YouTubeの動画はこちらです。
Stadia Streaming Tech: A Deep Dive (Google I/O'19) - YouTube
発表者は、GoogleでStadiaを開発している方で、特にゲームのPlayability（操作性とでも訳せばいいでしょうか）に注力しているチームメンバーの皆様。
Playabilityに必要な要素は、大きく分けて、ユーザの操作にリアルタイムに反応すること、まちまちなネットワークの状況、変動にも挙動が変わらないこと、ゲーム開発者の想定通りの体験を届けられることの3点。
このセッションでは、次の5つのトピックについて順に説明します。
1. バックグラウンド（今までのビデオストリーミング技術）
2. ユーザエクスペリエンスリサーチ（Googleで実施した、ストリーミングでのゲームに必要なものとは何かを理解し、それを計るための調査）
3. Streamer（Googleのクラウドゲーミングを実現するための技術基盤）
4. Project Stream（Streamerを改善するための大規模テスト）
5. Playability ToolKit（最適化のためのゲーム開発者向けAPI、ツール類の紹介）（本稿では省略）
バックグラウンド - 動画配信とクラウドゲーミングの違い
典型的な動画配信は、下図のような構成となっています。CDNなどのキャッシュがあり、数秒から数分のバッファをもって送信することで、効率的に、ネットワーク帯域の変動に影響されずに映像を届けられることができます。
一方、クラウドゲーミングは、ユーザが操作するので、バッファも、キャッシュも持つことができません。時間がかかるエンコーディングフォーマットも使えません。
これが、典型的なクラウドゲーミングのプラットフォームです。クラウドで生成された映像・音声がエンコードされ、インターネットで転送され、クライアント側でデコードされます。同様に、ユーザの操作や音声が、クラウドに送信されます。これがすべてリアルタイムで発生するのです。
なぜそんなに難しいのでしょうか。成功の鍵となるのは、あらゆる環境にいるユーザに対し、変わらない(Consistantな）体験を、大きなスケールで届けることです。つまり、あらゆるエンドポイント、ハードウエアやソフトウエアの違い、ネットワーク品質の違いに、対応しなければならないのです。
レイテンシ
クラウドゲーミングと聞いて最初に思いつく課題は何でしょう。レイテンシですよね。
Googleでは、レイテンシがゲームに与える影響について、詳細に調査しました。
例えば、HDMI信号で映像を届けるまでに16-33ms要します。モニタのリフレッシュレートにより、4-16ms必要になります。USB周辺機器のポーリングで、8msかかります。ゲーム用USB機器では、専用のハードウエア、ソフトウエアでレイテンシを減らす努力をしていても、レイテンシはゼロにはならないのです。
神経学の授業ではありません。まだクラウドゲーミングの話をしています。人間の神経系でも、レイテンシがあるのです。映像を脳内で処理するのに、最低13msかかります。脳からの指令が指に届くまで、70-130msかかります。データセンターからユーザまでデータを届けるより、脳から指に指示が届く方が時間がかかるのです。
レイテンシの影響を軽減させること、ユーザにレイテンシを気付かせないことが我々のゴールです。
映像品質(Visual Fidelity)
映像の品質（再現性？）が、次の大きな課題です。
我々は、映像品質と応答性のバランスを取らないと行けません。クラウドゲーミングを実現するには、コーデックと、エンコーダ・デコーダを理解し、正しく選択する必要があります。
コーデックには、相当量の開発や最適化をして、リアルタイムでの品質、応答性を実現する必要があります。
エンコーダは、選択したコーデックと、エンコードストラテジ（エンコード設定？）で映像を変換しますが、エンコーダは、その性質上、ラグが発生したり、最適な品質を維持しようとOvershoot(上振れ）したり、Undershoot(下振れ）したりします。
そして最後に、デコーダが、変換された映像を、ユーザのデバイスで再生できる形式に戻します。デコーダも、課題満載です。まず、デコーダは統一されていません。チップセットも、ドライバも、能力も、性能も異なります。
これらを常にコントロールすることが、スケールするために必要です。
下記の例のように、メニュー画面では早いフレームレートで画面が切り替わるのに対し、ゲーム画面では、フレームレートは低くても、高画質の画像が必要になります。ゲーム内で、このようにメニュー画面とゲーム画面を切り替えても、エンコーダがリアルタイムで高品質の映像を届けなければならないのです。
ネットワーク品質
ネットワークも大きな課題です。ネットワークの障害に対応したり、帯域の競合に対応したり、というのを、リアルタイムで行わなければなりません。
ゲーム操作性 (Playability)
最後に、ゲームの操作性という課題があります。これは、ゲーム自体、ゲームのプレイヤー、そしてネットワークが複雑に影響してきます。客観的な指標と主観的な指標があり、フレームレート、解像度、帯域、遅延、品質、スムーズさ、すべてが影響するのです。
ユーザエクスペリエンスリサーチ
Googleでは、それぞれの要素がゲーム体験にどう影響するかを科学的に測定するため、大規模な調査を行いました。ゲーム業界で使われる、MOSという主観的な指標を利用しました。
短時間から長時間のゲームセッションのあと、ユーザは1から5の評価をつけます。フリーフォーマットでの回答も任意で可能としました。
また、評価に使うゲームタイトルすべてに対し、ベースラインとして最高の環境での評価も測定しました。我々のゴールは、6000ドルもするような最高スペックのPCと同じ体験を、ブラウザで実現することです。
それぞれの要素に関する調査を、我々のプラットフォームに整合する形で分離させました。ネットワーク帯域、コーデック、フレームレート等です。それぞれの要素は、全体としての体験の評価に対して、大なり小なり影響を与えていますが、それら自体、相互に強い因果を認めることができます。そのため、個別の条件に対しての影響と、相互に変化した結果の影響を調べる必要がありました。
そして、莫大なテストを実施しました。ツールを開発して、様々なネットワーク環境を再現し、各種プロトタイプと、各種rate-adoptation(ネットワークの状況に応じて利用帯域等を変更する？）テクニック、コーデック、インフラで条件を変えてテストしました。
テストは、2つの手法で実施しました。1つは、Googleのラボで、制御された環境下で、変数を操作して実施しました。1500人を超えるテスターに、1万時間以上、決まった手順でゲームをプレイしてもらいました。これは、Project Stream（2018年10月から2019年1月まで実施された、Chrome上で著名ゲームをプレイするβテスト）の開始前に行われました。
2つめの手法として、さらに広い範囲でのテストを行いました。これには、Google社員のゲーミングコミュニティが参加しました。彼らに対し、他のゲームと同じようにプレイしてもらいました。これにより、あらゆるEndpoint、ネットワーク、場所の違う環境下でのEnd-to-endでの体験のフィードバックを得ることができました。Assasin's Cread だけでも、2500人以上のGoogle社員から、24000時間以上のプレイ時間のなかで、A/Bテストをローンチ前に実施することができたのです。
レイテンシ
我々は、レイテンシだけでも、大量のテストを実施しました。
まず、レイテンシの影響を理解するには、ゲームの違い、ジャンルの違い、メカニクスの違いからくる影響の違いを理解することが必要です。同じゲームの中でも、メカニクスが違えば、レイテンシの要求も変わってきます。逆に、同じメカニクスでも、ゲームタイトルが変われば、違った挙動、要求になります。
また、プレイヤーの習熟度によっても、レイテンシを感じるかどうかが変わってきます。初心者であれば、スポーツゲームのレイテンシを異常なくらい引き上げても違和感を感じないこともあります。
そのため、調査は、ゲーム・ジャンル・メカニクスの違いだけでなく、習熟度の違うユーザで、広く行われました。
さまざまなネットワーク障害を再現して、それを伝えずに、ユーザにゲーム体験を評価してもらいました。
調査を進めていくと、レイテンシがゲームにどのような影響を与えるかの詳細が分かってきただけでなく、快適なゲーム体験を提供するために求められる時間制約（入力を受けて、映像をレンダリングして戻すまでの制限時間）も分かってきました。
映像品質
ゲームストリーミングを語るとき、映像品質はレイテンシほど重視されませんが、映像品質も、ゲーム全体の評価と大きく関係することが分かりました。
また、映像品質には複数の要素が影響します。コーデックには、スケーラビリティや、4K映像パフォーマンスから、最終的にVP9を使うことになりました。また、ビットレートも要素の1つです。一般的に、高いビットレートであれば、高い映像再現性が得られます。ですが、現実には、ビットレートに関する調査を行うには、スクリーンサイズ、解像度、フレームレート、そしてすべてのエンコーダの設定値を考慮しなければなりません。PSNRやSSIMといった指標も参照しましたが、それよりも、プレイヤーに与える影響に注目しました。ほとんどの場合、結果は予想通りでしたが、驚くべき結果もありました。例えば、低いビットレートでは30FPSの方が評価が高いこともありました。ですが、だからといって帯域が狭い時は30FPSに落とすということにするのではなく、狭い帯域でも60FPSを実現するために動的な解像度の変更などの解決策を導き出すこととなりました。
我々の調査から得られた最大の結果は、我々で操作できる変数のそれぞれが、どの程度の許容度があるかということが分かった点です。
それぞれの変数がまとまって、全体としてのゲーム体験の評価につながるのです。我々が取り組まないと行けないのは、変数それぞれが、決められた許容度の中に収まるようにすることです。
精緻なバランスをとることで、データに裏付けされた、素晴らしいゲーム体験をユーザに届けることができます。Streamerでどのようにそのバランスを取ったのか、説明します。
Streamer
Streamerは、ゲームストリーミングのために開発されたストリーミングエンジンです。品質を最大化しつつ、レイテンシを許容範囲に収めるためにリアルタイムで判断をします。WebRTCなどのオープンスタンダードに基づいて、ブラウザや、TV、携帯電話などあらゆるプラットフォームをサポートします。
本日は、ゲームストリーミングの中でのrate adoptationについて説明します。帯域、パケットロス、遅延等のネットワークの状況を継続的に監視、予測して、リアルタイムで調整します。難しいのは、たくさんの情報が必要で、それを見に行かないといけないことです。そして、再度見に行くまで、その情報が変化したかどうか分からない点です。その中で、戦略ゲームと同じように、リアルタイムで品質とレイテンシのあいだでどうバランスをとるか、判断をする必要があります。完璧なクラウドゲーミングを実現するためのシンプルな法則はないのです。常にトレードオフの連続です。
ゲームのなかで探索アルゴリズムを実装したことのある方はいますか。探索アルゴリズムを実装するには、既存のよいアルゴリズムを実装するところから始めます。例えば、エースター探索アルゴリズムです。しかし、実装していくと、たくさんのエッジケースに突き当たります。なので、別のアルゴリズムを加えたり、ヒューリスティックを追加したりして、動くモノを作りますよね。
Googleが、このような複雑な問題を解くにあたってユニークな立場にいることを説明しましょう。Web検索が、Googleの文化を形作ってきました。Web検索を実現するためのアプローチとして、アルゴリズムを使い分けたり、ヒューリスティクスを使ったり、人間の知恵を加えたり、そして品質基準測定を自動化したり、複雑な現実の事象を機械的に処理できるようシンプルにしたり、強化学習を加えたりしてきましたが、それらはすべて、クラウドゲーミング用のストリーミングプラットフォームにも必要なモノなのです。
PageRankは非常に重要な検索アルゴリズムでしたが、それだけではあらゆる状況に対応するには不十分です。バランスが重要なのです。Web検索でも、正確さを求めて絶対正しい結果だけを表示して一部の関連するかもしれない結果を見せないでおくか、逆に多少間違いを含んでいても、関連するすべての結果を見せるか。クラウドゲーミングでも、戦略ゲームでも同じです。両極端の間でバランスを取って、プロダクトとしての立ち位置を決めないといけません。Googleには豊富な経験があります。
ではどうやってクラウドゲーミングエンジンを作るのでしょうか。例えば、レイテンシと品質のバランスです。不完全でノイズのある信号から、現在の状況を把握して、何をすべきか判断しなければなりません。しかし、常にどちらかを取らないといけないわけではなく、技術の発展により両方を解決することもあります。たとえば、AV1コーデックで、同じ帯域でもより高品質の映像を届けられます。
ビデオエンコーダの基本的な仕組みと、ビデオフレームの種類の違いについて説明します。ビット数を節約するため、エンコーダは、最初だけすべての映像を含んだフレームを送信し、その後は、変化した部分だけを送信します。すべての映像を含んだフレームを、Iフレームと呼びます。カメラで撮影したjpeg画像のようなモノです。Iフレームはとても大きいので、その後は、1つ前のフレームから変化した領域だけを送ります。それが、Pフレームと呼ばれます。1度Iフレームを送れば、その後、Pフレームを送り続ける限り、映像は途切れません。もしPフレームを失ってしまったら、再度Iフレームを送る必要があります。
他には、Bフレームと呼ばれるものは、その後に届くフレームがないと映像を再現できません。これを使うと、レイテンシが増加してしまうので、クラウドゲーミングでは使えません。
ゲームの中では、変化の激しいシーンと、変化のないシーンがあるので、各フレームのサイズは変動することができます。
多くのエンコーダは、パワフルですが計算量が多く、時間のかかる、プリエンコーディング処理を行って、ベストなエンコード戦略を探ります。他にも、よくある手法として、複数のエンコード戦略でエンコードした後に最適なモノを採用したり、極端なケースでは、Blu-rayのエンコードでは、考え得るエンコード設定のすべての組み合わせを試して、最低ビットレートで最高品質の映像を実現するパスを探します。彼らには、何週間もエンコードに費やすことができますが、我々、クラウドゲーミングでは、数msしか余裕がありません。なので、どのような分析をして、どのような分析をしないか、慎重に選ぶ必要があります。
こちらが、ネットワークの構成をシンプルに表現したモノです。エッジデータセンターから、プレイヤーに届くまで、いくつものホップを経由します。我々のエッジデータセンターは、ユーザに限りなく近い場所にある必要があります。光の速度も、レイテンシの計算に入れなければならないからです。
ネットワークは、相互に接続された不均一のデバイスで構成します。それぞれのデバイスに、それぞれの特徴があり、それぞれ、バッファ方法が異なります。それぞれのデバイス間のネットワーク速度も異なり、物理的距離から、最小レイテンシも生まれます。
それぞれのデバイスにはバッファが存在し、リンクスピードが遅く、まだパケットが転送できない場合にそれを吸収します。データセンタのルータのように、バッファが小さいものもあれば、大きいバッファのものもあります。バッファの大きなデバイスは、過去に有名だった、Bufferbloatという事象を引き起こすことがあります。バッファが一杯になってしまうと、バッファに溜まったパケットが送信されず、パケットが詰まってしまい、レイテンシが発生します。バッファがあふれてしまうと、パケットがロスし、再送する必要があります。
なので、受信側で、スウェーデンのGoogleで開発したWebRTCのエクステンションを使い、バッファを無効化して受信したパケットをすぐに次に引き渡す様にしました。我々のアプリケーションでは、パケット詰まりを制御し、バッファリングを極力削減するのがとても重要です。
次のスライドで、そのための手法について紹介します。
こちらが、インターネットでよく使われる、CUBICと呼ばれる輻輳制御の方法です。これは古い手法ですが、うまく動くのでよく使われます。複雑な部分は省き、議論のために簡単に説明すると、この手法では、パケットロスが発生するまで転送レートを増やしていきます。パケットロスを検知したら、少しだけ転送レートを減らして、そのレートを安定状態とします。多くの動画ストリーミングサービスが、今でもTCPとCUBICを使っています。
しかし、クラウドゲーミングでCUBICを使うと、大変なことになります。パケットロスが発生すれば、ユーザの画面がフリーズし、フレームを再生するまで数百msかかるためです。
より適切な方法がこちらです。1980年代に活躍したコンピュータサイエンティスト、Van Jacobsenが、インターネットを輻輳から救いました。VanはいまGoogleにいます。彼が気付いたのは、CUBICが開発された時代では、ルータのバッファは今よりずっと小さかったのです。パケットロスを指標とするのは、バッファが小さい時には有用でした。彼は、新しいアルゴリズム、BBR（Bottleneck Bandwidth and Round Trip Time)を開発しました。BBRは、パケットロスの代わりに、遅延を指標とします。まず、遅い速度でデータを送信し、RTTが増加するまで速度を上げ続けます。RTTが増加したということは、そこでバッファにパケットが溜まりはじめたということで、そのスピードがBottleneck Bandwidhになります。
クラウドゲーミングでも、BBRを使うことで、レイテンシの発生しない最大速度で映像を転送できるのです。
次に、今までのビデオストリーミングに使われてきた、DASH（Dynamic Adaptive Streaming over HTTP)について見てみましょう。DASHは、とても堅牢で、適用性もあり、あらゆるところで利用されています。レイテンシ増加や、Wi-FiからLTEネットワークへの変更など、あらゆる状況に耐えることができます。DASHは、映像と音声を、通常5-10秒の小さなかたまりに分割して送信します。そのかたまりは、最大のネットワーク速度で転送されます。たとえ10Mbpsの動画でも、かたまりは、150Mbpsで送られます。ネットワークが遅く、クライアント側でバッファができない場合は、リバッファリングが発生し、DASHプレイヤーは、低いビットレートのストリームに切り替えます。この処理は、数十秒といった、比較的長時間のインターバルで行われます。DASHストリームは、さらに、シーク（早送り、早戻し）を行えるよう、頻繁にIフレームを挿入します。グラフのオレンジの部分がそのIフレームです。これらの特徴は、クラウドゲーミングには不適です。
クラウドゲーミングにより適したものを見てみましょう
こちらが、ネットワークが安定している状態でのクラウドゲーミング基板の動きです。Congestion(輻輳/パケ詰まり) Controllerが、フレームごとに、ビットレートを指定していることが分かります。その時点での、ネットワーク経路上のバッファの状態を予想して、ビットレートを選択しています。DASHと異なり、何らかの障害が起こるまで、Pフレームが継続的に送信されます。Iフレームは、要求された場合にのみ送信されます。Iフレームは、品質を落としても小さいサイズに調整されます。Congestion Controllerはパケットごとのフィードバックを常に監視し、ビットレートを調節しています。下図の5つめのフレームでは、Controllerはバッファの増加を検知し、ビットレートを落としています。いままでの輻輳制御アルゴリズムと異なり、我々のアルゴリズムは、バイト単位ごとではなく、フレーム単位ごとに制御する必要があります。さもなくば、フレームの半分の送信が遅延してしまうことがあるためです。
ネットワークに障害が発生したときの動きです。Congestion Controllerはすぐに復旧に動きます。フレーム3，4付近で、速度が低下し、ビットレートを20Mから15M、15Mから12Mに削減したにもかかわらず、バッファが溜まってしまいます。5フレーム目で、復旧できないほどパケットをロスしてしまったと判断し、Iフレームを要求します。Congestion Controllerはあらゆるネットワーク環境、デバイス、トラブルに、不十分な情報のなか対応しなければなりません。
こうやって、レイテンシを感じさせること無く、高い品質のクラウドゲーミングを配信できるのです。
今までのGoogleの経験によって、このような体験をプレイヤーに届けることができます。msレベル、時にはnsレベルでチューニングし、レイテンシを感知できないレベルにしつつ最大の品質を実現します。
あらゆる測定値、モデル、フィードバック、アクティブラーニング、センサーデータを短いフィードバックループを回すことで、緻密にチューニングされた体験を作り上げます。ハードウエア、ソフトウエアエンコーダを、ネットワーク環境に沿った形でチューニングしています。高度な予測モデルで、カオスなWi-Fiネットワーク、LTE回線に備えています。
今まで説明してきた取り組みは、Googleの3つの得意分野に基づいています。
End to Endでプレイヤーの体験を管理する無類のインフラストラクチャー、ハードウエア、データ処理、セキュリティ等のテクノロジーへの継続的投資、そして我々のパートナーが成功するためのプロダクトを作るための青写真を作り上げてきたこと、これらすべてを、未来を発明するという、10倍のメンタリティーで進めてきました。
Googleのネットワークインフラの図です。90のインターネットエクスチェンジを持っており、世界中に100の相互接続設備があり、7500以上のエッジノードが、ネットワーク事業者やISPの奥深くに存在しています。これらがプレイヤーのすぐ近くに存在することで、大きなスケールで、変わらない体験を提供できるのです。
クラウドゲーミングは、Googleのテクノロジーへの継続的な投資も活用します。ムーアの法則から逃れるためのハードウエアアクセラレータや、各種Googleサービスのデータから得られるレイテンシ最適化のための情報、そしてゲーム開発にあらゆる形で寄与するAI。単にテクノロジーが何であるかだけでなく、それをどう適用するかというところに、Googleが、常に利用できる、セキュリティの高いクラウドゲーミングプラットフォームを提供できる理由があります。
そして、そのすべてに深く染みついているのが、スケールを目指すGoogleのDNAです。Googleのエンジニアリングの基礎にあるものです。
Googleには、無類の能力、そして意思によって、最高のエンジニアを最も困難な問題に取り組ませます。YouTube,Mapのような過去の成功経験もあります。
また、世界中のプレイヤーに届けることができます。Webブラウザ、リビングルーム、そしてモバイルです。
そして、Googleはいままで多くのインターネットプロトコルやアルゴリズムを発明し、大きく影響を与えてきました。HTML5、QUIC、WebRTC、VP9、BBRなどです。
Googleのクラウドゲーミングプラットフォームは、Googleの他の成功したスケーラブルなプロダクトと同じコアコンセプト、ベストプラクティス、テクノロジーに基づいているのです。
Project Stream
Streamerが安定してきたら、次のステップは、それをテストし、評価し、必要に応じて最適化することです。
Assasin's Creedは、完璧なテストとなりました。あらゆる環境に対応し、つまりあらゆるビットレート要求があり、あらゆるメカニクスがあり、つまりあらゆるレイテンシ要求があり、そして多くのユーザがそのゲームをプレイしたいと欲していて、アメリカ全土から多くの利用者を集めることができました。
内部的に、2つの主なゴールがありました。Streamerをテストし改善すること、そしてゲーム開発者と一緒に最適化ツールを作っていくことです。
First Buildを受け取った時点で、あらゆる新しいことを試すことができました。Ubisoftのチームも非常に協力的でした。
チームは素早い一方、調査結果を検証しつつ進めました。
興味深い結果もありました。ベンチマークでは測定できなくても、すべてのプレーヤーが改善を実感したものもありました。また、我々のプラットフォームは常に改善を繰り返すことができました。ローンチ後にもA/Bテストを実施できました。そして、映像再現性も改善を繰り返し、ユーザは何のアップデートも不要で、次の日ログインすると改善していたのです。
プロジェクトは非常に良い結果をもって終わりましたが、何よりも、Project Streamは、さらにスケールし、Stadiaと呼ばれるプラットフォームにつなげることができました。
Project Streamを通じて我々は学び、Streamerを改善し、低ビットレートかつ高品質、ネットワークの高速適応性、4K, HDR、サラウンドサウンドなどを実現できたのです。
Playability ToolKit
（力尽きました。1画面でレイテンシとかいろいろシミュレーションできらしいっす。）
おまけ
「まことしやかに、Googleがタキオンを使ってゼロレイテンシを実現したという噂があるが、それはまだ実現していない。」とか、「RFC1149での実装も試そうと思ったが、ファシリティ部門からまだ返事がないんだ」などと、ジョークを何度か飛ばしていましたが、会場の反応が寒く、かわいそうでした。