WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Reduce latency with HLS Blocking Playlist Reload

Reduce latency with HLS Blocking Playlist Reload

WWDC 2020HLSLow-Latency HLS
元の動画を見る

ハイライト

Apple が HLS プレイリストのリロードを追加_HLS_msnそして_HLS_part配信ディレクティブにより、サーバーはターゲット セグメントまたは部分セグメントが表示されるまで待機してからプレイリストに戻ることができるため、ライブ ブロードキャスト プレーヤーが新しいコンテンツを発見するまでの待ち時間が短縮されます。

主要内容

ライブ ブロードキャストのプレーヤーは、プレイリストの更新を見逃すことを最も恐れています。従来の HLS のアプローチはシンプルです。クライアントは同じプレイリスト URL を定期的に再リクエストします。更新の直前にリクエストされた場合、古いプレイリストが取得されたままになり、次のプレイリストを待つことしかできません。target durationもう一度やり直してください。通常のライブ ブロードキャストの場合、これはさらに数秒待つだけです。 Low-Latency HLS (低遅延 HLS) の場合、この数秒が低遅延のメリットを直接消費してしまいます。

プレイリスト リロードをブロックすると、ポーリングが条件付き待機に変更されます。 「今そこに何があるの？」と尋ねるのではなく、クライアントはサーバーに「プレイリストに次の見たことのないものが含まれるまで返信するまで待ってください」と指示します。サーバーにターゲット コンテンツがまだない場合は、リクエストを開いたままにします。新しいセグメントまたは部分セグメントがプレイリストに書き込まれると、すぐに新しいプレイリストが返されます。

この変更により、HTTP キャッシュの古い問題も解決されます。従来のライブ プレイリストは常に同じ URL を持ち、キャッシュは頻繁に期限切れになる必要があり、プレーヤーは依然として古い応答を受け取る可能性があります。プレイリスト リロードのブロックでは、クエリ パラメーターを含む一意の URL が使用されます。_HLS_msn=24、各プレイリスト更新は個別のオブジェクトとしてキャッシュできます。新しい更新リクエストはキャッシュを通過してオリジンに到達し、生成された応答は CDN エッジでより長く保持されます。

詳細

サーバーがリロードのブロックをサポートしていることを宣言します

(01:27) プレイリストのリロードのブロックはオプションの機能です。サーバーはプレイリストに含まれている必要があります#EXT-X-SERVER-CONTROLタグ内のステートメントCAN-BLOCK-RELOAD=YESの場合、クライアントはこのリクエスト メソッドを使用します。

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES
#EXT-X-MEDIA-SEQUENCE:19
#EXTINF:6.0,
segmentA.ts
#EXTINF:6.0,
segmentB.ts
#EXTINF:6.0,
segmentC.ts
#EXTINF:6.0,
segmentD.ts
#EXTINF:6.0,
segmentE.ts

キーポイント:

  • #EXT-X-SERVER-CONTROLこれをプレイリストに配置して、サーバーが追加の再生制御機能をサポートしていることをクライアントに伝えます。 -CAN-BLOCK-RELOAD=YESリロードをブロックするためのスイッチです。これがない場合、クライアントは引き続き通常のリロードを使用する必要があります。 -#EXT-X-MEDIA-SEQUENCE:19最初のセグメントを示すメディア シーケンス番号は 19 です。
  • プレイリストの最後のものsegmentE.tsメディア シーケンス番号 23 に対応するため、次の新しいセグメントは 24 になるはずです。

＃＃＃ 使用_HLS_msn次の完全なセグメントをリクエストします

(02:44) 通常のライブ プレイリストには部分セグメントがありません。クライアントは使用するだけで済みます_HLS_msn次に表示するメディア シーケンス番号を指定します。サーバーがリクエストを受信した後、MSN 24 がプレイリストに書き込んでいない場合、HTTP リクエストはブロックされます。更新が完了すると、新しいバージョンのプレイリストが返されます。

_HLS_msn=24
#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES
#EXT-X-MEDIA-SEQUENCE:20
#EXTINF:6.0,
segmentB.ts
#EXTINF:6.0,
segmentC.ts
#EXTINF:6.0,
segmentD.ts
#EXTINF:6.0,
segmentE.ts
#EXTINF:6.0,
segmentF.ts

キーポイント:

  • _HLS_msn=24クライアントがメディア シーケンス番号 24 を含むプレイリストを待っていることを示します。 ・リクエストURLは通常のプレイリストURLとは異なります。 CDN は、このバージョンのプレイリストを独立したキャッシュ オブジェクトとして扱うことができます。
  • 結果を返す#EXT-X-MEDIA-SEQUENCE20 に進むとウィンドウが削除されますsegmentA.ts。
  • 新しく追加されたセグメント F は、クライアントが待機している次のセグメントである MSN 24 に対応します。

＃＃＃ 使用_HLS_part次の部分セグメントをリクエストします

(03:57) 低遅延 HLS は、セグメントを複数の部分セグメントに分割します。クライアント以外_HLS_msn、まだ使用する必要があります_HLS_part対象となる部分セグメントの番号を指定します。講義の例では、セグメント 7 にはすでにパート 0 とパート 1 があるため、次のリクエストのターゲットはセグメント 7 パート 2 です。

_HLS_msn=7
_HLS_part=2
現在の playlist 末尾: segment 7 part 0、segment 7 part 1
次の blocking reload の対象: segment 7 part 2

キーポイント:

  • 部分セグメントの目標継続時間は 2 秒です。これは、音声例の部分目標継続時間です。 -_HLS_msn=7親セグメントのメディア シーケンス番号をロックします。 -_HLS_part=2このセグメントの 3 番目の部分セグメントを要求します。
  • サーバーはセグメント 7 パート 2 がプレイリストに表示されるまで待機してから戻ります。プレーヤーは一定の間隔でセグメント 7 パート 2 を繰り返し検出する必要はありません。

リクエストがセグメントの終端をまたいだ場合の処理

(04:47) クライアントは、セグメント 7 パート 3 など、現在のセグメントの終わりを超える部分をリクエストする場合があります。サーバーはこのリクエストを次のセグメントのパート 0 に変換します。このように、クライアントはパーツ番号を順番に増やすだけでよく、最終的に各セグメントにいくつのパーツが含まれるかを事前に知る必要はありません。

クライアントのリクエスト: segment 7 part 3
サーバーの解釈: segment 8 part 0
リクエストされた part が parent segment の末尾を越えた場合、
サーバーはそれを次の segment の part 0 に変換します。

キーポイント:

  • _HLS_part=36秒の部と2秒の部を合わせた範囲を超えている。
  • サーバーはこれを次のセグメントのパート 0 として解釈します。
  • 次のセグメントのパート 0 がプレイリストに表示された後、リクエストを返すことができます。
  • クライアント ロジックは線形のままです。どの MSN とパートが表示されても、次の MSN とパートを要求します。

キャッシュとタイムアウトのルール

(05:22) 配信ディレクティブはライブ プレイリストにのみ適用されます。持ってくる#EXT-X-ENDLISTプレイリストはこれらのパラメータを無視します。サーバーがクライアントによって要求されたバージョンをすでに持っている場合、サーバーは現在のプレイリストを直ちに返す必要があります。要求されたセグメントがウィンドウからロールアウトした場合も、現在のプレイリストをすぐに返す必要があります。 3つ以上待つだけtarget durationの場合、サーバーはエラーを返します。

_HLS_msn=23  -> playlist update 23 の独立したキャッシュオブジェクト
_HLS_msn=24  -> playlist update 24 の独立したキャッシュオブジェクト
_HLS_msn=7 + _HLS_part=2 -> segment 7 part 2 の独立したキャッシュオブジェクト

キーポイント:

  • 配信ディレクティブの各セットは異なるプレイリスト更新に対応し、キャッシュは同じライブ プレイリスト オブジェクトで相互に上書きする必要がありません。
  • CDN が認識していないパラメーターの組み合わせを持つ新しいリクエストは、引き続きオリジンに送信されます。
  • 成功したプレイリストの応答は、トークの提案ごとに 6 回キャッシュできますtarget duration。
  • CDN は、同じエッジ リクエストを 1 つのオリジン リクエストにマージして、オリジン サイトへの負担を軽減するために重複エッジ リクエストの結合を構成する必要があります。

重要ポイント

  • ライブ ブロードキャスト プレーヤーのリロード診断パネル

    • 何をするか: 現在の MSN、パート、次回を内部プレーヤーに表示します。_HLS_msn / _HLS_partリクエストして待っていると時間がかかります。
    • 実行する価値がある理由: このセッションの中心的な問題は、プレーヤーが新しいコンテンツを発見するのにかかる時間です。待ち時間を視覚化することによってのみ、遅延がエンコード、オリジン、CDN、またはクライアント要求戦略によるものであるかどうかを判断できます。
    • 開始方法: 各プレイリストのリクエスト URL、応答時間、最後の MSN とプレイリストに返された部分を記録し、再生セッションごとにタイムラインを描画します。

  • 低レイテンシの HLS オリジン ブロック リクエストのモニタリング

    • 対処法: オリジンのブロッキング リロード同時実行数、平均ブロッキング期間を増やし、オリジンのブロッキング リロード数を 3 倍にします。target durationタイムアウト数などのインジケーター。
    • 実行する価値がある理由: サーバーは、プレイリストが更新されるまで HTTP リクエストを保持し、容量のボトルネックが短いリクエスト スループットから同時接続待機に変化します。
    • 開始方法: 処理中_HLS_msnそして_HLS_partイングレス管理、プレイリスト パスおよび CDN POP ごとのレイテンシとエラー率の集計。

  • CDN キャッシュ ヒット実験

    • 何をすべきか: 通常のライブ プレイリスト URL と配信ディレクティブを持つ URL のキャッシュ ヒット、発信元、応答の再利用を比較します。
    • 実行する価値がある理由: この講演では、プレイリストの更新ごとに固有の URL を使用することで、成功した応答をより長くキャッシュに保持できることが強調されています。
    • 開始方法:_HLS_msn、_HLS_part出力キャッシュ フラグを結合し、重複エッジ リクエストの結合を有効にして、オリジン リクエストの数が減少するかどうかを観察します。

  • ライブ ブロードキャスト ウィンドウ例外回復テスター

    • 何をすべきか: クライアントが古い MSN を要求する、高度なパートを要求する、終了したプレイリストを要求するなどの境界条件をシミュレートします。
    • 実行する価値がある理由: セッションでは次の例外ルールが提供されます。事前にテストすることで、プレイヤーが待機状態に陥るのを避けることができます。
    • 開始方法: スクリプトを使用してさまざまなクエリ パラメーターを生成し、ステージング プレイリストをリクエストし、サーバーがルールに従って現在のプレイリストをすぐに返すか、タイムアウト後にエラーを返すかを確認します。

関連セッション

コメント

GitHub Issues · utterances