Jitsi video bridge で遊んでみた

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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