WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Discover HLS Blocking Preload Hints

Discover HLS Blocking Preload Hints

HLSLow-Latency HLSStreaming
元の動画を見る

ハイライト

低遅延 HLS ではプレイリストのリリースが必要#EXT-X-PRELOAD-HINTこれにより、クライアントが次の部分セグメントを事前にリクエストし、サーバーがセグメントが利用可能になるとすぐにそれを返すことができるため、メディアが検出された後の追加の往復遅延が削減されます。

主要内容

ライブ ブロードキャストの低レイテンシーのボトルネックは、小さな隙間に隠れていることがよくあります。プレイリストが更新された後、クライアントは新しいシャードの URI だけを知っており、メディア リクエストを開始します。クロスリージョン CDN シナリオでは、エッジ ノードからオリジンまでの往復に 100 ミリ秒以上かかる場合があります。目標遅延がわずか数秒であるライブ ブロードキャストの場合、この差は繰り返し蓄積されます。

プレイリストのリロードをブロックすることで、プレイリストの検出の問題が解決されました。クライアントは事前に次のプレイリスト バージョンをリクエストでき、サーバーはプレイリストが更新されるのを待ってから戻ります。プリロード ヒントのブロックは、同じ考え方をメディア シャーディング自体に適用します。プレイリストは最初に次の部分セグメントのヒントを書き込み、クライアントはすぐにこの URL をリクエストし、セグメントのエンコードとパッケージ化が完了した後にサーバーがデータを返します。

その結果、メディアはリクエストを開始する前に「新しいシャードが見つかる」まで待機する必要がなくなりました。通常、クライアントはブロッキング プレイリスト リロード リクエストとプリロード ヒント リクエストを同時にハングさせます。新しい部分セグメントが完了すると、サーバーはプレイリストを更新し、メディア リクエストを解放します。プレーヤーがプレイリストの更新を取得するまでに、メディア データはすでに送信されています。

このセッションでは、2 つの配信モデルについても説明します。単純なモデルでは、各部分セグメントは独立した URL を持ちます。 CMAF チャンク モデルでは、複数の部分セグメントは同じ親セグメントのバイト範囲です。クライアントはチャンク転送を使用して、1 つのリクエストから複数のチャンクを継続的に受信できます。これにより、同じメディア セットから低遅延 HLS と低遅延 DASH の両方を提供することが容易になります。

詳細

次の部分セグメントを事前にリクエストします

(00:48) プリロード ヒンティングの目的は、メディアが実際に利用可能になる前にリクエストを確立することです。プレイリストは必ず持参してください#EXT-X-PRELOAD-HINT、それURIパッケージャーが生成すると予想される次の部分セグメントを指します。

公開済みの最後の Partial Segment: part1.1.m4s
Preload Hint は、packager が次に生成すると予測する Partial Segment を指します: part1.2

キーポイント:

  • トランスクリプトには、最後に公開された部分が次であることが明示的に記載されています。part1.1.m4s。
  • トランスクリプトでは、ヒントがクライアントにロードを試行できる次の部分であることを伝えると明示的に述べられています。part1.2。
  • TYPE=PARTメディアの部分セグメントのセマンティクスに使用されるプリロード ヒントです。
  • クライアントはヒントを見た後、すぐにヒントされた URL をリクエストします。シャードがまだ生成されていない場合、サーバーは要求を続け、シャードが使用可能になった後に戻ります。

(02:30) 実際のリクエスト フローは非常に簡単です。クライアントは最初にブロッキング プレイリスト リロードを開始し、次にヒント付き部分セグメント リクエストを開始します。エンコーダーが新しい部分セグメントを完了すると、サーバーはメディア応答を解放し、プレイリストを更新します。プレーヤーは、「プレイリストを受信して​​からメディアを要求する」という待ち時間を節約できます。

コンテンツの切り替えを事前に処理するよう MAP に指示する

(02:15) プリロードヒントは、今後のMAP。これは、プレーヤーが事前に新しい初期化情報を取得し、切り替えポイントでの一時停止を減らすことができるため、広告境界などのコンテンツ切り替えにとって重要です。

コンテンツ切り替え前: playlist はまもなく現れる MAP を示せます。
コンテンツ切り替え後: playlist は引き続き次の Partial Segment を示します。

キーポイント:

  • トランスクリプト記述のプリロード ヒントは、今後の MAP タグに使用できます。 ・ MAP ヒントの目的は、コンテンツの切り替えに必要な初期化情報をクライアントが事前に準備できるようにすることです。
  • コンテンツ境界では、クライアントは引き続き後続の部分セグメントの読み込みを続けます。
  • クリエイティブが事前に記録されたコンテンツの場合、サーバーはライブ エンコードされたコンテンツのようにブロックしたり待機したりすることなく、ヒント リクエストをすぐに返すことができます。

バイト範囲を使用して部分セグメントを表現します

(03:39) 部分セグメントには必ずしも独立したファイルがあるとは限りません。より大きなリソースではバイト範囲になることもあります。プリロードヒントタグを持ち込めるBYTERANGE-STARTそしてBYTERANGE-LENGTH。長さが決まっていない場合は、開始位置だけを記入することもできます。

Preload Hint は、segment 23 内の 0 から始まる 4,044 バイトの範囲を示せます。
長さがまだ確定していない場合、hint には byte-range の開始位置だけを残します。

キーポイント:

  • トランスクリプトは、ヒントがセグメント 23 を指している可能性があることを明確に示しています0到着4,044範囲。
  • バイト範囲の開始位置は、次の部分セグメントが親セグメントから始まる場所をクライアントに伝えます。
  • バイト範囲の長さは、現在既知の範囲サイズをクライアントに伝えます。
  • パッケージャがヒントを発行するときに長さが不明な場合は、長さを省略できます。

CMAF チャンクとチャンク転送を使用した継続的配信

(04:17) CMAF チャンクは、低遅延 HLS の部分セグメントにマッピングできます。サーバーは、複数のチャンクを同じ親セグメントに徐々に追加します。クライアントは親セグメントへのオープン要求を開始し、チャンク転送エンコーディングを通じて後続の部分セグメントを継続的に受信します。

最初の更新: segment 1 の最初の Partial Segment は先頭 3,000 バイトで、hint は 3,000 から始まるよう更新されます。
2 回目の更新: segment 1 に 2 つ目の byte-range が現れ、hint は 8,000 から始まるよう更新されます。

キーポイント:

  • トランスクリプトには、最初の部分セグメントがセグメント 1 の前であることが明確に記載されています3,000バイト。
  • 次回のプレイリスト更新後、ヒントの開始位置は次のように更新されます。3,000。
  • 次回の更新後、2 番目のパートが表示され、ヒントは次のパートの開始位置を示します。8,000。
  • セッションでは、多くの CDN がライブ コンテンツのチャンク転送エンコーディングをサポートしていないことを思い出させます。このモデルを採用する前に、CDN 機能を検証する必要があります。

サーバーに計画の変更を許可する

(07:42) プリロードヒントは計画であり、約束ではありません。サーバーがヒントを解放した後も、次のコンテンツは変更できます。一般的なシナリオは、オペレーターが事前に広告からライブ ブロードキャストに戻ることを決定することです。

サーバーはすでに hint を公開しています。
運用者は広告からライブ配信へ早めに戻すことを決定します。
次回の playlist 更新には、以前 hinted URL が含まれません。
クライアントは保留中の hint リクエストをキャンセルし、playlist に実際に現れたコンテンツを使用します。

キーポイント:

  • トランスクリプト サーバーはプリロード ヒントを発行した後も計画を変更できることを説明します。
  • 一般的な理由は、運営者が早期に広告からライブ ストリーミングに戻ることを決定したことです。
  • 次回プレイリストが更新されるときに、以前にヒントされた URL がプレイリストに表示されない場合、クライアントは保留中のリクエストをキャンセルします。
  • その後、クライアントは実際にプレイリストに表示される新しい部分セグメントをロードします。

重要ポイント

  • 低遅延ライブ ブロードキャスト用のリクエスト タイミング ダッシュボード: ブロッキング プレイリストのリロード、プリロード ヒントのリクエスト、および部分セグメントのリターン時間を同じタイムライン上に描画します。実行する価値がある理由: Session は、これら 2 つのブロッキング リクエストが通常同時にハングし、ほぼ同時に返されることを強調しています。開始方法: プレイリスト リクエスト、ヒント リクエスト、HTTP ブロック解除時間、および一部の URI をプレーヤーとエッジ サービスのログに記録し、[OK] を押します。#EXT-X-PRELOAD-HINT位置合わせ。

  • HLS パッケージャーのヒントの整合性チェックを行う: ヒント付きの各 URL が後続のプレイリストでヒントとして使用されるかどうかを確認します。#EXT-X-PARTまたは#EXT-X-MAP現れる。実行する価値がある理由: サーバーは計画を変更できますが、一般的なエラーによりクライアントが無効なリソースを要求する可能性があります。開始方法: 連続したプレイリストのスナップショットを解析し、トレースする#EXT-X-PRELOAD-HINT、次の更新で URI とバイト範囲が一致することを確認します。

  • CDN 機能検出ツール: ターゲット CDN がライブ ブロードキャスト シナリオのチャンク転送エンコーディングをサポートしているかどうかを確認します。実行する価値がある理由: CMAF チャンク ソリューションは、同じメディア サービスのセットである低遅延 HLS および低遅延 DASH を再利用できますが、セッションは、多くの CDN がこのライブ配信方法をサポートしていないことを明確に思い出させます。開始方法: テスト親セグメントへの長い接続リクエストを開始し、サーバーがチャンクを徐々に追加し、クライアントがデータをバッチで受信できるかどうかを記録します。

  • 広告境界プリロード検証: 特殊なテストTYPE=MAPそしてTYPE=PART広告挿入中の動作とライブブロードキャストへの早期のカットバック。実行する価値がある理由: セッションでは、MAP ヒントがコンテンツの切り替えに役立つと述べており、また、サーバーがアドバタイズ中に計画を変更する可能性があることも示しています。開始方法: ライブ ストリーミング、広告、早期リターンの 3 種類のプレイリスト更新を含むテスト ストリームを準備し、プレーヤーが古いヒントをキャンセルして新しいシャードをロードするかどうかを確認します。

関連セッション

コメント

GitHub Issues · utterances