誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。
利用している技術
STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。
Project Stream は 1080p (フルHD)で 60fps という試みでした。STADIA では抜本的な改良を行い 4K で 60fps まで引き上げたとインタビューに書いてあります。
Project Stream
操作は WebRTC DataChannel (SCTP over DTLS) を利用して、映像はWebRTC MediaChannel (DTLS-SRTP) で H.264 を 1080p で 60fps で送信しているというのが SDP ログからわかっています。
シアトルに住んでいる友人に Project Stream に申し込んでもらって chrome://webrtc-internals でログを取得してもらった情報なので間違いありません。
ゲームサーバと P2P で繋がっているのだと想定しています。ここは明言されていませんでしたので想像です。
詳細は記事にしてあるので、興味ある方は是非。
WebRTC で 4K@60 を送信するのは可能なのか
可能ですが、ハードウェアによる支援が必須です。自社では Android を搭載したカメラ端末を利用し 4K@30 を WebRTC で配信することを実現しています。これは端末に搭載されているハードウェアエンコーダーを利用することで実現しています。
つまり STADIA ではサーバ側に 4K@60 でエンコード可能なエンコーダが用意されているので間違いないでしょう。AMD GPU のエンコーダに明るくないため想像ですが カスタム AMD GPU に載っているのではないかと思います。
実時間でエンコードできてしまえば、あとは送信だけですが P2P ということもありひたすら UDP パケットを投げつけるだけです。
この辺りは QUIC のノウハウがとても生きてると思います。QUIC も結局は UDP を投げつける仕組みです。YouTube は今はもう QUIC ですので、このノウハウがそのまま使えるのだと思っています。
インタビューでも YouTube が行ければ、使えるという話が書いてあります。
WebRTC で 4K@60 を受信するのは可能なのか
クライアントに依存します。ネットワークはおそらく最低でも 30Mbps 程度は必要になると思います。またそれを受取って表示するためにはハードウェアによるデコード支援が必要になるでしょう。
Project Stream では H.264 を利用していました。STADIA では VP8/VP9 なのか AV1 なのかわかりません。エンコーダーを考えると H.264 の可能性が高いです、ただこれは想像です。
WebRTC は映像に特化した再送や輻輳の制御技術がふんだんに詰め込まれています。そのノウハウが送信側同様、再送要求を出したりする受信側にも注ぎ込まれています。
8K@120 について
実は STADIA で一番驚いたのはこちらです。4K60 だけでもすごいのに 8K@120 となると、必要となるビットレートは 100Mbps 以上だと思います。そもそもクライアントが耐えられないような気がしないでもないです。
なによりも 8K@120 を実時間で変換できるエンコーダーが必要になります。これが自分の知識が及ばない範囲なので、とてもドキドキしています。
まとめ
Project Stream は “ストリーミング技術の限界を押し広げる” というのがテーマでした。まさにそれを実現したというのが STADIA の発表なのだと思います。
クラウドゲーミングはいろいろな課題があると言われて来ていると書かれることが多いようですが、Chrome や WebRTC や QUIC 、そして YouTube と必要な技術とノウハウを全て持っている Google がやるとどうなるのか、とても楽しみです。
日本にくるのはいつになるかだけが心配です。
