ハイライト
低遅延 HLS のサーバー側広告挿入では、部分セグメントに従って広告を公開する必要があり、広告が切り替わるときに低遅延再生モデルを維持するために、広告とプログラム コンテンツの両方にブロッキング プレイリスト リロードとプリロード ヒントを提供する必要があります。
主要内容
通常のライブ ブロードキャスト HLS での広告挿入は、セグメント境界に基づいて機能します。番組ソースには広告を挿入するためのマーカーが付いています。パッケージャは、広告が開始される前に短いプログラム セグメントを追加し、境界をセグメントに合わせてから、不連続タグを使用して広告までカットします。コマーシャルが終了すると、短いコマーシャル セグメントが埋められ、その後プログラムに戻ります。
低遅延のライブ ストリーミングにより、このモデルは薄くなります。クライアントは完全なセグメントが表示されるのを待つことはなくなり、ライブ エッジに対して短い部分セグメントを読み取ります。 6 秒の親セグメントは、複数の 2 秒の部分セグメントに分割できます。クライアントは、6 秒間すべて待つことなく、2 秒以内にメディアの最初の部分を取得できます。
したがって、広告挿入では広告セグメント全体のみを公開することはできません。広告の開始後、パッケージャは部分期間ごとに広告の部分セグメントも発行します。親セグメントはまだ存在しており、不連続性、境界の位置合わせ、およびキーの回転位置は変更されません。変化はライブ エッジにあり、プレーヤーには部分的な広告がより頻繁に表示されます。
ライブ ブロードキャストでよくあるもう 1 つのトラブルは、早期復帰です。イベントの生放送中、プロデューサーはコマーシャルが終了する前にシーンをカットバックする場合があります。この時点で、サーバーは広告パーシャルを停止し、現在のポイントまでの短い親セグメントを追加し、プリロード ヒントを更新し、クライアントが次のプログラム パーシャルに移動できるようにする必要があります。
詳細
部分セグメントは広告挿入のリズムを変える
(01:51) 低遅延 HLS はライブ エッジで部分セグメントを使用します。スピーチは 6 秒の部分と 2 秒の部分を使用します。たとえば、クライアントは 2 秒後にセグメントの最初の部分を取得し、4 秒後に追加のコンテンツを取得し、6 秒後に最後の部分セグメントと親セグメントを取得できます。
このリズムは広告に直接影響します。パッケージャは、プレイリストを更新する前に、完全な広告セグメントの準備が完了するまで待つことはできません。クライアントが同じライブ エッジ ルールのセットに従って広告セグメントを再生できるように、親セグメントの生成プロセス中に部分広告を継続的に公開する必要があります。
キーポイント:
parent segment完全な通常の HLS セグメントです。 -Partial Segment同じメディアをホストしますが、プレイリストの前に表示されます。- クライアントは部分セグメントを使用してライブ エッジの近くで再生し、完全なセグメントのリリース遅延を待つことを回避します。
- 広告コンテンツも最初に部分再生時間に従って公開する必要があり、親セグメントは後で表示されます。そうしないと、アドバタイズメントに切り替えるときに、通常の HLS 遅延モデルに戻ります。
広告の境界は依然として短いセグメントと不連続部分によって調整されています
(02:54) 通常の HLS のサーバー側の広告挿入では、最初に境界が処理されます。マーカーは必ずしも通常のセグメント境界上にあるとは限りません。パッケージャは、広告開始点が正確にセグメント境界に位置するように短い番組セグメントを生成してもよい。広告を切り替えるときは、不連続タグを使用してプログラムと広告を分離します。
典型的なシーケンスは次のとおりです。番組ソースが広告に挿入できるマーカーを提供し、決定エンジンが広告を選択し、パッケージャが短い番組セグメントを使用して広告の開始点を調整し、後続の番組セグメントを広告セグメントに置き換えます。広告エンドポイントは通常のセグメント境界上にない可能性があるため、パッケージャは短い広告セグメントも生成し、その後プログラム コンテンツに戻ります。
キーポイント:
- マーカーはプログラム ソースから取得され、広告を挿入できる場所を示します。
- 短いプログラムセグメントにより、広告の開始点が明確な境界になります。
- 不連続タグは、番組コンテンツと広告コンテンツの間の切り替えをマークします。
- 広告のエンドポイントがセグメント境界上にない場合もあるため、短い広告セグメントが必要です。
広告は最初に部分セグメントとしても公開する必要があります
(04:20) 低遅延シナリオでは引き続き同じ広告境界セットが使用されますが、より細かい公開順序になります。広告が開始された後、パッケージャはまず部分的な継続時間に従って部分的な広告を公開します。親セグメントのすべての部分が利用可能になると、完全な広告の親セグメントが解放されます。
スピーチのタイムラインは次のとおりです。プログラム部分は通常どおりに進行し、短いプログラム部分と親セグメントが広告境界の前に表示されます。広告を入力した後、パッケージャは 2 秒の部分継続時間ごとに部分広告を追加します。完全な広告セグメントが組み立てられると、親セグメントが表示されます。広告が終了したら、短い広告部分を使用して境界を調整し、部分セグメントと親セグメントを再開します。
キーポイント:
- 広告境界、不連続点、キーローテーションの位置は同じタイムライン上に残ります。
- 低レイテンシーの違いは、公開の粒度で発生します。広告セグメントは最初に部分セグメントに分割され、ライブ エッジに表示されます。
- パッケージャは、プログラムと広告の両方に対して同じ低遅延タイミング モデルを維持する必要があります。
- 広告が完全なセグメントでのみ公開される場合、プレーヤーは広告セグメントにおける低遅延の利点を失います。
プレイリスト リロードのブロックには広告段落も含まれます
(05:48) このスピーチでは、オリジンが広告の Blocking Playlist Reload も実装することを明示的に要求しています。クライアントが次のプレイリスト バージョンをリクエストすると、サーバーは古いプレイリストをすぐに返さず、新しい部分またはセグメントが利用可能になるまで待機します。
この要件はプログラムのコンテンツだけに適用されるわけではありません。広告部分がプレイリストに入る前に、オリジンも同じ待機セマンティクスを維持する必要があります。このようにして、クライアントが取得したプレイリストは、広告段落で古いバージョンを繰り返し受信するのではなく、引き続きライブ エッジに近くなります。
キーポイント:
- プレイリスト リロードのブロックは、HLS Origin API の一部です。
- 番組コンテンツだけでなく、プレイリストの更新タイミングも保護します。
- 広告セグメントがすぐに古いプレイリストに戻ると、クライアントは古いプレイリストを取得することになり、低遅延の再生が遅くなります。
- 広告とプログラムは同じ待機および公開リズムを共有しているため、プレーヤーは切り替えポイントで戦略を変更する必要がありません。
プリロードのヒント 広告 MAP と広告部分をプロンプトするには
(06:08) プリロード ヒントでは、次に予期されるリソース URL をプレイリストに書き出す必要があります。広告が切り替わると、プレイリストは最初に新しいメディア初期化セクションを要求し、次に広告の最初の部分セグメントを要求することができます。
音声の例では、セグメント 7 がその時点で利用可能な最後の番組コンテンツでした。プレイリストの最後には 2 つのプリロード ヒントが表示されます。1 つは広告に必要な新しいメディア初期化セクションをロードするようクライアントに求めるもの、もう 1 つは広告の最初の部分をロードするよう求めるものです。 2 秒後、プレイリストは広告の不連続点、広告マップ タグ、最初の部分のタグを更新し、新しいプリロード ヒントが広告の 2 番目の部分を指します。
キーポイント:
TYPE=MAP広告コンテンツに使用される新しい初期化情報を要求します。 -TYPE=PART次の広告の部分セグメントをキューに入れます。- コマーシャルは事前に録画されたコンテンツであるため、広告の配信元はライブ プログラム ソースのようにエンコードが完了するまで待つ必要がありません。
- クライアントが次にリクエストされる広告リソースを常に認識できるように、プレイリストはヒントを継続的に更新する必要があります。
早期復帰時にヒントを更新し、プログラムに直接切り替えます
(07:55) 早期復帰とは、生放送のプロデューサーがコマーシャルを早めに終了し、すぐに番組に戻ることを意味します。サーバーは、後続の広告部分の公開を停止し、現在公開されている部分までの短い親セグメントを埋め、その後、不連続性を利用してプログラムに戻ることができます。
重要な処理ポイントはヒントです。サーバーは以前に次の広告部分を要求している可能性があります。プログラムに早く戻りたいことがわかったら、ヒントを次のプログラム部分に変更する必要があります。クライアントは新しいヒントを確認すると、プログラム コンテンツの読み込みパスに戻ります。
キーポイント:
- 発行された古いヒントは、次の広告部分を示している可能性があります。
- サーバーは、プログラムを早く返したいことを認識した後、ヒントを次のプログラム部分に変更します。
- クライアントが新しいヒントを確認すると、広告在庫に沿った読み込みが停止します。
- この処理により、低遅延の読み込みパスを維持しながら、突然のライブ コンテンツを即座にプログラムに返すことができます。
重要ポイント
-
何をすべきか: 広告の部分公開リンクを低遅延ライブ ブロードキャスト パッケージャーに追加します。 実行する価値がある理由: 講演では、LL-HLS の広告は最初に部分セグメントとしてライブ エッジに表示される必要があると明確に指摘されました。 開始方法: プログラム コンテンツの部分再生時間を再利用し、クリエイティブを同じリズムで部分部分に切り分け、完全な親セグメントが利用可能になったら公開します。
-
対処方法: 広告切り替えポイントを監視可能なプレイリスト チェック項目にします。 実行する価値がある理由: 広告は短いセグメント、不連続性、境界線の配置で始まり、終わります。 開始方法: 自動チェックで広告マーカー付近のプレイリストをスキャンし、短いセグメント、不連続タグ、広告マップ タグ、および部分広告が正しい順序であることを確認します。
-
内容: SSAI (サーバーサイド広告挿入) のヒント書き換え機能を実装します。 実行する価値がある理由: 早期に復帰すると、公開された広告ヒントが無効になり、サーバーはそれをプログラム パーシャルにリダイレクトする必要があります。 開始方法: デシジョン エンジンが早期リターン シグナルを送信すると、パッケージャーに短い広告親セグメントを生成させ、次のプリロード ヒントをプログラム URI に変更させます。
-
対処方法: 広告元とプログラム元のブロック セマンティクスを個別に設定します。 実行する価値がある理由: このスピーチでは、広告は事前に記録されたコンテンツであり、広告の発信元が強制的にブロックして待機する必要がないことが指摘されました。プレイリストのオリジンでは、広告とプログラムに対してブロッキング プレイリストのリロードを実行する必要があります。 開始方法: プレイリスト生成サービスを低遅延の制御ポイントとして使用し、リロードとヒントのブロックをそれに任せます。広告メディア ファイルは、通常の静的オリジンまたは CDN によって配信できます。
-
作業内容: プレーヤー テストの広告セグメントにライブエッジ レイテンシ カーブを追加します。 実行する価値がある理由: 広告がフルセグメントのリリースに戻されると、ユーザーは広告へのジャンプが遅れて表示されます。 開始方法: 番組部分、広告部分、親セグメント、およびプレイリストの戻り時間を記録し、それぞれ広告前、広告中、広告後のライブエッジ距離を計算します。
関連セッション
- 低遅延 HLS の新機能 - 部分セグメント、ライブ エッジ、低遅延 HLS の基本モデルを理解します。
- HLS ブロッキング プリロード ヒントを発見する - プリロード ヒントを詳しく調べると、広告スイッチングの MAP ヒントと PART ヒントはこのメカニズムに依存しています。
- HLS ブロック プレイリスト リロードによる遅延の削減 — 次の更新を待機するプレイリスト リクエストがどのようにブロックされるかについて説明します。これは、広告段落の遅延を低く維持するための前提条件です。
- HLS プレイリスト デルタ更新によるライブ ストリームの最適化 — 低遅延のライブ ブロードキャスト展開に関連する、大規模なライブ プレイリストの送信コストの処理に適しています。
- HLS ツールによるストリーム オーサリングの改善 — HLS ツールを使用して、プレイリスト、メディア シャーディング、低遅延オーサリングの結果を検証します。
コメント
GitHub Issues · utterances