LL-HLS.m3u8.m4s

スポーツ中継やライブコマースで、コメントへの反応が映像に届くまで30秒かかる、SNSの速報より画面が遅れる、という不満を解消する手段として出てくるのがLL-HLSです。HLSの仕組みを残したまま、映像を1秒未満の細かい単位で届けることで、遅延を数秒程度まで縮めます。既存のCDNで大人数に配れる点が、WebRTCとの大きな違いです。

LL-HLSが使われる場面

遅延が視聴体験に直接響くライブ配信で使われます。スポーツの中継では、テレビ放送やSNSの速報より大きく遅れると、得点の結果を先に知ってしまいます。ライブコマースやオンラインのイベントでは、出演者が視聴者のコメントに答える場面があり、数十秒の遅れがあると会話が成り立ちません。

構成としては、エンコーダーからパッケージャーへSRTやRTMPで映像を送り、パッケージャーがLL-HLSの再生リストと部分セグメントを作り、CDNを通して配ります。AWS Elemental MediaPackage、Wowza Streaming Engine、Nimble Streamerなど、多くの配信サーバーやクラウドサービスがLL-HLSの出力に対応しています。

LL-HLSの仕組み

通常のHLSは、数秒のセグメントが完成してから再生リストに載せます。LL-HLSでは、1つのセグメントをさらに細かい部分セグメント（パート）に分け、パートができるたびに再生リストへ #EXT-X-PART として書き足します。プレーヤーはセグメントの完成を待たずに、最新のパートから再生できます。

再生リストの取りに行き方も変わります。プレーヤーは _HLS_msn と _HLS_part の値を付けて「この番号のパートが載った再生リストをください」と要求し、サーバーはそのパートができるまで返事を保留します。これをブロッキングの読み込みと呼び、定期的に読み直す無駄と待ち時間を減らします。#EXT-X-PRELOAD-HINT は次のパートのURLを先に知らせるタグで、プレーヤーはできあがる前から要求を出しておけます。長いライブでは、_HLS_skip を付けて前回からの差分だけを受け取り、再生リストの転送量を抑えます。

LL-HLSの設定で間違えやすい点

パートの長さは短いほど遅延が減りますが、リクエストの回数が増えます。仕様では、ライブの端からさかのぼる距離（PART-HOLD-BACK）をパートの長さの少なくとも2倍、推奨は3倍以上としています。パートを極端に短くしても、この余裕とネットワークの揺らぎがあるので、遅延は思ったほど縮まりません。

CDNの対応も確認が要ります。ブロッキングの読み込みでは、サーバーが応答を保留し、URLの問い合わせ文字列ごとに別の応答を返します。CDNがこの問い合わせ文字列を無視してキャッシュしたり、保留中の要求をタイムアウトさせたりすると、再生が止まったり通常のHLSと同じ遅延に戻ったりします。再生の開始や画質の切り替えは、キーフレームを含むパート（INDEPENDENT=YES が付いたもの）からしかできないので、GOPが長いとその分だけ待たされる点にも注意します。

よくある質問

LL-HLSの遅延はどれくらいですか

構成やネットワークの状態によりますが、数秒程度が目安です。通常のHLSの十数秒から数十秒と比べると大きく縮まりますが、1秒未満が必要な双方向の用途にはWebRTCが向いています。

LL-HLSは通常のHLSのプレーヤーでも再生できますか

再生できます。LL-HLSのタグを知らないプレーヤーは部分セグメントを無視し、通常のセグメント単位で再生するので、遅延は通常のHLSと同じになります。

LL-HLSとSRTの違いは何ですか

SRTはエンコーダーから配信サーバーへ映像を送るためのプロトコルで、LL-HLSはサーバーから大勢の視聴者へ届けるための方式です。同じ配信の中で、送り込みにSRT、視聴者への配信にLL-HLSと組み合わせて使います。配信プロトコルの選び方はSRT・RTMP・WebRTC・HLSの違いで比較しています。