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

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

P2Pにおける限界

5人以上は…

X人数分

X人数分

回線負荷

処理負荷

限界を突破するSFU/MCUP2Pをやめます

ここに処理を寄せる

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で書き直してます。