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