こんにちは、ストリーミングチームの松本です。 今回はミラティブの配信の画質を向上させるために行った対応の概要をご紹介したいと思います。
目次
スマホゲームの配信の画質を改善したい
配信の画質を改善したい場合には、画質が悪いとはどういうことかについて考える必要があります。
多くの場合画質が悪い一番の大きな理由は「配信される映像の解像度が低い」ということです。
画面をキャプチャした映像データをそのまま送信することができれば最も綺麗な画質で視聴者にとどけることができますが、 大容量の映像データを送ることになります。それをリアルタイムで視聴するには非常に高速な通信速度が必要となるため、ライブ配信の映像はエンコードして送信する必要があります。
そこで映像のエンコード時の解像度をあげれば良いのではないかとなりますが、解像度を上げると
- 映像のエンコードの負荷が大きくなってしまう
- 映像のエンコード時のビットレートを高くする必要がある
という問題がでてきます。
映像のエンコードの負荷が大きくなってしまう
ミラティブを含め現在の主流なライブ配信においては映像のエンコード方式としてH.264/MPEG-4 AVC が使われています。
解像度が大きくなればなるほどエンコードにかかるCPUやGPUの計算量が増えるため、解像度を上げて綺麗な映像で配信することと快適にゲームをするということで天秤にかけることになります。
映像のエンコード時のビットレートを高くする必要がある
H.264/MPEG-4 AVC においては、一般的には同じ解像度・フレームレートであればビットレートが高いほど映像はきれいになります。
逆に解像度を上げることで必要なデータ量が多くなるため、 解像度に合わせてエンコード時に適切な映像のビットレートを設定しないと画質がむしろ悪くなってしまうこともあります。
映像のエンコード時のビットレートを高くすると、それに応じたネットワークのアップロード速度が必要になってきます。
しかし、高性能な端末を使い光回線や高速なルーターを準備し高い解像度・高い映像ビットレートを設定して配信すれば問題なく高画質で視聴することができるかといえば、そうとも限りません。
視聴側においても十分なネットワークの帯域が必要であるため、映像データの再生が追いつかない場合があるからです。
その結果バッファリングのため映像が止まってしまったり、遅延する状況になります。
ミラティブでは現在の所配信サーバー側での複数のストリームにエンコードしなおすマルチビットレートの対応は行っていません 1。配信側でエンコードされた映像がそのまま視聴側に届くため、解像度やエンコードのビットレートは配信側となるアプリで調整する必要がありました。
ミラティブでの配信画質改善への取り組み
ミラティブでは、映像をエンコードするための画質設定として、低画質・標準画質・高画質設定が存在しています。
インストール直後の画質設定は標準画質となっています。標準画質については端末の種類によって微妙に解像度などは違いますが、 モバイル回線を利用する場合に大体の人が問題なく配信できるであろう設定となっていました。
映像ビットレートの向上
調査の結果、ミラティブの画質設定では解像度の設定値に対してブロックノイズが発生するケースがあり、設定された解像度に対して映像のビットレートが足りていないようでした。そのため、映像ビットレートを引き上げる対応を行いました。
アップロード速度の調査
映像ビットレートを大幅に上げればネットワークのスループットの低いユーザーの配信が不安定になってしまうため、事前にアップロード速度状況の調査を行っています。
低遅延プロトコルで利用する1サンプルサイズ程度の小さな数十個程のパケットを送受信して、クライアントが実際に送受信しているネットワークのアップロード速度を計測しました。
結果としてWi-Fiの場合高画質設定・標準画質の場合の映像ビットレートを1.5倍程度に引き上げることとなりました。
ただしモバイル回線においては上記の結果から標準画質においては据え置き、高画質においては元の設定より下げる結果になっています。
アップロード速度のでない配信ユーザーへの救済措置
エンコード時の映像ビットレートがネットワークのスループットよりも大きい場合、 映像をキャプチャした時間に対してアップロード時間が多くかかってしまい映像の送信が遅延することを意味します。
映像の送信が遅延するということは、配信者がゲームをしたり雑談をしている時間と 視聴者がライブを視聴している時間にずれが生じるため、ミラティブが重きを置いている 配信者と視聴者がリアルタイムなコミュニケーションの面においては大きなマイナス になってしまいます。
回線が不安定なユーザーや、標準画質では十分配信できるもののスループットが低く高画質で配信するとアップロードが間に合わないようなユーザーも少なからず存在することから、 送信の状況に応じて配信ユーザーの映像ビットレートを動的に調整する対応を行っています。
映像ビットレートの動的な調整
以前からアプリの配信処理に映像ビットレート調整のロジック自体はありました。それは映像や音声データの送信が間に合わない場合半分にし、間に合うようになったら映像ビットレートの初期値にリセットするものでした。
このロジック自体はシンプルであり映像や音声データの送信が大きく遅延することはなかったものの、遅延を検知するたびに毎回エンコードのビットレートを半減させてしまうことから、 一時的に回線が不安定になったケースにおいても大きくビットレートの値が変動し継続的に映像が乱れてしまう問題がありました。
そのためアプリの配信処理内における映像ビットレートの調整についてはTCPの輻輳制御なども参考に修正しました。
図は映像のエンコードのビットレートを変更する様子を表しています。2 映像や音声データの送信の遅延が起きた際より少し手間のビットレートを保持しておき一定期間その状態をキープしています。
映像ビットレートの動的な調整のロジックの修正によって、回線が不安定だったりスループットに見合わない配信設定をおこなっている場合でも、できるだけ高い映像ビットレートを維持した状態で配信できるようになっています。
配信サーバーの台数・コスト見積もり・増設
アプリ側の映像の映像ビットレートを上げれば、配信のアップロードのトラフィックが増加します。
つまり、 個々の配信の映像ビットレートが1.5倍になれば、配信サーバー側の入り口のインバウンドのトラフィックもまた1.5倍となります。
ミラティブにおいて現状は配信のオリジンサーバーのNICの帯域として2Gbpsの上限があるため、上記の増加分のトラフィックを捌くためにオリジンサーバーの台数をまず見積もる必要があります。
オリジンサーバーには、初期状態で2つのエッジサーバーが接続されています。 トランスコードサーバーからRTMP・低遅延プロトコルの2つのストリームのインバウンドのトラフィックがあり、 エッジサーバー毎にRTMP・低遅延プロトコル・HLSの3つのストリームのアウトバウンドのトラフィックがあり3 ます。 したがって、1つの配信が1Mbpsの映像・音声データを送信する場合には合わせて最大で8倍の8Mbpsのトラフィックが流れる見積もりとなります。
オリジンサーバーのトラフィックは、以下のように見積もることができます。
オリジンサーバーのトラフィック = 1ストリームあたりの配信トラフィック * (2 + 3 * エッジサーバー数)
視聴者が一時的に増加してエッジサーバーがオートスケールすることも考慮に入れつつ、オリジンサーバーに流れるトラフィックがNICの帯域上限のの6〜7割程度までを目安としておく必要がありました。 そうして得られたオリジンサーバーの台数を元に、エッジサーバー・トランスコードサーバー・スタンバイ用のサーバーのそれぞれの台数を見積もります。
このようにして、追加で必要となるサーバーの台数を見積もり、サーバー費用・ネットワーク費用が大きくなりすぎそうであれば構成の見直しも視野に入れながら増設していきます。
配信サーバー増設に関連する対応
サービスイン・サービスアウトの自動化
ミラティブでは各配信サーバーはshardというグループの単位にわかれていて、配信サーバーのプロセスが停止してしまった場合等にはスタンバイのサーバーに対してフェールオーバーされます。 しかし、障害後に対象の配信サーバーでライブが開始されないようにするためには手動でSQLを叩いてサービスアウトを行う運用が必要となっていました。 低遅延プロトコル対応サーバーの増設や、画質改善にともない配信shard数が大幅に増えることでこれらの手動の運用が増えてしまうことのないようにサービスイン・サービスアウトの自動化の開発についても行いました。
また、エンドツーエンドで配信が遅延していないかを監視し、サーバーの性能が劣化して大幅に遅延している場合は、自動でエッジサーバーを入れ替える仕組みの開発も関連して行いました。
段階的なリリース
ストリーミングに関する施策全般に言えることですが、全サーバー・全ユーザーに一度にリリースするのではなく、 APIサーバーからフィーチャーフラグを返してアプリから参照することで、機能の有効化・無効化の設定を行っています
また、元々あるABテストの仕組みを利用して対象となるユーザーを徐々に増やしていく方法もとっています。
まずは特定のshardで一定の割合のユーザーに段階的にリリースして、配信サーバーの負荷状況や、急激なトラフィックの増加、配信・視聴の遅延が起きていないか、 ユーザーの個別に配信についても問題が起きていないか、配信・視聴体験に関するネガティブな会話がされていないか、配信の異常終了率が増えていないかどうかといった事も含めて確認していきます。
特定のshardで問題が起きなかった場合、他の配信shardについてもフィーチャーフラグを有効化し、同様の確認をしつつ、段階的にユーザーに展開しました。
まとめ
まとめると以下のような手順で対応をおこなってきました。
- 画質が悪い原因・改善方法の調査・検討
- アップロード速度のでないユーザーを考慮した映像ビットレート向上の対応を行ったアプリバージョンのリリース
- 必要な配信サーバーの見積もり・増設
- 配信shardのサービスイン・サービスアウトの自動化
- フィーチャーフラグ・ABテストの仕組み等を利用した段階的なリリース
他にも画質改善の文脈において、Androidの個別のデバイスの画面アスペクト比に合わせた解像度の決定や、 MediaProjection利用時の画質の改善など細かな対応がありますが、それらはまた機会があれば書きたいと思います。
スマホによるゲーム配信おいてはH.264のエンコードでは圧縮率に限界があり、高画質な映像を送受信するためにはより速いアップロード速度が必要となります。 5Gの普及やより高速な回線が増えていく中で解決されていく面ではありますが、モバイル端末でも快適に利用できるような別のエンコード方式の導入も検討しています。
We are hiring!
ミラティブではライブストリーミングの技術が好きなエンジニアを募集しています！
少しでも興味を持っていただいた方はお話を聞いていただくだけでも結構ですので、気軽にご連絡ください。
www.mirrativ.co.jp
エンジニア向け会社紹介資料
-
過去には行っていたこともありました↩
-
ネットワーク帯域の制限や遅延を再現するには、iOSやMacのNetwork Link Conditionerを利用しています。↩
-
Mirrativにおける低遅延配信への取り組みについてhttps://tech.mirrativ.stream/entry/mirrativ-low-latency-streaming-preview↩
