DeNAのライブストリーミングサービスでの低遅延化の取り組みについて紹介します。(プレゼンテーションに埋め込まれた動画を再生するには、pptxファイルをダウンロードする必要があります)

1. ライブストリーミング低遅延化の
取り組み @ DeNA
2018/08/31
株式会社ディー・エヌ・エー システム本部 技術開発室 樋口 証

2. DeNAのライブストリーミングサービス
 SHOWROOM
 Pococha
 Vtuber系ライブ配信サービス(開発中@DeNA)
 配信システムはほぼ共通
 RTMPで配信、RTMPかHLSで視聴
 現状、数秒程度の遅延がある。とくにHLSが遅い
 低遅延化に取り組んでいる
 最短 0.2 秒程度にまで低遅延化 (RTMP、HLS共)
 実際のサービスでは0.3秒 〜 1.0秒程度にできる見込み
 まもなくリリース

3. 実際にテスト配信しているところ
 約250msの遅延
 インターネット越し
 RTMPで配信、HLSで視聴
 iPhoneからiPhoneに配信
 30fps

4. 動画ライブストリーミングの遅延内訳
遅延の内訳
① カメラとディスプレイのラグ: 90ms
② 動画エンコード・デコード: 30ms
③ 上り・下りネットワーク通信による遅延: 30ms〜
• RTTと転送レートの両方が影響する
• 環境によって大きく変動する
④ クライアントとサーバ側のソフトウェア処理: 30ms〜
⑤ 動画プレイヤーのバッファリング: 数10ms〜
• スムースに再生するために必要なバッファリング
(現在開発中のシステム、Iphone8で測定)
①
②
③
④
⑤
遅延の内訳

5. 遅延測定方法
 カメラとディスプレイのラグの測りかた
 カメラをプレビューし、撮影対象とプレビューの両
方を別のビデオカメラで撮影（右写真）
 プレビューが何フレーム遅れているか数える
 ライブストリーミング遅延の測りかた
 合わせ鏡方式: 視聴しているディスプレイを配信し
ているカメラで映す（先の動画）
 一周あたり何フレーム遅れているか数える
 カメラとディスプレイのラグを含めた遅延を測るこ
とができる

6. 低遅延化のための基本方針(RTMP, HLS共通)
 視聴クライアント以外では一切バッファリングしない
 配信クライアントがキャプチャしたフレームはなるべく早く視聴クライアントへ送る
 視聴クライアントでは音声プレイヤーが音声フレームをバッファリング
 このバッファが network を含む全ての揺らぎを吸収する
 再生中の音声にタイミングを合わせて映像フレームを表示（ lip sync ）
 「現在再生中の音声の位置」を正確に知ることのできる音声プレイヤーを作る必要がある

7. HLS視聴の低遅延化
 個々の mpeg2ts チャンクをストリーム配信する
 HTTP 1.1 の chunked encodingを使う
 プレイリストには未完成のチャンクも含める
 一本のTCP接続を繋ぎっぱなし
 HTTP 1.1 の persistent connection
これでRTMPと同程度の遅延になる
 mpeg2ts チャンクの長さが長くなっても遅延は変わらない
 処理にかかるCPUコストはRTMPより少し高い

8. HLS視聴の低遅延化 ボツ案
 案1. チャンクを細かくする。1フレーム1チャンクのように。
 案2. チャンク1個だけ。実質的には mpeg2ts をストリーム配信しているだけになる

9. バッファリング処理(RTMP, HLS共通)
lip sync 処理
 音声プレイヤーにサンプルをバッファリング
 現在再生中の音声フレームとタイムスタンプが一致する映像フレームをディスプレイ
に表示する
音声を基準にして映像をそれに合わせる理由
 音声再生以外のタイマーに音声を同期させるのは困難
 音声の再生には必ずバッファリングが必要
 映像よりも音声のほうが途切れると目立つ

10. 途切れにくさと低遅延のトレードオフ
 視聴クライアントでは音声プレイヤーが音声フレームをバッファリング
 このバッファが network を含む全ての揺らぎを吸収する
 音声にタイミングを合わせて映像フレームを表示 （ lip sync ）
 バッファリング量が一定値になるよう常時調整
 このバッファが network を含む全ての揺らぎを吸収する
トレードオフ
 音声のバッファリング量を大きくすると、途切れにくくなるが遅延が大きくなる
 バッファリング量を小さくすると遅延が小さくなるが、network の揺らぎなどによっ
て音声が途切れやすくなる

11. バッファはどれくらい必要か
 配信側から視聴側までの経路の品質に依存
 品質のよい network であれば 100ms でもほとんど途切れることはない
 品質悪いとき 1秒くらいがよいか
 配信内容に応じてバッファ量を変える
 音声フレームに音楽が含まれていればバッファを大きくして途切れにくくする

12. さらなる低遅延化は可能か
 可能だが効果が薄いので実装していない
 サーバ側で個々のフレームをストリーミング処理すると少し早くできる
 特にキーフレームの network 遅延を避けられる効果がある
 HLSのプレイリスト取得
 TCPを2本使えばプレイリスト取得の往復の遅延を避けられる
 network が遠くないと効果が薄い
 サーバ側、クライアント側のソフトウェア処理についてもまだ改善の余地はある
 あと 30ms 程度の改善可能か

13. 人材募集中
 Pococha
 温かくて居心地がいいソーシャルライブ空間をつくるエンジニア募集！
 https://www.wantedly.com/projects/237486
 新規Vtuber ライブ配信
 手軽にみんながVtuberになれる新ライブ配信サービス開発エンジニア募集！
 https://www.wantedly.com/projects/237624
 リーンな新規サービス立ち上げ
 DeNA社内ベンチャー組織で新しいネットサービスを生み出すエンジニア募集！
 https://www.wantedly.com/projects/160778