【REALITY×Mirrativ Tech Talk】音声・モーション配信とアバター・ギフトほかについて【勉強会レポ】
一番好きなうまい棒はめんたい味のようてんです。30本入りの袋を常備しておくと、何かあった時に「俺にはうまい棒（めんたい味）がある」とメンタルコントロールに効くのでオススメです。
はじめに
先日、Mirrativさんとの合同勉強会があり、そこで「REALITYの音声・モーション配信とアバター・ギフトほかについて」というタイトルで発表をしてきました。
本エントリでは、その勉強会でお話しした資料を公開するとともに、勉強会に参加してなかった方にもわかるように、再構成・補足を追記したレポートをお届けします。
発表内容
前回と前々回は主にアバターまわりの話をしたのですが、今回はMirrativさんとの合同勉強会ということもあって、配信サイドの話にしました。こんなタイトルでありながらギフトの話はあまり詰め込めませんでしたし、マルチゲームについてはばっさり省いていたりするので、このへんはまた別の機会にチームメンバにでもお願いしたいなと思っています。
入社当時のWFLEから社名は変更になりましたが、もう4年生になりました。
勉強会はZoomのウェビナー形式だったため、登壇者カメラ映像が映るのですが、毎度のことながら着ていく服に悩むわけです。この日はトロピカルサマーの水着とどちらにしようか悩んだのですが人魚姫のドレスにしました。
開始前の打ち合わせで「映り込んでも問題ない背景を設定して、顔が明るくなるようにライティングにご注意ください…」みたいな話をされていたのですが「リアルアバター組は大変だな」と思ってました。
いつもの雰囲気紹介セットです。紹介動画はREALITY公式トップに掲載されているものです。
REALITYでも以前はアプリで画面キャプチャしたものをエンコードし、動画としてRTMPでサーバに送信、その後HLSとして変換されて配信され、視聴側のアプリでデコード・再生される映像配信方式が使われていました。現在は、2方式の併用期間を経て、こちらのCR、クライアントレンダリング方式に一本化されています。
キャッチコピーの3つの要素については、以下の通りの対応となっています。
ラグなし：セグメントとキャッシングの都合上、数秒から十数秒の遅延があるHLS（CMAFなどの低遅延対応により1秒前後までは頑張れますが）に対して、WebSocketベースで百から数百ミリ秒程度に遅延を抑えられること。
ギガ安：解像度720x1280の30fps、ビットレート1Mbpsの動画のストリーミングと比較して、音声とモーションなどの必要な要素のみを送信しているため、数分の1から10分の1程度に通信量が抑えられること。
高画質：H.264での1Mbpsは高いスマホの解像度に対して十分に高いビットレートとは言えない中、どうしても動きの激しさなどによりブロックノイズが出てしまう映像配信と比較して、ローカルレンダリングのためそのような圧縮映像ノイズが発生しないこと。
「モーション情報」と「音声」と2つの項目を挙げましたが、REALITYアプリではこの図のように、Unityレイヤがアバターのモーションやギフトの座標などのデータを送信し、ネイティブレイヤがマイクから入力された音声などのデータを送信するそれぞれで分担する方式で動作しています。
「Unityレイヤ」と「ネイティブレイヤ」、とざっくり登場させてしまいましたが、REALITYアプリではUnity as a Library（のようなもの）により、ネイティブアプリをベースに、Unity部はライブラリとして埋め込まれています。
Unityのビューにネイティブのビューをオーバレイさせることができます。このスライド中の画像はライブの視聴画面ですが、アバター・壁紙・ギフトは背面のUnityレイヤで描かれており、画面上下部のオーバレイ表示されたUI部はネイティブレイヤで描かれるといった構造になっています。
全ての画面がこの方式で実現されているわけではなく、（歴史的経緯もあり）UnityでUIを描いている画面も多数あります。
WebSocketコネクション数としてはもちろん2倍消費してしまうのですが、開発が独立して進められるメリットを期待して2レイヤ作戦を採用しました。
スライド中の画像の通り、Unityエディタのみでギフト・コラボ・マルチプレイゲームを含む配信まわりが概ねすべて動作します。
また、音声を取り扱うネイティブレイヤが独立していることで、「ミニプレーヤーによる音声のみの再生モード」や「バックグラウンド音声配信」などのラジオのような視聴モードを開発する際に、プロトコル・サーバサイドとして特別な対応が不要というメリットがありました。UnityPlayerをpause状態にすることでアバターやギフトの処理は自動的に停止し、ギガ消費的にも音声のみに自動的に限定されることになります。
それぞれのレイヤでどのような情報を投げているかをざっとご紹介します。
Unityのレイヤではコラボの最大人数4にあわせた最大4アバター分のTransform - 空間位置や回転などの座標情報、BlendShape - 目や口の開閉などの表情情報、「拍手」や「手を振る」などのエモートと呼ばれるアニメーション再生情報などを送信しています。ギフト情報には座標や、条件で変化していくギフトであれば何段階目の変身であるか、名前入りのギフトであればユーザ名の文字列などギフトに応じたさまざまな情報も含まれています。
Unityレイヤの情報は、画面の描画の30fpsと比較して、低めの10fps程度での送信となっており、よしなに補完して描画されています。
ネイティブレイヤは主には音声を扱っており、Opus 64kbps stereoのパケットが格納されています。
いくつか本方式でアプリの実機能がどうなっているかの構造をご紹介します。まずは突然ごつめの図を出してしまいましたが、コラボです。
この図で肝となるのは真ん中下段に居る「配信者ホスト」なのですが、REALITYのコラボは配信者であるホストががんばって、最大3人までのゲスト間との相互のモーション・音声のやりとりを中継し、視聴者側に届けるというトポロジーで実現されています。
アプリの動作として、ホストの処理・ネットワークが安定していることが前提になってしまうものの、右半分の視聴者側に届けるルートが通常の非コラボ状態と同一のトポロジーになるメリットを優先し、割り切ってこの方式にしました。
他にも現在進行形の開発コードネームで「Tantan」とか「Mead」などがいます。お披露目される日をお楽しみに：）
アバターの描画と音声の同期の話です。図中の文章で記載した通りですが（文字が小さめで読みづらいのはすいません）、ネイティブの音声プレイヤーのバッファ量をUnityレイヤに通知し、同量分描画をウェイトすることで実現しています。
定番の手法ではあるのですが、音声はネイティブレイヤでのOpusのデコード再生、映像はUnityレイヤでのモーション情報の3Dモデルへの適用という変わった組み合わせでも、元気に動いてくれています。
ここからは、Habaneroプロトコルの話として、実際にアプリ上の機能としてどのように使われているかの実例のよもやま話が続きます。
ギフトはいっぱい表示されると、その分だけ同期が間引かれます。
（いかんせん多機能なこともあって）さまざまな機能が同時に動作した際のfpsの低下がサービスとしてクリティカルではないと考えているのですが、Mirrativさんも同様の考えをしているところがある話が面白かったですね。
タイトルにこっそり入れてあった「ほか」という文字列の部分の話です。
Protobufは既存のパラメータに対するタグ番号（フィールド番号）を変更しなければ、追加に関しては下位互換性が保たれます。
図中にいくらかREALITYアプリでの実例を載せましたが、新しい機能もProtobufのフィールドが増える形のデータ設計で済ませることで、サーバサイドの開発は不要で、クライアントサイドの開発のみで実現が可能となります。
またアプリのバージョンアップについても、「その機能に対応したバージョンでなければ正常に表示されない」にとどめることができれば、リリース時に強制バージョンアップを実施せずに済むことができ、ユーザへの影響を小さく抑えることができます。
おわりに
このような形で、「HabaneroというWebSocketベースの独自プロトコルで組んだので夢がいっぱいです」、という話をしてまいりました。（ご紹介した通り、プロトコルというほど手続きがあるわけではなくていち独自フォーマットではあるのですが。）
映像配信方式ではないが故にブラウザ再生ができなかったり、アーカイブ周りをやろうと思ってもどうしても考えることが多いというデメリットの面があるのですが、どちらかというと僕らの出自もあって、「映像配信サービス」側よりは「3Dのネトゲ」側に進む方が向いているだろうと、こちらを選択しました。
今後もっとアバターで生きられるメタバースの実現を進めていくんだ、という目指す先を考えても、必然だったのかなと思っていますし、ガンガン面白いビューと体験をこれからも引き続きみなさまにお届けできたらいいなと思っています。
ここまで長文を読んでくださってありがとうございました。もし続きを一緒につくってくれる、REALITYに興味のあるエンジニアの方がいらっしゃいましたが、以下のリンクから気軽にお話を聞きにきてくれると嬉しいです。
→ REALITYエンジニアカジュアル面談お申し込みフォームはこちら