翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 冗長 HLS マニフェストの作成 標準MediaLiveチャンネルで HLS 出力グループを作成すると、冗長なマニフェストを有効にすることができます。冗長なマニフェストにより、ダウンストリームシステム (マニフェストを読み込む) は、 MediaLive からの出力失敗をより適切に処理できます。 冗長なマニフェスト機能が有効になっている場合、各パイプラインのメインマニフェストは、独自の子マニフェストと他のパイプラインの子マニフェストの両方を参照します。ダウンストリームシステムは、1 つのパイプラインの子マニフェストへのパスを検索します。そのパイプラインに問題がある場合、そのパイプラインの子マニフェストに問題があります。その後、ダウンストリームシステムはメインマニフェストを再度参照して、他のパイプラインの子マニフェストを見つけることができます。このようにして、ダウンストリームシステムは、常にマニフェストとメディアの処理を続行できます。 冗長なマニフェストを正常に実装するために、ダウンストリームシステムが HLS 仕様に記載されている方法で冗長なマニフェストを処理できることを確認する必要があります。 **注記** HLS マニフェストのこのセクションの情報は、「[ゼロからのチャンネルの作成](creating-channel-scratch.md)」で説明しているように、チャンネルを作成する一般的な手順に精通していることを前提としています。 この機能に関係するコンソール内の主なフィールドは **[Create channel]** (チャンネルの作成) ページにある **[HLS output group]** (HLS 出力グループ) セクションの **[Manifests and segments]** (マニフェストとセグメント) グループです。これらのフィールドに入力する手順を確認するには、「[手順](creating-hls-output-group.md#hls-create-procedure)」を参照してください。 **Topics** + [冗長なマニフェストを設定する手順](hls-rm-procedure.md) + [HLS マニフェストのメディアコンテンツ](hls-rm-manifests-contents.md) + [ほとんどのダウンストリームシステムのルール](hls-redundant-manif-most-systems.md) + [Akamai CDN のルール](hls-redundant-manif-akamai.md) + [冗長なマニフェストを他の機能と組み合わせる](hls-redundant-manif-combine.md) # 冗長なマニフェストを設定する手順 MediaLive HLS 出力で冗長マニフェストをセットアップするには、2 つのパートがあります。出力グループの 機能を有効にする必要があります。また、出力名と送信先パスの設計も調整しなければならない (冗長なマニフェストを実装しない HLS 出力と比較して)。 次のフィールドは、特に冗長なマニフェストに関連しています。 + **[HLS output group] (HLS 出力グループ) – [Manifests and Segments] (マニフェストとセグメント) – [Redundant manifests] ([冗長なマニフェスト)** フィールド **冗長なマニフェストを設定するには** 1. 冗長マニフェストをサポートしているかどうか、下流システムのオペレーターに問い合わせてください。 1. 「[出力先のフィールド — HTTP サーバーへの送信](hls-destinations-http.md)」の情報を確認します。マニフェストは、MediaLive から出力されると見なされます。したがって、出力の送信先に関する一般的なルールが冗長なマニフェストに適用されます。 1. 2 つのパイプラインの URL を設計します。HLS ファイルの URL には、特別な要件があります。該当するセクションをお読みください。 + [ほとんどのダウンストリームシステムのルール](hls-redundant-manif-most-systems.md) + [Akamai CDN のルール](hls-redundant-manif-akamai.md) これらのルールは、「[出力先のフィールド — HTTP サーバーへの送信](hls-destinations-http.md)」の情報を補足するものです。 1. マニフェストのカスタムパスも必要な場合、「[カスタムパスの仕組み](hls-manifests-how-work.md#hls-custom-manifest-paths)」の情報を必ずお読みください。URL を設計する際、カスタムパスのルールを考慮する必要があります。 1. **[HLS 出力グループ]** セクションで、**[マニフェストとセグメント]** と [**Redundant manifests (冗長なマニフェスト)]** に対して **[ENABLED]** (有効) を選択します。このフィールドは、出力グループ内のすべての出力に適用されます。 1. 設計に従って、次のフィールドに入力します。 + **[Output group] (出力グループ) – [HLS group destination] (HLS グループ送信先)** セクション + **[Output group] (出力グループ) – [HLS settings] (HLS 設定) – [CDN]** セクション + **[Output group] (出力グループ) – [Location] (場所) – [Directory structure] (ディレクトリ構造)** + **[Output group] (出力グループ) – [Location] (場所) – [Segments per subdirectory (サブディレクトリごとのセグメント** + **[HLS outputs] (HLS 出力) – [Output settings] (出力設定) – [Name modifier] (名前修飾子)** + **[HLS outputs] (HLS 出力) – [Output settings] (出力設定) – [Segment modifier] (セグメント修飾子)** + **[HLS output group] (HLS 出力グループ) – [Location] (場所) – [Base URL Manifest] (ベース URL マニフェスト)** (カスタムパスも設定している場合) + **[HLS output group] (HLS 出力グループ) – [Location] (場所) – [Base URL Content](ベース URL コンテンツ)** (カスタムパスも設定している場合) この機能によって HLS マニフェストのコンテンツがどのように変更されるかについては、「[HLS マニフェストのメディアコンテンツ](hls-rm-manifests-contents.md)」を参照してください。 ## この設定の結果 次の 3 つの障害シナリオで冗長なマニフェストがどのように機能するかについて説明します。 ### シナリオ A - 入力損失時のアクションが出力を発行することである いずれかのパイプラインで入力が失われ、[**[Input loss action]** (入力損失時のアクション) フィールド](hls-other-features.md#hls-resiliency)が **EMIT\$1OUTPUT** に設定されている場合、MediaLive は、マスターマニフェストと子マニフェストの更新を続行します。 ダウンストリームシステムの観点からは、どちらのパイプラインでも親マニフェストまたは子マニフェストに変更はありません。メディアファイル内のコンテンツはフィラーコンテンツですが、ダウンストリームシステムがマニフェストを読み込む方法には影響しません。 ### シナリオ B - 入力損失時のアクションが出力を一時停止することである いずれかのパイプライン (パイプライン 0 など) で入力が失われ、**[Input loss action]** (入力損失時のアクション) フィールドが **PAUSE\$1OUTPUT** に設定されている場合、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 を設定できます。「[オブジェクトのライフサイクルポリシーのコンポーネント](https://docs.aws.amazon.com/mediastore/latest/ug/policies-object-lifecycle-components.html)」を参照してください。子マニフェストが削除された後、MediaStore は、シナリオ B の「マニフェストが削除されました」ロジックにフォールバックします。 # HLS マニフェストのメディアコンテンツ HLS出力で冗長マニフェストを設定すると、MediaLiveはマニフェストの内容を変更します。これにより、マニフェスト内のメディア情報 (動画、オーディオ、および字幕の情報) が変更されます。この情報はすべて、「`#EXT-X-STREAM-INF`」 タグとして表示されます。 次のセクションでは、標準 (冗長ではない) マニフェストおよび冗長なマニフェストにおけるそれらのタグの数とそれらのタグの内容について説明します。 ## 標準マニフェストの内容 標準チャンネルでは、2 つのパイプラインがあります。各パイプラインは、独自のマニフェストのセットを生成します。したがって、パイプライン 0 には、1 つのメインマニフェスト、1 つの子マニフェストセット、1 つのメディアファイルセットがあります。同様に、パイプライン 1 には同じファイルセットがあります。マニフェストは、独自のパイプラインのファイルのみを参照します。 各パイプラインのメインマニフェストの動画情報は、次のようになります。 ``` #EXT-X-STREAM-INF:BANDWIDTH=629107 ... curling-high.m3u8 ``` ## 冗長なマニフェストの内容 冗長なマニフェスト機能が有効になっている場合、各メインマニフェストは、独自のパイプラインおよび他のパイプラインの子マニフェストを参照します。 この機能は、子マニフェストには影響しません。子マニフェストは、独自のメディアファイルのみを参照します。 以下に、マニフェスト内の動画情報がどのように表示されるかについての例を示します。パイプライン 0 の baseFilename が *first\$1curling* であり、パイプライン 1 の方は *other\$1curling* であると仮定します。 パイプライン 0 のマニフェストは、次のようになります (パイプライン 0 の子マニフェスト情報が最初に表示されます)。 ``` #EXT-X-STREAM-INF:BANDWIDTH=629107 ... first-curling-high.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=629107 ... other-curling-high.m3u8 ``` パイプライン 1 のマニフェスト内の動画情報は、次のようになります (パイプライン 1 の子マニフェスト情報が最初に表示されます)。 ``` #EXT-X-STREAM-INF:BANDWIDTH=629107 ... other-curling-high.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=629107 ... first-curling-high.m3u8 ``` # ほとんどのダウンストリームシステムのルール MediaLive HLS 出力グループで冗長マニフェストをセットアップできます。ただし、ダウンストリームシステムが特定のルールを操作できる場合に限ります。Akamai 以外のダウンストリームシステムで冗長なマニフェストを設定する場合は、このセクションをお読みください。ダウンストリームシステムが Akamai CDN の場合は、「[Akamai CDN のルール](hls-redundant-manif-akamai.md)」を参照してください。 ダウンストリームシステムが次のルールを実行できることを確認する必要があります。 + MediaLive が両方のパイプラインから同じ場所 (プロトコル/ドメイン/パス) にファイルをプッシュする。 + 場所が同一である場合、パイプラインのベースファイル名は異なっている必要がある。 + [カスタムマニフェストパス](hls-manifests-how-work.md#hls-custom-manifest-paths)も実装する場合、マニフェスト内の URL は同じである必要がある。 | フィールド | ルール | | --- | --- | | 2 つの送信先 URI (A と B) のプロトコル/ドメイン/パス部分 | 両方のフィールドで同一である必要があります。 | | 2 つの送信先 URI (A と B) の BaseFilename 部分 | 各フィールドで異なっている必要があります。 日付または時刻を含む[変数識別子](variable-data-identifiers.md)は使用*できません*。 | | 各出力の NameModifier | このフィールドのインスタンスは 1 つのみです。どちらのパイプラインも同じ値を使用します。 日付または時刻を含む[変数識別子](variable-data-identifiers.md)は使用*できません*。 | | セグメント修飾子 | このフィールドのインスタンスは 1 つのみです。どちらのパイプラインも同じ値を使用します。 日付または時刻を含む[変数識別子](variable-data-identifiers.md)を使用*できます*。 | | Base URL Manifest A (ベース URL マニフェスト A) と Base URL Manifest B (ベース URL マニフェスト B) | これらのフィールドは、[カスタムマニフェストパス](hls-manifests-how-work.md#hls-custom-manifest-paths)も実装している場合にのみ適用されます。 両方のフィールドに値を入力します。 | | Base URL Content A (ベース URL コンテンツ A) と Base URL Content A (ベース URL コンテンツ B) | これらのフィールドは、[カスタムマニフェストパス](hls-manifests-how-work.md#hls-custom-manifest-paths)も実装している場合にのみ適用されます。 両方のフィールドに値を入力します。 | # Akamai CDN のルール MediaLive HLS 出力グループで冗長マニフェストをセットアップできます。ただし、ダウンストリームシステムが特定のルールを操作できる場合に限ります。Akamai CDN で冗長マニフェストを設定する場合は、このセクションをお読みください。ダウンストリームシステムが Akamai CDN でない場合は、「[ほとんどのダウンストリームシステムのルール](hls-redundant-manif-most-systems.md)」を参照してください。 ダウンストリームシステムが次のルールを実行できることを確認する必要があります。 | フィールド | ルール | | --- | --- | | 2 つの送信先 URI (A と B) のプロトコル/ドメイン/パス部分 | 互いに異なっていても、同じでもかまいません。 | | 2 つの送信先 URI (A と B) の BaseFilename 部分 | 互いに異なっていても、同じでもかまいません。 日付または時刻を含む[変数識別子](variable-data-identifiers.md)は使用*できません*。 プロトコル/ドメイン/パスと baseFilename の組み合わせは、A と B で一意である必要があります。このルールにより、2 つのパイプラインの出力ファイルが互いに上書きされないようになります。 | | 名前修飾子 | このフィールドのインスタンスは 1 つのみです。どちらのパイプラインも同じ値を使用します。 日付または時刻を含む[変数識別子](variable-data-identifiers.md)は使用*できません*。 | | セグメント修飾子 | このフィールドのインスタンスは 1 つのみです。どちらのパイプラインも同じ値を使用します。 日付または時刻を含む[変数識別子](variable-data-identifiers.md)を使用*できます*。 | | Base URL Manifest A (ベース URL マニフェスト A) と Base URL Manifest B (ベース URL マニフェスト B) | これらのフィールドは、[カスタムマニフェストパス](hls-manifests-how-work.md#hls-custom-manifest-paths)も実装している場合にのみ適用されます。通常、Akamai CDN では、カスタムマニフェストパスを実装します。 両方のフィールドに値を入力します。 | | Base URL Content A (ベース URL コンテンツ A) と Base URL Content A (ベース URL コンテンツ B) | これらのフィールドは、[カスタムマニフェストパス](hls-manifests-how-work.md#hls-custom-manifest-paths)も実装している場合にのみ適用されます。 両方のフィールドに値を入力します。 | # 冗長なマニフェストを他の機能と組み合わせる ## 冗長なマニフェストとカスタムパス機能の組み合わせ MediaLive HLS 出力グループに冗長マニフェストを設定する場合、カスタムパスを設定することもできます。[カスタムパス](hls-custom-paths-rules.md)のルールとダウンストリームシステム ([Akamai CDN](hls-redundant-manif-akamai.md) または[別のダウンストリームシステム](hls-redundant-manif-most-systems.md)) 用の冗長マニフェストのルールに従っていることを確認してください。 ## 冗長なマニフェストとオーディオレンディショングループの組み合わせ **注記** このセクションの情報は、オーディオレンディショングループのマニフェストに精通していることを前提としています。詳細については、「[サンプルマニフェスト](sample-manifest.md)」を参照してください。 以下は、オーディオレンディショングループを含む HLS 出力グループで冗長マニフェストをセットアップするときに MediaLive が実行する処理に関する情報です。 MediaLive は、親マニフェスト内のオーディオレンディショングループへの参照を自動的に調整します。 行の各ペア (例えば、高解像度動画用の 「`#EXT-X-STREAM-INF`」) で、MediaLive はそのレンディショングループの名前を調整します。このようにして、レンディショングループへの参照はパイプラインごとに異なります。これにより、クライアントプレーヤーがマニフェストを読み込むときに、同じパイプラインから動画とオーディオが選択されます。 パイプライン 0 の動画の 「`#EXT-X-STREAM`」。*AUDIO* の値を書き留めます。 ``` #EXT-X-STREAM-INF:BANDWIDTH=541107,...AUDIO="aac-audio-0", ... ``` パイプライン 1 の動画の 「`#EXT-X-STREAM`」。*AUDIO* の値を書き留めます。 ``` #EXT-X-STREAM-INF:BANDWIDTH =541107, ...AUDIO="aac-audio-1",... ```