WebRTC Meetup Tokyo #9 https://atnd.org/events/67945 で発表させていただいたときの資料です。

1. Jitsi Video
Bridge
で遊んでみた
tonofo→tnoho(アカウント整理ｗ)

2. 仕切りなおして、話をします
あ、多人数配信や多人数会議を前提とした話をします。

3. P2Pにおける限界
5人以上は…
X人数分
X人数分
回線負荷
処理負荷

4. 限界を突破するSFU/MCU
P2Pをやめます
ここに処理を寄せる

5. MCU
全部サーバになげます
x 1 x
n x
nx 1
会議室にパソコン1台割り当てる覚悟が要りますが、何でもできます。
オーバーレイも録画も再生もトランスコード前提でなんでもこい。CPUで頭打ちです。

6. SFU
配信は代行します
x n -­‐ x x
n x
n
上り x
1
配信を代行して回線負荷をサーバに集約します。帯域幅で頭打ちです。
クライアントは配信と上り回線のリソースが削減され余裕ができます。
下り x
n

7. TURNとは違うの？
TURNは転送しかしません
x n x
n x
n x
nx
n
クライアントの負荷はP2Pと同じです。

8. Jitsi Video
Bridgeって？
最も高機能なOSSのSFUです
Google
Hangoutに最も近いSFUで最も近代的で実用的な動作をします

9. 公式のサンプルはJitsi Meet!
なんですが、XMPPでJitsiという本来のプラットフォームと連携してるのでわかんない。。。

10. こうやって使うんだと思う
XMPP SFU(JVB)

11. じゃあ、WebSocketでフロントエンドつくろう
URLは公開に当たり削りマシたん。。。
言うより触ってみた方がいいよね！

12. 切断処理とかイロイロまだ書いてないけどね！

13. 多くのSFU？(LicodeとかJanusとか)
通信先は同じですが、クライアントの数だけPeerConnectionを張ります

14. Jitsi Video
Bridge(とHangout)の場合
一本のPeerConnectionに複数のStreemを詰め込みます
つまりCandidateでの経路情報交換は最初の一回だけ！

15. N-­‐1機能(試してないよ！)
多人数でSFUには接続していますが、発言者だけ送ります
つまりクライアントはしゃべっている人だけ受け取って、デコードする→大会議可！

16. Simcast機能(試してないよ！)
クライアントは複数のサイズの映像を送ります
クライアントは自分にあったサイズの映像を受け取ります

17. GitHubに公開するつもりでいます。
Java(Spring-­‐boot)で書いてたんです。
シグナリングで辛くなりました。
で、Socket.IOで使うべくNodeで書き直してます。