WebRTCによる低遅延ライブ配信

Transcript

1. WebRTCによる低遅延ライブ配信
 NTTコミュニケーションズ株式会社 
 イノベーションセンター テクノロジー部門 
 松下 正樹

2. • HTTPベースのライブ配信
 ◦ 一般的には30秒〜1分程度の遅延が生じる
 ◦ 遅延を数秒程度に小さくする技術もある
 • WebRTCによるライブ配信
 ◦ 1秒未満の遅延を狙うことができる
 • 低遅延ライブ配信のユースケース
 • WebRTCとHTTPベースのライブ配信の違い
 • 大規模な配信を実現するためのアーキテクチャ
 • WebRTCによるライブ配信のメリット・デメリット
 本セッションの概要
 2

3. HTTPベースのライブ配信技術
 3
 ファイルベースの配信技術
 映像を数秒単位の小さな
 ファイル (セグメント)に分割
 セグメントのダウンロードを
 順次繰り返す
 
 セグメントの
 秒数 x バッファする個数
 で遅延が決まる
 
 (例)
 6秒のセグメントを5個バッファ
 → 30秒程度の遅延
 プレイリスト playlist.m3u8 セグメント1 video001.ts セグメント2 video002.ts セグメント3 video003.ts (2) ダウンロード
 数秒程度
 …
 クライアント (1) セグメント
 　　一覧を取得

4. HTTPベースの低遅延ライブ配信技術
 4
 • HTTPベースで低遅延ライブ配信を目指す技術
 ◦ Low-Latency HLS
 ◦ CMAF-ULL
 • 遅延 ≒ セグメントの秒数 x バッファする個数
 ◦ バッファする個数を減らす
 ◦ セグメントを細かく (短く)する
 ◦ さらに細かい単位に分ける
 (Chunked Transfer Encoding)
 • 遅延を数秒程度まで小さくすることができる

5. WebRTCによるライブ配信
 5
 • ブラウザでテレビ電話やWeb会議ができる技術
 ◦ RTC = Real-Time Communication
 ◦ 会話が成立するよう低遅延を追求
 • Real-time Transport Protocol (RTP) ベース
 ◦ IP電話やWeb会議で使われている技術
 • 1秒未満の遅延を狙うことができる
 ◦ 数秒程度の遅延でよい場合も余裕が持てる

6. • 2013年よりWebRTCプラットフォームSkyWayを
 開発者向けにトライアル提供
 ◦ 通話やWeb会議などを簡単に実現できる
 • 2017年より商用サービス提供開始
 • 15,000のアプリ、14,000名の開発者、
 80万人のユーザーがSkyWayを利用 (2020年10月現在)
 弊社のWebRTCへの取り組み
 6

7. SkyWayの活用事例
 7

8. • SkyWayを配信用途で検討いただくケースが増加
 • SkyWayでは数十人程度への配信が限界
 ◦ あくまで通話や会議を想定
 • 配信に特化したシステムとしてSmart vLiveを開発
 ◦ 数〜数十万人規模の配信に対応
 ◦ ライブ配信用の機器・ソフトに対応
 低遅延ライブ配信に取り組む経緯
 8

9. • 1秒未満の遅延で映像を配信できるプラットフォーム
 • ブラウザで視聴可能
 ◦ アプリのインストールは不要
 ◦ Chrome, Firefox, Safari, Edgeに対応
 • アダプティブ・ビットレート (ABR)
 ◦ NWの状況に応じて最適な画質に自動切り替え
 • マルチアングル配信
 ◦ 複数の映像を同期させて配信できる
 Smart vLive
 9

10. • 配信者の環境について
 ◦ ライブ配信で標準的なRTMPに対応
 ◦ 映像: H.264 音声: AACに対応
 ◦ OBS、ATEM mini PRO、LiveShell、LiveU
 など主要な配信ソフト・機器に対応
 Smart vLive
 10

11. • 東京ドーム・巨人戦でのマルチアングル配信技術実証
 • サンボマスター 真 感謝祭 ～ホール＆レスポンス～
 • Interop 2021 ShowNetステージ　　など
 主な実績
 11

12. 低遅延ライブ配信のユースケース
 12
 • 音楽ライブ・ストリーマー・e-Sports
 ◦ テンポよく双方向のやりとりが可能
 • スポーツ観客向けマルチアングル配信
 ◦ 観客が好きなアングルを選んで鑑賞
 ◦ 目の前の試合から遅れてはいけない
 • オークション・会議・記者会見・セミナー
 ◦ 遅延があると入札や進行に支障がある
 • 同時通訳
 ◦ 専用レシーバーがなくてもスマホで聞ける
 • リアルタイム性や双方向のやりとりが
 必要なケースで活用できる

13. 低遅延ライブ配信のユースケース
 13
 • 低遅延ってそんなに必要？
 ◦ ニッチなケースでしか使われないと考えていた
 ◦ 作ってみたところ意外と需要があった
 • 企画の内容を踏まえて要件を検討すべき
 ◦ 一方的な配信であれば遅延は問題にならない
 • ライブ配信に遅延があること自体を知らない人も
 ◦ 低遅延でないと成立しない企画であることに
 気づいていないケース
 ◦ 「電話みたいにすぐ届くんじゃないんですか？」
 と言われたことも

14. システム概要
 14
 メディアサー バ APIサーバ 配信者 RTMP WebRTC 視聴者 ライブ情報 管理 クラウド基盤 WebRTC 配信サーバ WebRTC 配信サーバ 2段構成の1段目 映像をWebRTC配信サーバへ分配
15. システム概要
 15
 メディアサー バ APIサーバ 配信者 RTMP WebRTC 視聴者 ライブ情報 管理 クラウド基盤 WebRTC 配信サーバ WebRTC 配信サーバ 2段構成の2段目 WebRTCで視聴者に配信 2段構成の1段目 映像をWebRTC配信サーバへ分配
16. システム概要: スケーラビリティ
 16
 メディアサー バ APIサーバ 配信者 RTMP WebRTC 視聴者 クラウド基盤 WebRTC 配信サーバ WebRTC 配信サーバ WebRTC配信サーバを 増やして視聴者増加に対応 メディアサーバを増やして 同時並行する配信数の増加に対応 ライブ情報 管理
17. • HTTP
 ◦ 映像ファイルをHTTPで逐次ダウンロード
 ◦ CDNを利用可能
 • WebRTC
 ◦ RTPベースの技術でUDPによる通信
 ◦ 一般的なCDNは利用不可
 → スケーラビリティに課題
 ▪ Smart vLiveでは2段構成を採用
 ◦ ネットワーク要件が特殊
 → 接続性に課題
 HTTPベースのライブ配信との違い
 17

18. • UDPで広い範囲から選択したポートを使用
 • 一般家庭の環境では問題ないことが多い
 • 企業や学校などの環境で課題
 ◦ 通信できるポートを制限している場合は
 直接の通信は難しい
 • 通信を中継して接続性を高める
 ◦ TURNサーバ
 WebRTCによるライブ配信のネットワーク要件
 18

19. • WebRTCの通信を中継してくれるサーバ
 • UDP・TCP・TLSを利用可能
 • 使用するポートを固定できる
 ◦ FWなどで通信を許可しやすい
 • HTTPプロキシも場合によっては透過可能
 ◦ 負荷については検討が必要
 • 視聴者の数%〜十数%程度がTURN経由
 • それでも通信できない場合も
 → HTTPベースのライブ配信との併用も選択肢
 TURNサーバ
 19

20. Smart vLiveでのTURNサーバ
 20
 メディアサー バ APIサーバ 配信者 RTMP WebRTC 視聴者 クラウド基盤 WebRTC 配信サーバ TURN サーバ ライブ情報 管理 TURN TURNサーバを経由させることで TCP/TLS:443など通りやすい プロトコル・ポートを利用できる
21. • アップロードに用いられるコーデック
 ◦ 映像: H.264 (H.265)
 ◦ 音声: AAC
 • WebRTCで利用できる主なコーデック
 ◦ 映像: H.264・VP8・VP9
 ◦ 音声: Opus
 • WebRTCを使ったライブ配信では
 ◦ 映像: H.264
 ◦ 音声: AAC → Opusに再エンコードが必要
 WebRTCによるライブ配信で利用できるコーデック
 21

22. • HTTP: パケットロスはTCPにより回復
 • WebRTC: 通常はUDPを利用
 ◦ パケットロスへの対処
 ▪ RTPベースの再送 (RTX)
 ▪ 音声コーデックOpusの誤り訂正 (FEC)
 • 低遅延と安定性はトレードオフ
 ◦ 低遅延を求めれば安定性はある程度犠牲になる
 ◦ それに見合うメリットがあるか
 → 企画段階で十分な検討が必要
 パケットロスへの対処と安定性
 22

23. • UDPでどうやって再送を行っているのか？
 • RTP Control Protocol (RTCP)
 ◦ RTPを制御するためのプロトコル
 • Receiver Reports
 ◦ 受信者が送信者にフィードバックを送る
 • WebRTCで主に用いられるフィードバック
 ◦ NACK
 ▪ パケットロスを検知して再送を要求
 ◦ Picture Loss Indication (PLI)
 ▪ 映像のキーフレーム要求
 ▪ 配信用途では対応が難しい
 WebRTCでの受信者からのフィードバック
 23

24. • 視聴者のNW環境に応じて最適な画質を配信する
 ◦ 安定した配信には必須の技術
 • HTTPでのABR
 ◦ 複数の画質でセグメントを用意しておく
 ◦ 状況に応じて参照するセグメントを切り替える
 ◦ クライアントが主体
 • WebRTCでのABR
 ◦ 複数の画質でストリームを用意しておく
 ◦ ブラウザ (視聴者)との間で利用可能な帯域を推定
 ◦ 推定した結果に応じて流すストリームを切り替える
 ◦ 配信サーバが主体
 アダプティブビットレート (ABR)
 24

25. Smart vLiveでのアダプティブ・ビットレート
 25
 メディアサー バ APIサーバ 配信者 RTMP WebRTC 視聴者 クラウド基盤 WebRTC 配信サーバ WebRTC 配信サーバ 低画質版をクラウド上で リアルタイムに再エンコードして重畳 ライブ情報 管理 推定した帯域に合わせて 最適な画質を配信
26. • メリット
 ◦ 1秒未満の遅延を狙うことができる
 ◦ RTPベースでありながらブラウザで利用可能
 • デメリット
 ◦ UDPを利用するなどNW要件が特殊
 ▪ 企業NWなどでは視聴できないケースがある
 ◦ 環境によっては安定性の確保が難しい
 ▪ 回線やWiFiが貧弱なケース
 ▪ 低遅延と安定性はトレードオフ
 ◦ 追っかけ再生 (DVR)も難しい
 ◦ 他の技術の併用も選択肢のひとつ
 WebRTCのメリット・デメリット
 26

27. • WebRTCを用いたライブ配信
 ◦ 1秒未満の遅延を狙うことができる
 • 低遅延ライブ配信のユースケース
 ◦ 双方向のやりとりがある場合
 ◦ リアルタイム性が必要な場合
 • WebRTCによるライブ配信
 ◦ HTTPベースの技術とはかなり異なる
 ◦ 特徴をよく理解して技術選定する必要がある
 • 企画段階での十分な検討が成功につながる
 ◦ 低遅延と安定性はトレードオフ
 まとめ
 27