冗長なマニフェストを設定する手順 - MediaLive
この設定の結果

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

冗長なマニフェストを設定する手順

出力に MediaLive HLS冗長マニフェストを設定するには、2 つのパートがあります。出力グループの 機能を有効にする必要があります。また、出力名と送信先パスの設計も調整する必要があります (冗長マニフェストを実装しないHLS出力と比較して）。

次のフィールドは、特に冗長なマニフェストに関連しています。

  • HLS 出力グループ – マニフェストとセグメント – 冗長マニフェストフィールド

冗長なマニフェストを設定するには

  1. ダウンストリームシステムのオペレータに問い合わせて、冗長マニフェストをサポートしているかどうかを確認してください。

  2. 「出力先フィールド – HTTPサーバーへの送信」の情報を確認します。マニフェストは からの出力と見なされます MediaLive。したがって、出力の送信先に関する一般的なルールが冗長なマニフェストに適用されます。

  3. 2 つのパイプラインURLsの を設計します。HLS ファイルの URLsには特別な要件があります。該当するセクションをお読みください。

    これらのルールは、「出力先フィールド – HTTPサーバーへの送信」の情報を補足するものです。

  4. マニフェストのカスタムパスも必要な場合、「カスタムパスの仕組み」の情報を必ずお読みください。を設計するときは、カスタムパスのルールを考慮する必要がありますURLs。

  5. HLS 出力グループセクションのマニフェスト とセグメント では、冗長マニフェスト では、 を選択しますENABLED。このフィールドは、出力グループ内のすべての出力に適用されます。

  6. 設計に従って、次のフィールドに入力します。

    • 出力グループ – HLSグループ送信先セクション

    • 出力グループ – HLS設定 – CDNセクション

    • [Output group] (出力グループ) – [Location] (場所) – [Directory structure] (ディレクトリ構造)

    • [Output group] (出力グループ) – [Location] (場所) – [Segments per subdirectory (サブディレクトリごとのセグメント

    • HLS 出力 – 出力設定 – 名前修飾子

    • HLS 出力 – 出力設定 – セグメント修飾子

    • HLS 出力グループ – Location –Base URL Manifest (カスタムパスも設定している場合）

    • HLS 出力グループ – Location – Base URL Content (カスタムパスも設定している場合）

マHLSニフェストの内容を変更する方法については、「」を参照してくださいHLS マニフェストのメディアコンテンツ。

この設定の結果

次の 3 つの障害シナリオで冗長なマニフェストがどのように機能するかについて説明します。

シナリオ A - 入力損失時のアクションが出力を発行することである

いずれかのパイプラインで入力が失われ、入力損失アクションフィールドが EMIT_OUTPUT に設定されている場合、 MediaLive は引き続き親マニフェストと子マニフェストを更新します。

ダウンストリームシステムの観点からは、どちらのパイプラインでも親マニフェストまたは子マニフェストに変更はありません。メディアファイル内のコンテンツはフィラーコンテンツですが、ダウンストリームシステムがマニフェストを読み込む方法には影響しません。

シナリオ B - 入力損失時のアクションが出力を一時停止することである

いずれかのパイプライン (パイプライン 0 など) で入力が失われ、入力損失アクションフィールドが PAUSE_OUTPUT に設定されている場合、以下 MediaLive を実行します。

  • パイプライン 0 の子マニフェストのリスト化を削除する。

  • 子マニフェストを削除するために、パイプライン 0 の子マニフェストの場所にリクエストを送信する。

ダウンストリームシステムがパイプライン 0 のメインマニフェストを読み込んだ結果、パイプライン 0 の子マニフェストのリスト化は見つかりません。システムは、パイプライン 0 のメインマニフェストで、代替の子マニフェストを探します。パイプライン 1 の子マニフェストが見つかった場合、その子マニフェストの読み込みに切り替わります。

パイプライン 1 のメインマニフェストを読み込んでいるダウンストリームシステムは、おそらくパイプライン 1 の子マニフェストを読み込んでいるため (それらの子マニフェストがメインマニフェストに最初に表示されるため)、影響を受けません。

シナリオ C - パイプラインの失敗

パイプラインが失敗する可能性もあります。この失敗は、入力の失敗と同じではありません。パイプラインが失敗した場合 (パイプライン 0 など)、次のことが発生します。

  • 出力が停止します。

  • パイプライン 0 のメインマニフェストは削除されません。これには、パイプライン 0 の子マニフェストのリスト化が引き続き含まれています。

  • 新しいメディアファイルが生成されていないため、子マニフェストは更新されません。そのため、子マニフェストは古いです。

  • パイプライン 1 のメインマニフェストは変更されません。これには、パイプライン 0 (およびパイプライン 1) の子マニフェストのリスト化が引き続き含まれています。

ダウンストリームシステムがパイプライン 0 のメインマニフェストを読み込んだ結果、パイプライン 0 の子マニフェストのリスト化が見つかりますが、そのマニフェストは古いです。マニフェストが古いことをシステムが検出できる場合、システムは、パイプライン 0 のメインマニフェストに戻り、代替の子マニフェストを検索できます。パイプライン 1 の子マニフェストが見つかった場合、その子マニフェストの読み込みに切り替わります。

パイプライン 1 のメインマニフェストを読み込んでいるダウンストリームシステムは、影響を受けません。これらのシステムは、おそらくパイプライン 1 の子マニフェストを読み込んでいます (それらの子マニフェストがメインマニフェストに最初に表示されるため)。

注記

HLS 出力のダウンストリームシステムが の場合 AWS Elemental MediaStore、古い入力を削除する MediaStore ように を設定できます。「オブジェクトのライフサイクルポリシーのコンポーネント」を参照してください。子マニフェストが削除されると、 はシナリオ B の MediaStore 「マニフェストが削除された」ロジックにフォールバックします。