• 沒有找到結果。

Coordinate with downstream systems

在文檔中 AWS Elemental MediaLive (頁 122-132)

Step 7: Arrange for delivery to downstream systems

As the final step in preparing the downstream and upstream systems in your workflow, you must perform this step on each downstream system:

• You and the operator at the downstream system must agree on some portions of the path from AWS Elemental MediaLive to the downstream system.

• You must arrange for the operator at the downstream system to perform some setup so that MediaLive can successfully send outputs to these systems.

The setup is different for each type of output group and downstream system.

The output from MediaLive is considered input to this downstream system. You and the operator of the downstream system must agree about the input locations on the downstream system now, because when you create the MediaLive channel you need those URL locations.

Note that this guide describes how to set up an origin server. It does not describe how to set up the CDN that is downstream of the origin server. For information about that setup, see the documentation for the chosen origin server.

The options

The following table summarizes the combinations of output group and downstream system that are covered in the following sections.

Output group Downstream system Section to read

Archive Amazon S3 the section called “Archive or

frame capture” (p. 112)

Frame capture Amazon S3 the section called “Archive or

frame capture” (p. 112)

HLS Amazon S3 the section called “HLS to

Amazon S3” (p. 113)

HLS AWS Elemental MediaStore the section called “HLS to

MediaStore” (p. 114)

HLS AWS Elemental MediaPackage the section called “HLS to

MediaPackage” (p. 115)

HLS HTTP server or Akamai CDN the section called “HLS to

HTTP” (p. 116) MediaPackage AWS Elemental MediaPackage the section called

“MediaPackage ” (p. 117)

Microsoft Smooth HTTP server the section called “Microsoft

Smooth” (p. 118)

RTMP RTMP server the section called

“RTMP” (p. 119)

UDP UDP address the section called

“UDP” (p. 119)

Archive or frame capture

Result of this step

At the end of this step, you will have completed all the steps to prepare the downstream system to receive content from MediaLive.

Topics

• Archive or frame capture output group (p. 112)

• HLS output group to Amazon S3 (p. 113)

• HLS output group to MediaStore (p. 114)

• HLS output group to MediaPackage (p. 115)

• HLS output group to HTTP (p. 116)

• MediaPackage output group (p. 117)

• Microsoft Smooth output group (p. 118)

• RTMP output group (p. 119)

• UDP output group (p. 119)

Archive or frame capture output group

Follow this procedure if you determined (p. 73) that you will create an archive output group or frame capture output group. The destination for these output groups is always Amazon S3.

You and the operator of the downstream system must agree about the destination for the output of this output group. You will need this information when you create the MediaLive channel (p. 158).

You must follow this procedure for each output group.

To arrange setup of the destination

1. Decide if you need two destinations for the output:

• You need two destinations for output from a standard channel (p. 76).

• You need one destination for output from a single-pipeline channel.

2. Consult with the Amazon S3 user and decide on the bucket name or names. Ask the Amazon S3 user to create any buckets that don't already exist.

3. Discuss ownership with the Amazon S3 user. If the bucket belongs to another AWS account, you typically want that account to become the owner of the output. For more information, see the section called “Controlling access to the output” (p. 113), after this procedure.

4. You can design the full destination paths now, or you can design them when you create the output group.

If you want to design the full paths now, but you aren't familiar with the path requirements, see the section called “Destination fields” (p. 159) or the section called “Destination fields” (p. 165).

If you have two destinations, the destination paths must be different from each other in some way.

At least one of the portions of one path must be different from the other. It is acceptable for all the portions to be different.

5. Make a note of the bucket or the full destination paths.

Note that you don't need user credentials to send to an S3 bucket. MediaLive has permission to write to the bucket via the trusted entity. Someone in your organization should have already set up these permissions. For more information, see the section called “Reference: summary of trusted entity access” (p. 56).

HLS to Amazon S3

Controlling access to the output

You might be sending output files to an Amazon S3 bucket that is owned by another AWS account. In this situation, you typically want the other account to become the owner of the output files (the object being put in the bucket). If the bucket owner doesn't become the object owner, you (MediaLive) will be the only agent that can delete the files when the files are no longer required.

It is therefore in everyone's interest to transfer ownership of the output files after they are in the Amazon S3 bucket.

To transfer object ownership, the following setup is required:

• The bucket owner must add a bucket permissions policy that grants you permission to add an Amazon S3 canned access control list (ACL) when MediaLive delivers the output files to the bucket. The bucket owner should read the information in Managing access with ACLs in the Amazon Simple Storage Service user guide. The bucket owner must set up ACL permissions for the bucket, not for the objects.

• The bucket owner should also set up object ownership. This feature effectively makes it mandatory (rather than optional) for the sender (MediaLive) to include the Bucket owner full control ACL. The bucket owner should read the information in Controlling object ownership in the Amazon Simple Storage Service user guide.

If the bucket owner implements this feature, then you must set up MediaLive to include the ACL. If you don't, delivery to the Amazon S3 bucket will fail.

• You must set up MediaLive to include the Bucket owner full control ACL when it delivers to the bucket.

You will perform this setup when you create the channel (p. 159).

The S3 canned ACL feature supports ACLs other than Bucket owner full control. But those other ACLs are typically not applicable to the use case of delivering video from MediaLive.

HLS output group to Amazon S3

Follow this procedure if you determined (p. 73) that you will create an HLS output group with Amazon S3 as the destination.

You and the operator of the downstream system must agree about the destination for the output of the HLS output group. You will need this information when you create the MediaLive channel (p. 168).

You must follow the procedure for each HLS output group.

To arrange setup of the destination

1. Decide if you need two destinations for the output:

• You need two destinations for output from a standard channel (p. 76).

• You need one destination for output from a single-pipeline channel.

2. Consult with the Amazon S3 user and decide on the bucket name or names. Ask the Amazon S3 user to create any buckets that don't already exist.

3. Discuss ownership with the Amazon S3 user. If the bucket belongs to another AWS account, you typically want that account to become the owner of the output. For more information, see the section called “Controlling access to the output” (p. 114), after this procedure.

4. You can design the full destination paths now, or you can design them when you create the output group.

If you want to design the full paths now, but you aren't familiar with the path requirements, see the section called “Step 1: Design the path” (p. 182).

HLS to MediaStore

If you have two destinations, the destination paths must be different from each other in some way.

At least one of the portions of one path must be different from the other. It is acceptable for all the portions to be different.

5. Make a note of the bucket or full destination paths.

Note that you don't need user credentials to send to an S3 bucket. MediaLive has permission to write to the S3 bucket via the trusted entity. Someone in your organization should have already set up these permissions. For more information, see the section called “Reference: summary of trusted entity access” (p. 56).

Controlling access to the output

You might be sending output files to an Amazon S3 bucket that is owned by another AWS account. In this situation, you typically want the other account to become the owner of the output files (the object being put in the bucket). If the bucket owner doesn't become the object owner, you (MediaLive) will be the only agent that can delete the files when the files are no longer required.

It is therefore in everyone's interest to transfer ownership of the output files after they are in the Amazon S3 bucket.

To transfer object ownership, the following setup is required:

• The bucket owner must add a bucket permissions policy that grants you permission to add an Amazon S3 canned access control list (ACL) when MediaLive delivers the output files to the bucket. The bucket owner should read the information in Managing access with ACLs in the Amazon Simple Storage Service user guide. The bucket owner must set up ACL permissions for the bucket, not for the objects.

• The bucket owner should also set up object ownership. This feature effectively makes it mandatory (rather than optional) for the sender (MediaLive) to include the Bucket owner full control ACL. The bucket owner should read the information in Controlling object ownership in the Amazon Simple Storage Service user guide.

If the bucket owner implements this feature, then you must set up MediaLive to include the ACL. If you don't, delivery to the Amazon S3 bucket will fail.

• You must set up MediaLive to include the Bucket owner full control ACL when it delivers to the bucket.

You will perform this setup when you create the channel (p. 172).

The S3 canned ACL feature supports ACLs other than Bucket owner full control, but those other ACLs are typicallly not applicable to the use case of delivering video from MediaLive.

HLS output group to MediaStore

Follow this procedure if you determined (p. 73) that you will create an HLS output group, with AWS Elemental MediaStore as the destination.

You and the operator of the downstream system must agree about the destination for the output of the HLS output group. You will need this information when you create the MediaLive channel (p. 168).

You must follow the procedure for each HLS output group.

To arrange setup of the destination

1. Decide if you need two destinations for the output:

• You need two destinations for output from a standard channel (p. 76).

HLS to MediaPackage

• You need one destination for output from a single-pipeline channel.

2. If you have two destinations, the destination paths must be different from each other in some way.

At least one of the portions of one path must be different from the other. It is acceptable for all the portions to be different.

You can design the full destination paths now, or you can decide only on the container name or names:

• If you want to design the full paths now, but you aren't familiar with the destination requirements for an HLS output, see the section called “Step 1: Design the path” (p. 182). You and the

MediaStore user must agree on the containers that you want to use.

• If you want to decide only on the containers, you and the MediaStore user must agree on which containers to use.

3. Ask the MediaStore user to create any containers that don't already exist.

4. Obtain the data endpoint for the container or containers. For example:

https://a23f.data.mediastore.us-west-2.amazonaws.com https://fe30.data.mediastore.us-west-2.amazonaws.com You need the data endpoints. You don't need the container name.

Note that you don't need user credentials to send to MediaStore containers. MediaLive has permission to write to the MediaStore container via the trusted entity. Someone in your organization should have already set up these permissions. For more information, see the section called “Reference: summary of trusted entity access” (p. 56).

HLS output group to MediaPackage

Follow this procedure if you determined (p. 73) that you will create an HLS output group, and will send to AWS Elemental MediaPackage over HTTPS.

You and the operator of the downstream system must agree about the destination for the output of the HLS output group. You will need this information when you create the MediaLive channel (p. 168).

Note that you can send to AWS Elemental MediaPackage by creating a MediaPackage output group, or by creating an HLS output group. See the section called “HLS versus MediaPackage” (p. 74) for a description of the differences. This section describes the second option.

Follow this guidance for each HLS output group.

To arrange setup of the destination

1. Ask the MediaPackage user to create one channel on MediaPackage. Even if the MediaLive channel is a standard channel (p. 76) (with two pipelines), you need only one MediaPackage channel.

2. Arrange with the MediaPackage user to set up HTTPS user credentials. You must send to MediaPackage over a secure connection.

3. Obtain the following information:

• The two URLs (input endpoints is the MediaPackage terminology) for the channel. The two URLs for a channel look like this:

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

HLS to HTTP

The two URLs are always identical except for the folder just before channel.

Make sure that you obtain the URLs, not the channel name.

• The user name and password to access the downstream system, if the downstream system requires authenticated requests. Note that these user credentials relate to user authentication, not to the protocol. User authentication is about whether the downstream system will accept your request. The protocol is about whether the request is sent over a secure connection.

HLS output group to HTTP

Follow this procedure if you determined (p. 73) that you will create an HLS output group with one of the following downstream systems as the destination:

• An HTTP or HTTPS PUT server.

• An HTTP or HTTPS WebDAV server.

• An Akamai origin server.

You and the operator of the downstream system must agree about the destination for the output of the HLS output group. You will need this information when you create the MediaLive channel (p. 168).

When you deliver HLS over HTTP, you are often delivering to an origin server. The origin server typically has clear guidelines about the rules for the destination path, including the file name of the main manifest (the .M3U8 file).

You must follow the procedure for each HLS output group.

To arrange setup of the destination

You must talk to the operator at the downstream system to coordinate your setup.

1. If the downstream system isn't an Akamai server, find out if it uses PUT or WebDAV.

2. Find out if the downstream system has special connection requirements. These connection fields are grouped in the console in the CDN settings section for the HLS output group. To display this page on the MediaLive console, in the Create channel page, in the Output groups section, choose Add, then choose HLS. Choose the group, then in HLS settings, open CDN settings.

3. Decide if you need two destinations for the output:

• You need two destinations for output from a standard channel (p. 76).

• You need one destination for output from a single-pipeline channel.

4. Find out if the downstream system uses a secure connection. If it does, arrange with the operator to set up user credentials.

5. Find out if the downstream system requires custom paths inside the main manifests and the child manifests. For more information, see the section called “Manifests – custom HLS manifest paths” (p. 431).

6. If you are setting up a standard channel (p. 76), find out if the downstream system supports redundant manifests. If so, decide if you want to implement this feature. For more information, see the section called “Manifests – Redundant HLS manifests” (p. 435), and specifically the section called “Rules for most systems” (p. 438) and the section called “Rules for Akamai” (p. 439) for specific instructions.

7. Talk to the operator at the downstream system to agree on a full destination path for the three categories of HLS files (the main manifests, the child manifests, and the media files). MediaLive

MediaPackage

always puts all three categories of files for each destination in this one location. It’s not possible to configure MediaLive to put some files in another location.

If you have two destinations, the destination paths must be different from each other in some way.

At least one of the portions of one path must be different from the other. It is acceptable for all the portions to be different. Discuss this requirement with the operator of the downstream system. The downstream system might have specific rules about uniqueness.

8. Talk to the operator at the downstream system about special requirements for the names of the three categories of HLS files. Typically, the downstream system doesn’t have special requirements.

9. Talk to the operator at the downstream system about special requirements for the modifier on the names of the child manifests and media files.

The child manifests and media files always include this modifier in their file names. This modifier distinguishes each output from the other, so it must be unique in each output. For example, the files for the high-resolution output must have a different name from the files for the low-resolution output. For example, the files for one output could have the file name and modifier curling_high, while the other output could have curling_low.

Typically, the downstream system doesn’t have special requirements.

10. Ask the operator of the downstream system if the media files should be set up in separate

subdirectories. For example, one subdirectory for the first 1000 segments, another subdirectory for the second 1000 segments, and so on.

Most downstream systems don’t require separate subdirectories.

11. Agree on the portions of the destination path where the downstream system has special requirements.

• For example, the downstream system might only require that you send to a specific host.

For example, send to two folders that you name, but on the host at https://203.0.113.55 Or send to two folders that you name, but on the hosts at https://203.0.113.55 and https://203.0.113.82

• Or the downstream system might require a specific host and folder, but with a file name that you choose. For example, this host and folders:

https://203.0.113.55/sports/delivery/

https://203.0.113.55/sports/backup/

12. Make a note of the information you have collected:

• The connection type for the downstream system – Akamai, PUT, or WebDAV.

• The settings for connection fields, if the downstream system has special requirements.

• The protocol for delivery—HTTP or HTTPS.

• The user name and password to access the downstream system, if the downstream system requires authenticated requests. Note that these user credentials relate to user authentication, not to the protocol. User authentication is about whether the downstream system will accept your request. The protocol is about whether the request is sent over a secure connection.

• All or part of the destination paths, possibly including the file names.

• Whether you need to set up separate subdirectories.

MediaPackage output group

Follow this procedure if you determined (p. 73) that you will create a MediaPackage output group.

在文檔中 AWS Elemental MediaLive (頁 122-132)

相關文件