低遅延DASH.mpd.m4s

ライブ配信の遅延を縮める話になると、セグメントを短くすればよいという答えがまず出ます。ところが1秒のセグメントにすると、ファイルの数もリクエストの数も増え、圧縮の効率も落ちます。低遅延DASHは、セグメントの長さを変えずに、中身を作りながら流し始めるという別の道を取ります。

低遅延DASHが使われる場面

スポーツ中継や開票速報のように、テレビ放送やSNSと並べて見られるライブ配信で使われます。DASH-IFの資料でも、放送の遅延はおおむね3秒から10秒の範囲に収まるとされており、そこに近づけることが目標に置かれています。同時配信でテレビより大きく遅れると、結果を先に知ってしまうという問題が起きます。

Androidやブラウザ、テレビ向けのアプリが中心の配信で選ばれます。iPhoneのSafariが標準で再生できるのはLL-HLSなので、両方を出す構成では、CMAFのセグメントを共通にして、マニフェストだけを2種類用意するのが一般的です。

設備の側では、CDNが分割転送をそのまま素通ししてくれるかどうかが要になります。取り込みからパッケージャー、CDNのエッジまでの経路が分割転送に対応していないと、エッジでセグメントが揃うまで待たされ、低遅延になりません。

低遅延DASHの仕組み

エンコーダーはCMAFのフラグメントをさらに小さなチャンクに分けて出します。パッケージャーは、できたチャンクをその都度オリジンへ上げ、サーバーはHTTPの分割転送でクライアントへ流します。プレーヤーは、セグメントがまだエンコーダーの中で作られている最中でも、届いた部分から再生を始められます。

遅延をどこに保つかはMPDで示します。ServiceDescription要素の中のLatency要素に@targetを置き、配信側が望む再生遅延をミリ秒で書きます。@minと@maxを添えて、下回ってほしくない値と超えてほしくない値も示せます。

目標に対して実際の遅延が動いたとき、プレーヤーは再生速度を微調整して戻します。どこまで速く、どこまで遅くしてよいかはPlaybackRate要素の@minと@maxで示されます。現在の遅延を測る基準には、制作側の時刻を示すProducerReferenceTime要素と、ミリ秒精度のUTCTiming要素を使います。

低遅延DASHとLL-HLSの違い

どちらもセグメントの中身はCMAFにできるため、同じファイルを両方のマニフェストから参照する構成が取れます。違いは、細切れになった映像をどう届けるかという点に集中しています。

よくある質問

低遅延DASHで遅延はどこまで縮みますか

配信の設計とCDNの経路で変わりますが、放送と同程度、数秒の範囲に収めることが目標に置かれています。セグメントを短くする従来のやり方と違い、セグメント長を保ったまま縮められる点が違いです。

低遅延DASHに対応していないプレーヤーでは再生できませんか

再生できます。分割転送を使わないプレーヤーは、セグメントが完成してから受け取る通常の動きになり、遅延が大きくなるだけです。仕様も、従来のクライアントがそのまま使えることを前提に作られています。

低遅延DASHとLL-HLSは両方用意する必要がありますか

視聴者の端末によります。iPhoneのSafariで標準再生させるならLL-HLSが要ります。両方を出す場合でも、CMAFに揃えればセグメントは1組で済みます。配信方式の選び方はHLSとMPEG-DASHの違いでも整理しています。