1WebRTCの映像フロー制御の働きを実際に確かめてみたWebRTCSkyWay今年の私のテーマは、「SkyWayを利用する開発者の皆さんからの質問にお答えする」というテーマで、カレンダー記事を何本か書きたいと思います。発表資料を公開記事用に加筆修正し、2019/12/1に全体公開したものです。映像の品質が悪い長時間接続していると映像が乱れる音が途切れるなどなど...。WebRTCは実環境に導入したら不確定要素だらけP2P通信の場合、その通信が上手くいくかどうかは、利用者の端末(PCやスマホ)、ネットワーク環境に依存する部分が多いです。サービス開発者がアプリケーションとして正しく動くものを作っていても、意図した動作をしない...という事はよくあります。不確定要素でよく問題となるのが、ビデオチャットを提供した場合の映像品質です。品質が低下すると視認性が下がってしまいます(下記図参照)。映像品質は、P2P通信の場合(TURNサーバ利用を含む)、完全に利用者のネットワーク環境に依存するため、残念ながら、サービス開発者からコントロールできないことが多いです。品質は完全にネットワーク環境任せなのか?というとそういうわけでも有りません。WebRTCでは、パブリックなインターネット回線を利用して映像トラフィックをやり取りすることを考慮し、回線帯域をフェアに分け合えるように独自のフロー制御機構が搭載されています。このフロー制御の仕組みを知っておくと、映像品質が劣化した際に、どういう事が起きているのか?ということをある程度想像できるようになります。絶対とは言えませんが、品質問題にぶち当たった時に解決の糸口になる可能性もあります。この記事では、Chromeの実装を利用して、フロー制御がどのように動作しているのかを解説します。Controlに基づき、フロー制御が行われ、インターネットを含むネットワークの状況に応じた、品質調整が行われています。アルゴリズムの詳細はこの記事では割愛しますが、興味があるか方はRFCを御覧下さい。送信側ではロスベースの推定をします。比較し、小さい値を基に、メディアの品質を落とし送信帯域を下げていくとなります。実際のところどうやって動くの?ということで、理論はこのくらいにして、実際にどう動くのかを調査してみました。元ネタが2019/9の記事なので公開時の最新バージョンではありません。deviceこれらのツールを使って、macOS上で帯域制限、パケットロスが発生する環境を作り、Android端末から受信した映像の品質を確認します。依存するためこの結果のとおりにならない可能性もあります。一例ということで御覧下さい。何もしない場合PCで受信したビデオストリームの統計情報はこちらです。制限したタイミングでジッターの値がはねて、そのタイミングで、リモートから受信した映像の解像度、フレームレートが一時的に低下しています(だいたい青丸の所)が、その後回復しました。制限したタイミングで、リモートから受信した映像の解像度が下がり始めました。framesReceivedとframesReceived/sのグラフは取得していなかったのでありません。250kbpsに制限250kbpsに制限すると、ジッターに加えて、パケットロスやRTTにも影響が出始めました。リモートから受信した映像の解像度やフレームレートは不安定に上下を繰り替えしていますが、映像自体は殆ど動きがない状態になります。実際の帯域は5byte/s(40kbps)前後でビデオチャットを成立させるのは難し状況です。この後、100kbpsまで制限をきつくしたところで、WebRTCのコネクションが切断されてしまいました。パケットロスを発生させてみる帯域制限の時と同じ条件で、今度はパケットロスのみを発生させてみます。ロス率5%パケットロスの累積パケット数は増えますが映像品質への影響はほぼ見受けられません。ロス率10%10%でも5%と同様の結果です。20%20%に増やしたところで、リモートから受信した映像の解像度、フレームレートが下がりました。フレームレート自体はその後回復しているように見えますが、解像度はおちたままです。packetLossグラフの青丸の位置は、パケットロスの変化量が増えたあたりについていますが、制限を変更したタイミングは、解像度が変化したタイミングとなります。50%フレームレートは不安定に上下していますが、解像度に変更はありません。最後にパケットロスの制限を解除させてみます。そのタイミングでリモートから受信した映像の解像度は元の解像度に戻り、その他のグラフも安定するようになりました。省略してしまいましたが、先に述べた帯域制限についても、制限解除すると同様に安定した状態に復活することを確認済みです。分かった事ジッターの変化(正確には帯域制限からのジッターの変化)とパケットロスの変化に伴い、受信側のビデオ解像度(WidthとHeight)が変化するネットワーク環境悪化に伴い解像度は小さくなり、通信環境がよくなると元の解像度に戻ります。ネットワーク環境が実際の映像品質に影響を与えていることがわかりました。間で解像度が変動しました。元の解像度によっても変化のステップや劣化した場合の最終的な解像度は変わる可能性がありますが、どんな時も状況に応じてリニアに解像度を変化させるような実装にはなっていないようです。今回資料中で紹介したグラフは、chrome://webrtc-internalsの情報の抜粋です。新しくなりますWebRTCの統計情報APIを利用することで同様の情報が取得できるため、統計的な通話品質の分析などに使ってみるのも良いかもしれません。RTCPeerConnectionを取得するAPIがあるため、そちらを利用します。具体的には、RTCPeerConnectionに生えている、getStats()というAPIを実行してレポートを取得します。そのまま叩くのはなかなかしんどいので、rtcstats-wrapperを使ってみてください。使い方の記事WebRTCの通信状況をプログラマブルに判別するライブラリを作ってみたも公開されているため、御覧下さい。Naka@yusuke84WebRTCに関わり6年目。NTTコミュニケーションズでWebRTCプラットフォームSkyWayのソリューションアーキテクト兼DevRel担当をやっています。EnablerTM」として、ICTの活用によるお客さまの経営課題の解決やスマートな社会の実現に取り組みます。upLoginユーザーは見つかりませんでした。