ライブストリーミング低遅延化の取り組み @ DeNA

ライブストリーミング低遅延化の取り組み @ DeNA

Transcript

1. ライブストリーミング低遅延化の 取り組み @ DeNA 2018/08/31 株式会社ディー・エヌ・エー システム本部 技術開発室 樋⼝ 証
2. DeNAのライブストリーミングサービス u SHOWROOM u Pococha u Vtuber系ライブ配信サービス(開発中@DeNA) u 配信システムはほぼ共通 u RTMPで配信、RTMPかHLSで視聴 u 現状、数秒程度の遅延がある。とくにHLSが遅い u 低遅延化に取り組んでいる u 最短 0.2 秒程度にまで低遅延化 (RTMP、HLS共) u 実際のサービスでは0.3秒 〜 1.0秒程度にできる⾒込み u まもなくリリース
3. 実際にテスト配信しているところ u 約250msの遅延 u インターネット越し u RTMPで配信、HLSで視聴 u iPhoneからiPhoneに配信 u 30fps
4. 動画ライブストリーミングの遅延内訳 遅延の内訳 ① カメラとディスプレイのラグ: 90ms ② 動画エンコード・デコード: 30ms ③ 上り・下りネットワーク通信による遅延: 30ms〜 • RTTと転送レートの両⽅が影響する • 環境によって⼤きく変動する ④ クライアントとサーバ側のソフトウェア処理: 30ms〜 ⑤ 動画プレイヤーのバッファリング: 数10ms〜 • スムースに再⽣するために必要なバッファリング (現在開発中のシステム、Iphone8で測定) ① ② ③ ④ ⑤ 遅延の内訳
5. 遅延測定⽅法 u カメラとディスプレイのラグの測りかた u カメラをプレビューし、撮影対象とプレビューの両 ⽅を別のビデオカメラで撮影（右写真） u プレビューが何フレーム遅れているか数える u ライブストリーミング遅延の測りかた u 合わせ鏡⽅式: 視聴しているディスプレイを配信し ているカメラで映す（先の動画） u ⼀周あたり何フレーム遅れているか数える u カメラとディスプレイのラグを含めた遅延を測るこ とができる
6. 低遅延化のための基本⽅針(RTMP, HLS共通) u 視聴クライアント以外では⼀切バッファリングしない u 配信クライアントがキャプチャしたフレームはなるべく早く視聴クライアントへ送る u 視聴クライアントでは⾳声プレイヤーが⾳声フレームをバッファリング u このバッファが network を含む全ての揺らぎを吸収する u 再⽣中の⾳声にタイミングを合わせて映像フレームを表⽰（ lip sync ） u 「現在再⽣中の⾳声の位置」を正確に知ることのできる⾳声プレイヤーを作る必要がある
7. HLS視聴の低遅延化 u 個々の mpeg2ts チャンクをストリーム配信する u HTTP 1.1 の chunked encodingを使う u プレイリストには未完成のチャンクも含める u ⼀本のTCP接続を繋ぎっぱなし u HTTP 1.1 の persistent connection これでRTMPと同程度の遅延になる u mpeg2ts チャンクの⻑さが⻑くなっても遅延は変わらない u 処理にかかるCPUコストはRTMPより少し⾼い
8. HLS視聴の低遅延化 ボツ案 u 案1. チャンクを細かくする。1フレーム1チャンクのように。 u 案2. チャンク1個だけ。実質的には mpeg2ts をストリーム配信しているだけになる
9. バッファリング処理(RTMP, HLS共通) lip sync 処理 u ⾳声プレイヤーにサンプルをバッファリング u 現在再⽣中の⾳声フレームとタイムスタンプが⼀致する映像フレームをディスプレイ に表⽰する ⾳声を基準にして映像をそれに合わせる理由 u ⾳声再⽣以外のタイマーに⾳声を同期させるのは困難 u ⾳声の再⽣には必ずバッファリングが必要 u 映像よりも⾳声のほうが途切れると⽬⽴つ
10. 途切れにくさと低遅延のトレードオフ u 視聴クライアントでは⾳声プレイヤーが⾳声フレームをバッファリング u このバッファが network を含む全ての揺らぎを吸収する u ⾳声にタイミングを合わせて映像フレームを表⽰ （ lip sync ） u バッファリング量が⼀定値になるよう常時調整 u このバッファが network を含む全ての揺らぎを吸収する トレードオフ u ⾳声のバッファリング量を⼤きくすると、途切れにくくなるが遅延が⼤きくなる u バッファリング量を⼩さくすると遅延が⼩さくなるが、network の揺らぎなどによっ て⾳声が途切れやすくなる
11. バッファはどれくらい必要か u 配信側から視聴側までの経路の品質に依存 u 品質のよい network であれば 100ms でもほとんど途切れることはない u 品質悪いとき 1秒くらいがよいか u 配信内容に応じてバッファ量を変える u ⾳声フレームに⾳楽が含まれていればバッファを⼤きくして途切れにくくする
12. さらなる低遅延化は可能か u 可能だが効果が薄いので実装していない u サーバ側で個々のフレームをストリーミング処理すると少し早くできる u 特にキーフレームの network 遅延を避けられる効果がある u HLSのプレイリスト取得 u TCPを2本使えばプレイリスト取得の往復の遅延を避けられる u network が遠くないと効果が薄い u サーバ側、クライアント側のソフトウェア処理についてもまだ改善の余地はある u あと 30ms 程度の改善可能か
13. ⼈材募集中 u Pococha u 温かくて居⼼地がいいソーシャルライブ空間をつくるエンジニア募集！ u https://www.wantedly.com/projects/237486 u 新規Vtuber ライブ配信 u ⼿軽にみんながVtuberになれる新ライブ配信サービス開発エンジニア募集！ u https://www.wantedly.com/projects/237624 u リーンな新規サービス⽴ち上げ u DeNA社内ベンチャー組織で新しいネットサービスを⽣み出すエンジニア募集！ u https://www.wantedly.com/projects/160778