SFUの話

1,352 views

Published on

WebRTC MeetUp Tokyo #10 で話した内容です。

Published in: Software
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,352
On SlideShare
0
From Embeds
0
Number of Embeds
523
Actions
Shares
0
Downloads
10
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

SFUの話

  1. 1. SFUの話 tnoho
  2. 2. 自己紹介 tnoho • 某通信会社 新卒入社3年目 • Web会議システムMCUサーバ担当 • Androidエンジニア → Javaエンジニア • 趣味は電子工作 WebRTCは Native Client / SFU / MCU を比較的よく調べています。
  3. 3. まあ、間も開いたのでおさらいから…
  4. 4. WebRTCは… • リアルタイム通信をブラウザで行う技術です • Javascriptで利用でき、映像はVideoタグから出せます ブラウザで映像・音声通話ができるなんてすばらしい! この技術を使った新しいサービスを作ろう!
  5. 5. あれ?5人くらいしかつなげなくない? 問題の原因はP2Pであるゆえの通信量と負荷 • WebRTCは標準で1人当たり2Mbps • 4人でつなげば6Mbps必要 • 動画エンコードに暗号化と処理が高負荷 WebRTCを利用したサービスを作ると必ずぶつかる問題 A C D B モバイル端末には特に辛い。この問題を解決するのが SFU / MCU
  6. 6. MCU (Multi-point Control Unit) サーバーサイドで映像加工を行う仕組み • メリット • PeerConnectionは一本でよい • サーバーでデコードするため異種接続可 • 自動応答や動画再生も可能 • デメリット • 画質の劣化が発生する • サーバー負荷が非常に高い • Videoが結合されて送られるため、 参加者ごとに別枠表示や拡大は難しい MCU A B C D A B C D デコード エンコード 結合 A B C D A B C D 1フレームに 4人を収める A B C D A B C D A B C D A B C D
  7. 7. SFU (Selective Forwarding Unit) サーバーが配信を代行する仕組み • メリット • クライアントはSFUにだけ、映像を送ればよい • サーバー負荷がMCUに比べ非常に低い • 個別の映像で来るため、Videoタグを分けて 自由なレイアウトが可能 • デメリット • デコードの数は変わらず端末負荷がある • 仕組みとして複雑なため、実装も複雑になる MCU A C D B SFU A B C D 分配のみ A A A
  8. 8. WebRTC接続方式の種類(まとめ) SFU (Selective Forwarding Unit) クライアントはサーバと通信する。上りは一本で良くなる すべての通信がサーバを経由するためサーバの通信速度がネックになる 実装に高い理解を要する非常に難しいアーキテクチャ 表示人数分デコードするためモバイルでは多人数では負荷が高い P2P (WebRTC自体はこれが前提) もっとも高解像度で自由度も高い 全員と送受信するため通信量とクライアント負荷が大きい モバイルの場合は少人数でも非常に負荷が高くなる MCU (Multi-point Control Unit) 映像/音声をサーバで合成する。録画再生も行うこともできる 参加人数が増えても負荷や通信量が増えない(モバイルでも多人数可) レイアウトの自由度が失われる サーバに負荷が集中するため、そこがネックになる(高スペック要)
  9. 9. SFU (Selective Forwarding Unit) P2P (WebRTC自体はこれが前提) MCU (Multi-point Control Unit) クライアント サーバ クライアント サーバ クライアント サーバ わかりやすく書くと
  10. 10. 商用 SFU 商用 MCU OSS MCUOSS SFU WebRTC SFU / MCUの代表例 このあたりはSIP向けなら イロイロあります
  11. 11. 前置きが長くなりましたが、今回はSFUの話…
  12. 12. SFU (Selective Forwarding Unit) サーバーが配信を代行する仕組み SFU A B C D PeerConnectionは SFUとクライアント間で張る A A A SFUは 配信しかしない クライアントは 配信者の映像を 受け取る 配信のみの場合はHLS (Http Live Streaming) が存在する
  13. 13. SFUの抱える問題点 WebRTCは通信状況や端末負荷に応じて細かく制御されている 複数人と繋いだ場合は、一番状況の悪い人に合わせざるを得ない ⇒結果、映像音声品質が悪化する (どこで切り捨てるかはSFU次第) SFU A B C D A A A A B A 解像度下げてよ パケットかけたよ キーフレーム送って 転送だけだと全員からくるRTCP Feedback
  14. 14. 映像品質低下を避ける技術 SFU A B C D 送信者 有線 WiFi携帯 SFU A B C D 送信者 有線 WiFi携帯 赤い電車が走ってきた。 駅のホームに。 汽笛をならして。 赤い電車が走ってきた。 駅のホームに。 汽笛をならして。 赤い電車が走ってきた。 駅のホームに。 赤い電車が走ってきた。 simulcast SVC 送信者が複数サイズの映像をSFUに送る →送信者の負荷が高い 送信者がSVCコーデック映像をSFUに送る →特許技術 SFUが受信相手の状況を把握して、送るパケットを変えるしかない
  15. 15. MultiStream(MultiTrack) 複数の映像音声を一本のPeerConnectionに入れる機能 SFU A B C D SFU A B C D 張ってあるConnectionにメディアを追加するため、接続処理が不要 MultiStreamなし MultiStreamあり
  16. 16. しかし、MultiStreamの実装が難しい 今のところブラウザで挙動差異があるし、SDPも読めないといけないし… Javascriptだけならともかく、ネイティブでまでこれをやるのは若干憂鬱… ユーザー PeerConnection <video> ユーザー <video> <video> ユーザー ユーザー <video><video> MultiStreamなし MultiStreamあり ユーザー単位の括りではなくなる SDP PeerConnection
  17. 17. jvb-module 部屋管理 Jitsi Video Bridgeをnodeで動かす Jitsi Video Bridge (SFU) node jvb module Socket.IO Browser RESTful (Colibri) WebSocket 作った SDP解析 Colibri生成 SDP生成 Colibri解析 SSRC-ユーザー紐づけ JVBはXMPPサーバとセットで動かす前提 ⇒ Socket.IOにしたかった インターフェイス 新規参加者 ダミーSDP Offer 参加者ブラウザ側処理 SDP Answer解析 ssrc-user紐づけ Colibri生成 Jvb側処理 Colibri解析 SDP生成 全員にSDP Offer 全員ブラウザ側処理 新規ストリーム追加完了 Jitsi video bridgeのソースコード読んで作りました… JVBの自主メンテはおすすめしません…
  18. 18. まとめ SFU が入ってくるとWebRTCはもっと難しい SDKで簡単に利用したい!
  19. 19. 端末 SFU/MCUの力を借りれば 非力なハードウェアでも配信することが可能になる 端末 動画エンコーダー(圧縮) 暗号化 暗号化 暗号化 B C D 通信帯域 SFU/MCU 動画エンコーダー(圧縮) ハードウェアが代行 暗号化 暗号化 暗号化 B C D 復号 暗号化
  20. 20. ハードウェアエンコーダー対応 WebRTC Native Library (ChromeのWebRTC部分) では かなり対応が進んでいる(意図しなくても使えている) • iOS ⇒ H.264 HW Encoderに対応 • Android ⇒ 端末依存(H.264, VP8に対応) • RaspberryPi ⇒ H.264 HW Encoder 搭載!が対応はしていない ⇒というわけで、自分で書いて対応させてみた!(っていう話をどこかでしたい これらを使えば、電池の寿命を延ばすことができる
  21. 21. EOF

×