WebRTCプラットフォーム tokboxのopentokを調べてみた(番外編) SFUについて考えた

番外編として

今回はopentokでも使われているSFUについて、勝手に考えてみたことを書いてみます。SFU/MCUについてはこちらの資料（スマートフォンでのWebRTC活用）の27ページをご覧ください。

• SFU... Selective Forwarding Unit：映像/音声ストリームを特定の相手に配信。ストリームの分配も担当
• MCU... Multipoint Control Unit：多拠点制御装置。拠点別の再エンコードや、複数映像の合成も実施

SFUの強み

SFUとMCUはどちらもPeer-to-Peerの通信経路爆発問題に対するソリューションです。特にSFUの場合は、「サーバー側で再エンコードしない」ということが最大の利点になります。

• サーバー側で再エンコードしない
• → サーバー側のCPU負荷が低い
• → 1つのサーバーで（MCUに比べて）多くのクライアントをつなげることができる

SFUの弱み

SFUの弱みも、同じく「サーバー側で再エンコードしない」という点にあると考えています。どういうことか、もう少し補足してみます。

Peer-to-Peerの場合

WebRTCの場合、通信相手ごとに動画/音声をエンコード（圧縮）しています。通信経路の状態をモニターしていて、相手に合わせた品質を調整しています。

例えば通信相手が2人いる場合に、片方が高速の回線でつながっていれば低圧縮/高ビットレートで送り、もう片方がモバイルなどの低速回線であれば高圧縮/低ビットレートで送ります。
つまり「相手ごとに、バイトレベルでは送っている情報が違う」ということです。重要なので繰り返しますが、「相手ごとに送信している内容が異なり」ます。
その結果、次のような特性があります。

• 相手ごとにエンコードするので、CPU負荷が高くなる
• 相手ごとに合わせるので、低速回線の相手が混じっていても、それなりにコミュニケーションできる

WebRTCでは個別にエンコードするというアグレッシブな戦略が採用されていて、それを知った時にはびっくりしました。良く「WebRTCは重い。ファンが唸る」と言われるのはそのせいですね。

MCUの場合

送信元は相手がMCUサーバーだけなので、エンコードは1回だけになります。代わりにMCUサーバー側で、映像を合成したあと、複数の受信側に合わせて個別にエンコードします。
したがって、個々の回線状況に応じてそれなりの品質になります。反面サーバーのCPU負荷が高くなってしまいます。

※実際には「映像の合成」でタイミング合わせの難しい問題があるのですが、今回は触れません。

SFUの場合

SFUはMCUと逆になります。

• すべての受信側に同じバイトデータを送る
• 低速回線の相手が混じっていると、その相手とはまともにコミュニケーションできない（映像停止、音声断絶）

モバイルが1人混じっていたりすると、通信が断続的になり、その人はまともに会話できないかもしれません。これが、私の考えるSFUの最大の弱点です。

opentokの知恵

SFUを使っているopentokはこの点にどう対処しているのでしょうか。その回答がこちらにありました。

• Audio Fallback ... 回線状況が悪い場合、音声のみの通信に切り替わる

説明にはさらに複数の工夫が書かれています。

• video-recovery により、回線が回復したら映像ありに復帰する
• Adaptable Frame-Rate Control で、切り替わる閾値をカスタマイズできる

この分野で実際にサービスを続けてきたからこそのノウハウですね。

その先か？SVCの可能性

SFUやMCUと違った考え方として、SVC(Scalable Video Coding)というものが提唱されています。

• Implementing SVC in WebRTC

きちんと理解できていませんが、必ずしもMCUなどと対立するものではないと受け取っています。P2Pや一般的なMCUのようにエンコードを相手別に行うのではなく、何段階のグループに分けて行う、というものだと思われます。通信相手が多い場合（例えば10人以上など）に有効でしょう。

これは全く新しい概念ということはなく、大規模な映像のオンデマンド配信や、ライブ配信の仕組みの中には以前から取り入れられている方式です。これを、WebRTCの世界にも持ち込もう、ということなのでしょうね。

ビット密度を変えてもコミュニケーションが成立する映像/音声の世界では、まだまだ色々な工夫の余地がありそうです。