

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

# ダウンストリームシステムとの調整
<a name="hls-opg-coordinate-dss"></a>

AWS Elemental MediaLive の HLS 出力グループは、いくつかのタイプのダウンストリームシステムをサポートしています。使用しているシステムに適用される情報をお読みください。

**Topics**
+ [Amazon S3 への HLS 出力グループ](origin-server-hls-s3.md)
+ [MediaStore への HLS 出力グループ](origin-server-ems.md)
+ [MediaPackage への HLS 出力グループ](origin-server-hls-emp.md)
+ [MediaPackage v2 への HLS 出力グループ](origin-server-hls-empv2.md)
+ [HTTP への HLS 出力グループ](origin-server-http.md)

# Amazon S3 への HLS 出力グループ
<a name="origin-server-hls-s3"></a>

この手順に従って、Amazon S3 を送信先とする HLS 出力グループを作成することに[決めました](identify-downstream-system.md)。HLS 出力グループの出力の送信先について、ダウンストリームシステムのオペレータと合意する必要があります。

**送信先のセットアップを手配するには**

1. 出力に 2 つの送信先が必要かどうかを判断します。
   + [標準チャンネル](plan-redundancy.md)には2つのデスティネーションが必要です。
   + シングルパイプラインチャネルには1つのデスティネーションが必要です。

1. Amazon S3 バケットとすべてのフォルダという宛先の完全なパスを設計することをお勧めします。「[出力先のパスを設計します。](hls-destinations-design-step.md)」を参照してください。

1. Amazon S3 ユーザーに、まだ存在しないバケットを作成するように依頼します。

   MediaLive では、Amazon S3 バケット名にドット表記を使用しないでください。つまり、バケット名の単語間に . (ドット) を使用しないでください。

1. Amazon S3 ユーザーと所有権について話し合います。バケットが別の AWS アカウントに属している場合、通常はそのアカウントを出力の所有者にします。詳細については、この手順の後の「[出力へのアクセスの制御](#setting-dss-hls-canned-acl)」を参照してください。

S3 バケットに送信するためにユーザー認証情報が必要になります。MediaLive は、信頼されたエンティティを介して S3 バケットに書き込むアクセス許可を持っています。これらのアクセス権限が組織内の誰かによって既に設定されている必要があります。詳細については、「[信頼されるエンティティのアクセス要件](trusted-entity-requirements.md)」を参照してください。

## 出力へのアクセスの制御
<a name="setting-dss-hls-canned-acl"></a>

別の AWS ア カウントによって所有されている Amazon S3 バケットに出力ファイルを送信したい場合があります。このような場合、通常、もう一方のアカウントが出力ファイル (バケットに入れられるオブジェクト) の所有者になることが望まれます。バケット所有者がオブジェクトの所有者にならない場合、ファイルが不要になったときにファイルを削除できる唯一のエージェントは MediaLive になります。

したがって、Amazon S3 バケット内の出力ファイルの所有権を転送することは、すべての人に関わってきます。

オブジェクトの所有権を転送するには、次の設定が必要です。
+ バケット所有者は、MediaLive がバケットに出力ファイルを配信するときに Amazon S3 の定型のアクセスコントロールリスト (ACL) を追加するアクセス許可を付与するバケットアクセス許可ポリシーを追加する必要があります。バケット所有者は、「Amazon Simple Storage Service ユーザーガイド」の[「ACL によるアクセス管理」](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acls)の説明をお読みください。バケット所有者は、オブジェクトではなく、バケットの ACL アクセス許可を設定する必要があります。
+ バケット所有者はオブジェクトの所有権も設定してください。この機能により、送信者 (MediaLive) にとって*バケット所有者のフルコントロール* ACL が (オプションではなく) 必須になります。バケット所有者は、「Amazon Simple Storage Service ユーザーガイド」の[「オブジェクト所有者の管理」](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership)の説明をお読みください。

  バケット所有者がこの機能を実装している場合は、ACL を含めるように MediaLive を設定する必要があります。重複してしまうと、Amazon S3 バケットへの配信は失敗します。
+ MediaLive を設定して、バケットの配信時に*バケット所有者のフルコントロール** *ACL を含めるようにする必要があります。この設定は、[チャンネルの作成](hls-destinations-s3-specify.md)時に実行します。

S3 の既定 ACL 機能は、*バケット所有者のフルコントロール*以外の ACL をサポートしますが、これらの他の ACL は通常 MediaLive からビデオを配信するユースケースには適用されません。

# MediaStore への HLS 出力グループ
<a name="origin-server-ems"></a>

を宛先 AWS Elemental MediaStore として HLS 出力グループを作成する[と判断した場合](identify-downstream-system.md)は、この手順に従います。HLS 出力グループの出力の送信先について、ダウンストリームシステムのオペレータと合意する必要があります

**送信先のセットアップを手配するには**

1. 出力に 2 つの送信先が必要かどうかを判断します。
   + [標準チャンネル](plan-redundancy.md)には2つのデスティネーションが必要です。
   + シングルパイプラインチャネルには1つのデスティネーションが必要です。

1. 送信先のフルパスを設計することをお勧めします。「[出力先のパスを設計します。](hls-destinations-design-step.md)」を参照してください。

   送信先が 2 つある場合、送信先のパスは何らかの方法で互いに異なっていなければなりません。1 つのパスの少なくとも 1 つの部分が、もう一方のパスと異なっていなければなりません。すべての部分が異なっていても許容されます。

1. MediaStore ユーザーに、コンテナの作成を依頼します。

1. 1 つ以上のコンテナのデータエンドポイントを取得します。例えば：

   `https://a23f.data.mediastore.us-west-2.amazonaws.com`

   `https://fe30.data.mediastore.us-west-2.amazonaws.com`

   データエンドポイントが必要です。コンテナ名は不要です。

MediaStore コンテナに送信するためにユーザー認証情報は必要ありません。MediaLive は、信頼されたエンティティを介して MediaStore コンテナに書き込むアクセス許可を持っています。これらのアクセス権限が組織内の誰かによって既に設定されている必要があります。詳細については、「[信頼されるエンティティのアクセス要件](trusted-entity-requirements.md)」を参照してください。

# MediaPackage への HLS 出力グループ
<a name="origin-server-hls-emp"></a>

HLS出力グループを作成し、HTTPSで「 AWS Elemental MediaPackage 」に送信すると[決定した](identify-downstream-system.md)場合は、この手順に従ってください。HLS 出力グループの出力の送信先について、ダウンストリームシステムのオペレータと合意する必要があります。

**送信先のセットアップを手配するには**

1. MediaPackage ユーザーに MediaPackage で 1 つのチャンネルを作成するように依頼します。MediaLiveチャンネルが[標準チャンネル](plan-redundancy.md) (パイプラインが 2 つ) でも、必要な MediaPackage チャンネルは 1 つのみです。

1. MediaPackage ユーザーとともに HTTPS ユーザーの認証情報をセットアップするように手配します。MediaPackage への送信は、安全な接続で行う必要があります。

1. 以下の情報を提供します。
   + チャンネルの 2 つの URL (入力エンドポイントは MediaPackage の用語) です。チャンネルの 2 つの URL は次のようになります。

      `https://6d2c.mediapackage.uswest-2.amazonaws.com/in/v2/9dj8/9dj8/channel`

      `https://6d2c.mediapackage.uswest-2.amazonaws.com/in/v2/9dj8/e333/channel`

     2 つの URL は、`channel` の直前のフォルダを除いて、常に同一です。

     チャンネル名（`arn`で始まる）ではなく、URL（`https://`で始まる）を取得していることを確認してください。
   + ダウンストリームシステムが認証リクエストを必要とする場合、ダウンストリームシステムにアクセスするためのユーザー名とパスワードです。これらのユーザー認証情報は、プロトコルではなくユーザー認証に関連することに注意してください。ユーザー認証は、ダウンストリームシステムがリクエストを受け入れるかどうかにまつわることです。プロトコルは、リクエストが安全な接続を介して送信されるかどうかに関するものです。

# MediaPackage v2 への HLS 出力グループ
<a name="origin-server-hls-empv2"></a>

HLS出力グループを作成し、MediaPackage v2に送信すると[決定した](hls-choosing-hls-vs-emp.md)場合は、この手順に従ってください。HLS 出力グループの出力の送信先について、ダウンストリームシステムのオペレータと合意する必要があります。

**送信先のセットアップを手配するには**

1. MediaPackage ユーザーに MediaPackage で 1 つのチャンネルを作成するように依頼します。MediaLiveチャンネルが[標準チャンネル](plan-redundancy.md) (パイプラインが 2 つ) でも、必要な MediaPackage チャンネルは 1 つのみです。

1. チャンネルの2つのURL（入力エンドポイントはMediaPackageの用語）を取得します。チャンネルの 2 つの URL は次のようになります。

    `https://mz82o4-1.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/1/curling/index` 

    `https://mz82o4-2.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/2/curling/index`

   上記の例に示すように、2 つの URLs は若干異なります。

   チャンネル名（`arn`で始まる）ではなく、URL（`https://`で始まる）を取得していることを確認してください。

   MediaPackage v2に送信するためにユーザー認証情報を使用しないことに注意してください。

# HTTP への HLS 出力グループ
<a name="origin-server-http"></a>

この手順に従って、次のダウンストリームシステムのいずれかを送信先とする HLS 出力グループを作成することに[決めました](identify-downstream-system.md)。
+ HTTP または HTTPS PUT サーバー。
+ HTTP または HTTPS WebDAV サーバー。
+ Akamai オリジンサーバー。

HLS 出力グループの出力の送信先について、ダウンストリームシステムのオペレータと合意する必要があります。

HTTP 経由で HLS を配信する場合、多くの場合、オリジンサーバーに配信されます。通常、オリジンサーバーには、メインマニフェスト (`.M3U8` ファイル) のファイル名など、送信先パスのルールに関する明確なガイドラインがあります。

**送信先のセットアップを手配するには**

設定を調整するには、ダウンストリームシステムでオペレータに相談する必要があります。

1. ダウンストリームシステムが Akamai サーバーでない場合は、PUT または WebDAV を使用しているかどうかを調べます。

1. ダウンストリームシステムに特別な接続要件がないか、調べます。これらの接続フィールドは、コンソールの HLS 出力グループ **[CDN settings]** (CDN 設定) セクションにあります。MediaLive コンソールでこのページを表示するには、**[Create channel]** (チャンネルの作成)ページの **[Output groups]** (出力グループ) セクションで **[Add]** (追加) を選択してから **[HLS]** を選択します。グループを選択してから **[HLS settings]** (HLS 設定) で **[CDN settings]** (CDN 設定) を開きます。

1. 出力に 2 つの送信先が必要かどうかを判断します。
   + [標準チャンネル](plan-redundancy.md)には2つのデスティネーションが必要です。
   + シングルパイプラインチャネルには1つのデスティネーションが必要です。

1. ダウンストリームシステムがセキュア接続を使用しているかどうかを調べます。その場合は、オペレータにユーザー認証情報を設定するように配置します。

1. そのダウンストリームシステムで、メインマニフェストと子マニフェスト内にカスタムパスが必要かどうかを調べます。詳細については、「[HLS マニフェスト内のパスのカスタマイズ](hls-manifest-paths.md)」を参照してください。

1. [標準チャンネル](plan-redundancy.md)を設定しようとする場合、ダウンストリームシステムが冗長マニフェストをサポートしているかどうかを確認してください。サポートしている場合は、この機能を実装するかどうかを決定します。詳細については「[冗長 HLS マニフェストの作成](hls-redundant-manifests.md)」を参照し、具体的な手順については、特に「[ほとんどのダウンストリームシステムのルール](hls-redundant-manif-most-systems.md)」と「[Akamai CDN のルール](hls-redundant-manif-akamai.md)」を参照してください。

1. ダウンストリームシステムのオペレータに相談して、HLS ファイルの 3 つのカテゴリ (メインマニフェスト、子マニフェスト、メディアファイル) の完全な送信先パスについて合意します。MediaLive は、送信先ごとに 3 つのファイルカテゴリを常にこの場所に置きます。一部のファイルを別の場所に置くように MediaLive を設定することはできません。

   送信先が 2 つある場合、送信先のパスは何らかの方法で互いに異なっていなければなりません。1 つのパスの少なくとも 1 つの部分が、もう一方のパスと異なっていなければなりません。すべての部分が異なっていても許容されます。この要件は、ダウンストリームシステムのオペレータと話し合います。ダウンストリームシステムには、一意性に関する特定のルールがある場合があります。

1. HLS ファイルの 3 つのカテゴリの名前に関する特別な要件については、ダウンストリームシステムのオペレータに相談してください。通常、ダウンストリームシステムには特別な要件はありません。

1. 子マニフェストとメディアファイルの名前に関する修飾子の特別な要件については、ダウンストリームシステムのオペレータに相談してください。

   子マニフェストとメディアファイルでは、ファイル名にこの修飾子が常に含まれています。この修飾子は、個々の出力を区別できるように各出力で一意である必要があります。例えば、高解像度出力のファイルは、低解像度出力のファイルとは異なる名前である必要があります。例えば、1 つの出力のファイルに、ファイル名と修飾子 `curling_high` を指定し、一方、他の出力に `curling_low` を含めることができます。

   通常、ダウンストリームシステムには特別な要件はありません。

1. メディアファイルを専用のサブディレクトリに設定すべきかは、ダウンストリームシステムのオペレータに問い合わせてください。例えば、最初の 1000 個のセグメント用に 1 つのサブディレクトリ、次の 1000 個用に別のサブディレクトリ、というように続きます。

   ほとんどのダウンストリームシステムでは、個別のサブディレクトリは必要ありません。

1. ダウンストリームシステムに特別な要件がある送信先パスの部分について合意します。
   + 例えば、ダウンストリームシステムでは、特定のホストへの送信のみが必要になる場合があります。ダウンストリームシステムでは、使用するフォルダやファイル名を知る必要はありません。

     例えば、名前を付けた 2 つのフォルダに送信しますが、`https://203.0.113.55` のホスト上です。

     または、ホスト上にある `https://203.0.113.55` および `https://203.0.113.82` という 2 つのフォルダに送信します。
   + または、ダウンストリームシステムでは、選択したファイル名を持つ特定のホストとフォルダが必要になる場合があります。例えば、次のホストとフォルダは次のようになります。

     `https://203.0.113.55/sports/delivery/`

     `https://203.0.113.55/sports/backup/`

1. 収集した情報を書き留めておきます。
   + ダウンストリームシステムの接続タイプ — Akamai、PUT、または WebDAV。
   + ダウンストリームシステムに特別な要件がある場合は、接続フィールドの設定。
   + 配信用のプロトコル — HTTP または HTTPS。
   + ダウンストリームシステムが認証リクエストを必要とする場合、ダウンストリームシステムにアクセスするためのユーザー名とパスワードです。これらのユーザー認証情報は、プロトコルではなくユーザー認証に関連することに注意してください。ユーザー認証は、ダウンストリームシステムがリクエストを受け入れるかどうかにまつわることです。プロトコルは、リクエストが安全な接続を介して送信されるかどうかに関するものです。
   + ファイル名を含む送信先パスの全部または一部。
   + 個別のサブディレクトリを設定する必要があるかどうか。