WebRTC SFU Sora で大規模会議

V
shiguredo
Published in
9 min readApr 27, 2018

WebRTC SFU は、クライアントに代わって SFU が映像や音声を配信してくれるという仕組みだ。これにより、クライアント自身の負荷を減らすことができる。

例えば、もし会議に 30 人が参加している場合、クライアントは自分以外の 29 人それぞれに音声と映像を送信する必要はなく、SFU だけに送信すればよい。ただし、SFU から 29 人それぞれの音声と映像を受信する必要がある。

技術者の方は 30 人の会議なんてないと思うかもしれないが、実はとても需要がある。例えば全国に拠点があるような企業の支店長会議ともなれば、30 人よりも多い人数が参加することもある。

話がそれた、話を戻す。29 人分の音声と映像。もう気が狂ってしまう。300kbps でも 8.7Mbps だ。それを 29 箇所に配信する必要がある。252Mbps … もうわけがわからない。

WebRTC SFU の場合

SFU では大規模な会議はできない。大規模な会議をするなら 残念ながら MCU にその座を譲るしかないというのが今までの SFU の立ち位置だった。MCU ならサーバ側の CPU をフル回転させて、複数の音声と映像を 1 つに合成してから配信ができる。

MCU の場合

MCU が持つ機能を WebRTC SFU Sora へ

このままでは MCU が強いとされる市場には勝てない。さらに大規模ユーザ市場を WebRTC SFU では取れない。

そこで WebRTC SFU Sora に MCU にはよく搭載される「直近で、一定の音量を発した N 名の音声と映像のみを合成して配信する」という機能を WebRTC SFU 向けにアレンジして「直近で、一定の音量を発した N 名の音声と映像のみを配信する」という機能を搭載することにした。

この機能は MCU でというよりは会議システムで実はよく求められる機能というのが正しい。ただ今までは会議システムといえば MCU ということで、ここでは MCU としている。

クライアントは 4 だが下りは 2

上の図は WebRTC SFU Sora に上記の「直近で話をしたクライアント 2 名の音声と映像を配信する仕組み」を搭載したときのイメージ図だ。

クライアントが 4 にもかかわらず下りの数が 2 しかない。つまり常に 2 つのクライアントの音声と映像しか配信されない。

上のクライアント B を細かく見ていくと、現時点では A と B が直近で音声を発したため、A と B が配信されている。ちなみに B は自分自身なので音声は配信されず、映像のみが配信される。そもそも自分なので音声はいらない。

ここで C が声を発したとする。そうすると A または B のうち、あまり声を発していないと WebRTC SFU が判断した方のクライアントが切り替わる。たとえばここでは B があまり声を発していないと判断されたとしよう。

B から C へ切り替わるまでは 100 ミリ秒もかからないので違和感を感じることはない。

たとえばこのクライアントの数が 4 から30 になったとしても、この機能を利用すれば実際に配信されるのは 2 だけにできる。

この機能は SFU が苦手とする、多人数での会議を実現するのを可能にし、さらに MCU の強みを SFU 側で克服できるようになってしまう。

例えばスマートフォンでの多人数会議だとしても、多くの映像や音声を受信する必要がなくなるからだ。

暗号化や復号の負荷が下がる

実は WebRTC SFU にとって MCU の強みに打ち勝つだけでなく、サーバ側の負荷も減らすことができるようになる。

WebRTC SFU にとって最大の CPU 負荷の敵は暗号化と復号だ。WebRTC の音声と映像は常に暗号化されて送られてくるため、WebRTC SFU 側で一度復号して、再度クライアントそれぞれに暗号化して配信する必要がある。

読みづらいが復号と暗号化とかいてある

実は WebRTC SFU の天敵がこの暗号化/復号にかかる CPU リソースだ。音声や映像をリアルタイムに扱うため、暗号化/復号処理の頻度はとても高い。

さらに例えばクライアントが 30 となったら、もう本当に CPU リソースをガンガン食いつぶしてしまう。

ただ、この直近で会話した人だけの音声や映像を配信することで、まずは暗号化の数が上の例であれば 2 以上は増えない。これは大きい。

さらにそもそも話していない人の音声や映像は復号する必要がない。30 クライアントいても復号する必要があるのは 2 クライアント分だけになる。

これは MCU だけでなく、ほかの WebRTC SFU とくらべても圧倒的なアドバンテージとなる。

クライアントもサーバも負荷がものすごく下がる

この機能を利用して WebRTC SFU Sora で 30 クライアントで会議を行ってみたところ、 1 コア 1 ギガのサーバで 80% 程度の CPU 使用率で済んだ。

この機能を利用しない場合は動作すらしないし、そもそもクライアントが耐えられない。

そしてサーバも耐えられないだろう。なんていったって、30 クライアントであれば WebRTC SFU は 870 本の配信と 30 本の受信をする必要がある。

  • 直近で会話した人だけの音声や映像の場合は 60 + 30
  • そうでない場合 870 + 30

もう目が当てられない。天と地の差である。

スポットライト機能

この、直近で会話していた N 人だけを配信する機能。正直呼びにくいし、イメージしにくい。

直近で会話している人達だけに、スポットライトがあたっているようなイメージだとわかりやすいのではないか?と考え、「スポットライト機能」と名付けることにした。

スポットライトが2つあって、そのスポットライトが直近で会話したクライアント A とクライアント B に当てられている

A と B

クライアント C が会話に参加したことにより、あまり話をしていなかったクライアント B からクライアント C へスポットライトが切り替わった。

A は継続、B から C へ

事前にスポットライトの個数は決めておける。最大で 5 だ。50 クライアントとかの場合は 5 あっても多くはないだろう。

WebRTC SFU Sora スポットライト機能デモ動画

4 クライアントの参考動画を YouTube に乗せておいたのでぜひ見てほしい。切り替わり速度も実感していただけるだろう。

固定と強制

この機能を見たら次に思うのは「声は発していなくても、ある指定したクライアントを強制的に配信したい」や「声は発していなくても、ある指定したクライアントを常に固定して配信したい」といった、偉い人が欲しそうな機能。これ、すでに用意してある。

例えば会議中に寝ていそうな人を強制的に配信することもできてしまう。

これらの機能は Sora では HTTP API として用意してあるので、ある意味やりたい放題だ。

API の説明は WebRTC SFU Sora の公式サイトの説明がとてもわかりやすいので、そのまま引用することにした。

  • 強制スポットライト
    発言する・しないにかかわらず、指定した参加者の映像と音声を強制的に配信するための API です。例えば会議の冒頭で参加者を紹介するような場合に、その対象者が発言していなくても一時的に映像を配信するといった使い方が可能です。
    指定した参加者の映像を配信している間に別の参加者が発言した場合は、その発言者の映像と音声が配信されます。
  • 常時固定スポットライト
    発言する・しないにかかわらず、指定した参加者の映像と音声を常に配信するための API です。
    例えば会議の司会進行役は発言していなくても常に映像を配信する、といった使い方が可能です。
  • スポットライト解除
    常時固定で配信するように指定していた参加者のスポットライトを解除するための API です。

さぁ、あなたがほしいものはここにある。録画を除いて。スポットライト機能利用時の録画はタスクには積んである。もう少し待ってほしい。夏までには提供する予定だ。

今後

このスポットライト機能は MCU を利用した会議システムを脅かす機能だと自負している。そのため WebRTC SFU Sora が入り込めていなかった大規模な会議を必要としているところに切り込んでいきたい。

さらに、この機能は実装が難しい、正直かなり難しい。そのため他の WebRTC サーバはそう簡単には実装してこないはずだ。実際 SkyWay や Tokbox や Twilio は実装できていない。もちろん追従があるとはおもっている。

ただその前にこの機能をもって WebRTC を利用した会議 を取りに行きたい。追いかけられる前に突き放していく。

そしてこの機能は WebRTC SFU の可能性を何倍にも高められる機能だと自負している。

時雨堂は WebRTC SFU Sora で日本の WebRTC 市場を取りに行く。

謝辞

本日 2018 年 4 月 27 日にこのスポットライト機能を搭載した WebRTC SFU Sora 18.04 をリリースした。

この機能は MCU の酸いも甘いもを知り尽くした方から、WebRTC SFU Sora への機能要望があってこそ実現できた機能である。心より感謝したい。

また、この機能は半年以上設計と実装を繰り返しても最低限動く程度だったのを文句も言わず、ここまで使える機能にしてくれたり、この機能を開発のためのテストツールを作ってくれたり、わかりにくいスポットライト機能をわかりやすく説明する資料を書いてくれたり、わかりやすいデモ機能を作ってくれたりと、この機能を実装すると決めてから長い間支えてくれ、リリースまで持ってきてくれた時雨堂の社員全員に感謝したい。

この機能を搭載している WebRTC SFU Sora は、採用事例の公開許可をいただければ年間 60 万円で利用可能だ。興味がある方は sora at shiguredo.jp までお問い合わせいただければ。

--

--