目次
Session概要
Blocking Playlist ReloadはLow-Latency HLSに必須のコンポーネントで、ライブストリームのセグメントディスカバリータイムを改善し、HTTPキャッシュを通じた配信の際によくある無効なプレイリストの問題にも対応します。Blocking Playlist Reloadを使ってストリーミング遅延を低減し、低遅延と通常のライブHLSストリーム両方のCDNパフォーマンスが向上します
https://developer.apple.com/videos/play/wwdc2020/10231
Blocking Playlist Reloadとは何か？
サーバ上に新しいセグメントがあるとクライアントに知らせるHLSの機能 HLSの基本はクライアントがプレイリストのリロードにより新たなセグメントを発見することであり、従来はターゲット期間ごとに同じプレイリストのURLをリロードしていたが、低遅延の配信の場合うまく機能しません。なぜなら、プレイリストの更新を逃すと問題に気づく前に別のターゲット期間が必要となるからです。
ポイント
- 低遅延HLSではDelivery Directive が導入された
- GETリクエスト時にクエリを付与してサーバにある種のサービス実行を求める方法
- Blocking Playlist Reloadではこの Delivery Directive を使用する
- 新たなセグメントが追加されるまでサーバにプレイリストのリロードを待たせる
- 更新されるとサーバのブロックが解除されクライアントに送られる
主な手順と補足
- Blocking Playlist Reloadはオプショナルである
- サーバがサポートを指示するには
CAN-BLOCK-RELOAD属性をサーバコントロールタグに追加する - 初めてプレイリストをロードする際はクエリを付与しない
- この時点では最新のものを全て取得するため
- プレイリストを取得するとリロードリクエストが出される
- この時次のセグメントを取得するための
_HLS_msnという Delivery Directiveを使用する - 低遅延であれば、次の部分セグメントの指定が可能
- この時次のセグメントを取得するための
- サーバはプレイリストが更新されるまでリクエストしない
LL-HLS Blocking Playlist Reloadの流れ
通常HLSによるBlocking Playlist Reloadのサンプル
EXT-X-SERVER-CONTROLによってBlocking Playlist ReloadがサポートされているがわかるEXT-X-MEDIA_SEQUENCEが19で、segmentがEまであることからメディアシーケンス23があることがわかる- つまり次に新たなセグメントでプレイリストが更新されたら、そのセグメントはメディアシーケンス24である
- GETリクエスト時は
GET playlist.m3u8?_HLS_msn=24のようにクエリ設定する- するとプレイリストが更新されるまでサーバはブロックされる
低遅延HLSによるBlocking Playlist Reloadのサンプル
上記プレイリストにおいて次のセグメントを取得する際のリクエストは
GET: playlist.m3u8?_HLS_msn=7&_HLS_part=2 となり、サーバは更新があるまで待機しレスポンスをクライアントに返す際は部分セグメントを追加した状態で返す
常に次のパートを要求したらセグメントの最後はどうなるか？-> 次のメディアシーケンスのpart 0までサーバ側でリクエストをブロックする
Blocking Playlist Reloadの例外と補足
_HLS_msnと_HLS_partはライブプレイリストにのみ適用され、EXT-X-ENDLISTタグがあれば無視される- リクエストしたプレイリストが既に存在すればサーバは最新のプレイリストを返す
- プレイリストがリクエストの内容より新しくても部分セグメントが先行している場合も同様
- 要求したセグメントがプレイリストから完全にロールアウトされている場合も同様
- プレイリストの更新に3つ以上のターゲット期間がかかるとエラーを返す
- 個々のプレイリストのアップデートごとに固有のURLがあるため、各リクエストをキャッシュできるためキャッシュ効率がよく、さらに下記のメリットがある
- 新しいリクエストはキャッシュを無効にする
- キャッシュ内の各レスポンスの有効期限が長くなる
- 重複するリクエストを1つに統合するようCDNを設定する必要がある
- オリジン起動中はその負荷を可能な限り軽減したいからです