# Creating an HLS output group
When you create a AWS Elemental MediaLive channel, you might want to include an HLS output group. For information about the use cases for an HLS output group, see [Containers, protocols, and downstream systems](outputs-supported-containers-downstream-systems.md). For information about choosing between an HLS and MediaPackage output group, see [Choosing between the HLS output group and MediaPackage output group](hls-choosing-hls-vs-emp.md).
**Topics**
+ [Organize encodes in an HLS output group](design-hls-package.md)
+ [Coordinate with the downstream system](hls-opg-coordinate-dss.md)
+ [Create an HLS output group](creating-hls-output-group.md)
# Organize encodes in an HLS output group
An HLS output group is typically set up as a video ABR stack. A video ABR stack is an output group that contains the following:
+ More than one outputs.
Each output can contain the following:
+ One video encode (rendition). Typically, each video encode is a different resolution.
+ One or more audio encodes.
+ One or more captions encodes. The captions are either embedded or sidecar.
There are two ways to organize the encodes, depending on whether the audio encodes must be bundled or each in their own rendition. You should have already [obtained this information](identify-dss-video-audio.md) from your downstream system.
**Downstream players that require bundled audio**
Plan for the output group to contain the following:
+ One output for each video encode. This output holds one video encode, all the audio encodes, and all the captions encodes (if the captions are embedded).
The same audio encodes will appear in each output. For example, the English and French encodes will appear in the high-resolution output, then the same English and French encodes will appear in the low-resolution output.
+ One output for each captions encode, if the captions are sidecars.
This diagram illustrates an HLS output group when the captions encodes are embedded.
![\[Output group diagram showing embedded and non-embedded outputs with associated elements.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/output11-ABR-2Ve-2A.png)
This diagram illustrates an HLS output group when the captions encodes are sidecars.
![\[Output group diagram showing V, A, A components, V, A, A outputs, and two C outputs.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/output12-ABR-2V-2A-2C.png)
**Downstream players that require separate audio**
Plan for the output group to contain the following:
+ One output for each video encode. This output holds one video and all the captions encodes (if the captions are embedded).
+ One output for each audio encode.
The audio encodes might be for different languages, or they might be for different bitrates, or they might be for different languages and bitrates.
+ One output for each captions encode, if the captions are sidecars.
The arrangement of the audio encodes in this output group is called an *audio rendition group*.
This diagram illustrates an HLS output group with an audio rendition group, and with embedded captions encodes.
![\[Output group diagram showing four outputs: two marked as embedded, and two marked as A.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/output13-ABR-2Ve-2Asep.png)
This diagram illustrates an HLS output group for an ABR stack with an audio rendition group, and with sidecar captions encodes.
![\[Output group diagram showing six outputs: two V, two A, and two C, arranged in a row.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/output14-ABR-2V-2Asep-2C.png)
# Coordinate with the downstream system
The HLS output group in AWS Elemental MediaLive supports several types of downstream systems. Read the information that applies to the system you are working with.
**Topics**
+ [HLS output group to Amazon S3](origin-server-hls-s3.md)
+ [HLS output group to MediaStore](origin-server-ems.md)
+ [HLS output group to MediaPackage](origin-server-hls-emp.md)
+ [HLS output group to MediaPackage v2](origin-server-hls-empv2.md)
+ [HLS output group to HTTP](origin-server-http.md)
# HLS output group to Amazon S3
Follow this procedure if you [determined](identify-downstream-system.md) 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.
**To arrange setup of the destination**
1. Decide if you need two destinations for the output:
+ You need two destinations in a [standard channel](plan-redundancy.md).
+ You need one destination in a single-pipeline channel.
1. We recommend that you design the full path of the destination — the Amazon S3 bucket and all the folders. See [Design the path for the output destination](hls-destinations-design-step.md).
1. Ask the Amazon S3 user to create any buckets that don't already exist.
With MediaLive, the Amazon S3 bucket name must not use dot notation, which means it mustn't use . (dot) between the words in the bucket name.
1. 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 [Controlling access to the output](#setting-dss-hls-canned-acl), after this procedure.
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 [Access requirements for the trusted entity](trusted-entity-requirements.md).
## 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-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](hls-destinations-s3-specify.md).
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](identify-downstream-system.md) 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
**To arrange setup of the destination**
1. Decide if you need two destinations for the output:
+ You need two destinations in a [standard channel](plan-redundancy.md).
+ You need one destination in a single-pipeline channel.
1. We recommend that you design the full path of the destination. See [Design the path for the output destination](hls-destinations-design-step.md).
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.
1. Ask the MediaStore user to create any containers that don't already exist.
1. 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 [Access requirements for the trusted entity](trusted-entity-requirements.md).
# HLS output group to MediaPackage
Follow this procedure if you [determined](identify-downstream-system.md) 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.
**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](plan-redundancy.md) (with two pipelines), you need only one MediaPackage channel.
1. Arrange with the MediaPackage user to set up HTTPS user credentials. You must send to MediaPackage over a secure connection.
1. 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`
The two URLs are always identical, except for the folder just before `channel`.
Make sure that you obtain the URLs (which start with `https://`), not the channel name (which starts with `arn`).
+ 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 MediaPackage v2
Follow this procedure if you [determined](hls-choosing-hls-vs-emp.md) that you will create an HLS output group, and will send to MediaPackage v2. You and the operator of the downstream system must agree about the destination for the output of the 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](plan-redundancy.md) (with two pipelines), you need only one MediaPackage channel.
1. Obtain the two URLs (input endpoints is the MediaPackage terminology) for the channel. The two URLs for a channel look like this:
`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`
The two URLs are slightly different, as shown in the examples above.
Make sure that you obtain the URLs (which start with `https://`), not the channel name (which starts with `arn`).
Note that you don't use user credentials in order to send to MediaPackage v2.
# HLS output group to HTTP
Follow this procedure if you [determined](identify-downstream-system.md) 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.
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).
**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.
1. 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**.
1. Decide if you need two destinations for the output:
+ You need two destinations in a [standard channel](plan-redundancy.md).
+ You need one destination in a single-pipeline channel.
1. Find out if the downstream system uses a secure connection. If it does, arrange with the operator to set up user credentials.
1. Find out if the downstream system requires custom paths inside the main manifests and the child manifests. For more information, see [Customizing the paths inside HLS manifests](hls-manifest-paths.md).
1. If you are setting up a [standard channel](plan-redundancy.md), find out if the downstream system supports redundant manifests. If so, decide if you want to implement this feature. For more information, see [Creating redundant HLS manifests](hls-redundant-manifests.md), and specifically [Rules for most downstream systems](hls-redundant-manif-most-systems.md) and [Rules for Akamai CDNs](hls-redundant-manif-akamai.md) for specific instructions.
1. 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 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.
1. 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.
1. 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.
1. 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.
1. 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. The downstream system doesn't need to know about the folder or file names you will use.
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/`
1. 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.
# Create an HLS output group
You create the output group and its outputs when you [create or edit a MediaLive channel](creating-a-channel-step4.md).
## The procedure
1. On the **Create channel** page, under **Output groups**, choose **Add**.
1. In the **Add output group** section, choose **HLS**, and then choose **Confirm**. More sections appear:
+ **HLS group destination** – This section contains fields for the destination of the outputs. For more information see the section for the type of downstream system:
+ [Fields for the output destination – sending to Amazon S3](hls-destinations-s3.md)
+ [Fields for the output destination – sending to MediaStore](hls-destinations-ems.md)
+ [Fields for the output destination – sending to MediaPackage](hls-destinations-emp.md)
+ [Fields for the output destination – sending to an HTTP server](hls-destinations-http.md)
+ **HLS settings** – This section contains fields for the [destination of the outputs](hls-destinations-http.md), for [resiliency](hls-other-features.md#hls-resiliency), and for [captions](hls-other-features.md#hls-captions).
+ **HLS outputs** – This section shows the single output that is added by default.
+ **Location** – This section contains fields for [customizing the paths inside the manifests](hls-manifest-paths.md).
+ **Manifest and segments** – This section contains fields for [configuring redundant manifests](hls-opg-redundant-manifest.md), for configuring the [manifest contents](hls-other-features.md#hls-manifest-contents), and for [configuring media segments](hls-other-features.md#hls-segment-fields).
+ **DRM** – This section contains fields for configuring [encryption of outputs](hls-other-features.md#hls-drm).
+ **Ad marker** – This section contains fields for setting up for [SCTE-35 ad avails](hls-other-features.md#hls-ad-markers).
+ **Captions** – This section contains fields for configuring [captions](hls-other-features.md#hls-captions).
+ **ID3** – This section contains fields for setting up for [ID3](hls-other-features.md#hls-id3).
1. If your plan includes more than one output in this output group, then in **HLS outputs**, choose **Add output** to add the appropriate number of outputs.
1. In **HLS outputs**, choose the first **Settings** link to view the sections for the first output:
+ **Output settings** – This section contains fields for the destination of the outputs. See these sections:
+ [Fields for the output destination – sending to Amazon S3](hls-destinations-s3.md)
+ [Fields for the output destination – sending to MediaStore](hls-destinations-ems.md)
+ [Fields for the output destination – sending to MediaPackage](hls-destinations-emp.md)
+ [Fields for the output destination – sending to an HTTP server](hls-destinations-http.md)
This section also contains fields for the [HLS container](hls-container.md).
+ **Stream settings** – This section contains fields for the [output streams](hls-streams-section.md) (the video, audio, and captions).
1. (Optional) Enter names for the output group and the outputs:
+ In **HLS settings**, for **Name**, enter a name for the output group. This name is internal to MediaLive; it doesn't appear in the output. For example, **Sports Curling**.
+ In the **HLS outputs** section for each output, for **Name**, enter a name for the output. This name is internal to MediaLive; it doesn't appear in the output. For example, **high resolution**.
1. To complete the other fields, see the topics listed after this procedure.
1. After you have finished setting up this output group and its outputs, you can create another output group (of any type), if your plan requires it. Otherwise, go to [Save the channel](creating-a-channel-step9.md).
**Topics**
+ [The procedure](#hls-create-procedure)
+ [Destination fields in an HLS output group](hls-destinations.md)
+ [Fields for the HLS container](hls-container.md)
+ [Fields for customizing the paths inside the manifests](hls-custom-manifests.md)
+ [Fields for redundant manifests](hls-opg-redundant-manifest.md)
+ [Fields for the video, audio, and captions streams (encodes)](hls-streams-section.md)
+ [Fields for other HLS features](hls-other-features.md)
# Destination fields in an HLS output group
The HLS output group in MediaLive supports several types of destinations. Each type has different configuration requirements.
**Topics**
+ [Fields for the output destination – sending to Amazon S3](hls-destinations-s3.md)
+ [Fields for the output destination – sending to MediaStore](hls-destinations-ems.md)
+ [Fields for the output destination – sending to MediaPackage](hls-destinations-emp.md)
+ [Fields for the output destination – sending to an HTTP server](hls-destinations-http.md)
# Fields for the output destination – sending to Amazon S3
When you [planned the destinations for the HLS output group](origin-server-hls-s3.md), you might have decided to send the output to Amazon S3. You must design the destination path or paths for the output. You must then enter the different portions of the path into the appropriate fields on the console.
**Topics**
+ [Design the path for the output destination](hls-destinations-s3-design.md)
+ [Complete the fields on the Console](hls-destinations-s3-specify.md)
# Design the path for the output destination
Perform this step if you haven't yet designed the full destination path or paths. If you've already designed the paths, go to [Complete the fields on the Console](hls-destinations-s3-specify.md).
**To design the path**
1. Collect the bucket names that you [previously obtained](origin-server-hls-s3.md) from the Amazon S3 user. For example:
`amzn-s3-demo-bucket`
1. Design the portions of the destination paths that follow the bucket or buckets. For details, see the sections that follow.
**Topics**
+ [The syntax for the paths for the outputs](#hls-syntax-s3)
+ [Designing the folders and baseFilename](#hls-path-s3)
+ [Designing the nameModifier](#hls-nameModifier-design-s3)
+ [Designing the segmentModifier](#hls-segmentModifier-design-s3)
## The syntax for the paths for the outputs
An HLS output always includes three categories of files:
+ The main manifest
+ The child manifests
+ The media files
The following table describes the parts that make up the destination paths for these three categories of files.
The destination paths for these three categories of files are identical up to and including the *baseFilename*, which means that MediaLive sends all these categories of files to the same folder. The modifiers and file extensions are different for each category of file. When sending to Amazon S3, you must send all the files to the same folder. The downstream systems expect all the files to be together.
| File | Syntax of the path | Example |
| --- | --- | --- |
| Main manifest files | protocol bucket path baseFilename extension | The path for a main manifest in the bucket *sports*, with the file name *index*:s3ssl://amzn-s3-demo-bucket/sports/delivery/curling/index.m3u8 |
| Child manifest files | protocol bucket path baseFilename nameModifier extension | The path for the child manifest for the high-resolution renditions of the curling output`s3ssl://amzn-s3-demo-bucket/sports/delivery/curling/index-high.m3u8` |
| Media files (segments) | protocol bucket path baseFilename nameModifier optionalSegmentModifier counter extension | The path for the file for the 230th segment might be:s3ssl://amzn-s3-demo-bucket/sports/delivery/curling/index-high-00230.ts |
These destination paths are constructed as follows:
+ The Amazon S3 user should have provided you with the bucket names.
+ You must determine the following:
+ The folders
+ The baseFilename
+ The modifier
+ The segmentModifier
See the sections that follow.
+ MediaLive inserts the underscore before the counter.
+ MediaLiveautomatically generates this counter. Initially, this is a five-digit number starting at 00001, and increasing by 1. So 00001, 00002, 00003 and so on. After 99999, the next number is 100000 (six digits), then 100001, 100002, and so on. Then from 999999 to 1000000 (seven digits), and so on.
+ MediaLive inserts the dot before the extension.
+ MediaLive selects the extension:
+ For manifest files – always `.m3u8`
+ For media files – .ts for files in a transport stream, or .mp4 for files in an fMP4 container
## Designing the folders and baseFilename
Design a folder path and baseFilename that suits your purposes.
If you have two destinations for each output, the destination paths must be different from each other in some way. Follow these guidelines:
+ 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.
Therefore, if the buckets are *different*, the folder path and file names for the two destinations can be different from each other, or they can be the same. For example:
`s3ssl://amzn-s3-demo-bucket/sports/delivery/curling/index-high.m3u8`
`s3ssl://amzn-s3-demo-bucket1/sports/delivery/curling/index-high.m3u8`
or
`s3ssl://amzn-s3-demo-bucket/sports/delivery/curling/index-high.m3u8`
`s3ssl://amzn-s3-demo-bucket1/sports/redundant/curling/index-high.m3u8`
+ If the buckets are *the same*, the folder path and file names for the two destinations must be different from each other. For example:
`s3ssl://amzn-s3-demo-bucket/sports/delivery/curling/index-high.m3u8`
`s3ssl://amzn-s3-demo-bucket/sports/redundant/curling/index-high.m3u8`
## Designing the nameModifier
Design the `nameModifier` portions of the file name. The child manifests and media files include this modifier in their file names. This `nameModifier` distinguishes each output from the other, so it must be unique in each output. Follow these guidelines:
+ For an output that contains video (and possibly other streams), you typically describe the video. For example, **-high** or **-1920x1080-5500kpbs** (to describe the resolution and the bitrate).
+ For an output that contains only audio or only captions, you typically describe the audio or captions. For example, **-aac** or **-webVTT**.
+ It’s a good idea to start the `nameModifier` with a delimiter, such as a hyphen, in order to separate the` baseFilename` from the `nameModifier`.
+ The `nameModifier` can include [data variables](variable-data-identifiers.md).
## Designing the segmentModifier
Design the segmentModifiers portion of the destination path. The segmentModifier is optional, and if you include it, only the media file names include it.
A typical use case for this modifier is to use a data variable to create a timestamp, to prevent segments overriding each other if the channel restarts. For example, assume that you include the timestamp **\$1t\$1-**. Segment 00001 might have the name `index-120028-00001`. If the output restarts a few minutes later (which causes the segment counter to restart), the new segment 00001 will have the name `index-120039-00001`. The new file won't overwrite the file for the original segment 00001. Some downstream systems might prefer this behavior.
# Complete the fields on the Console
After you have designed the output names and destination paths, you can set up the HLS output group.
The following fields configure the location and names of the HLS media and manifest files (the destination).
+ **Output group – HLS group destination** section
+ **Output group – HLS settings – CDN** section
+ **Output group – Location – Directory structure **
+ **Output group – Location – Segments per subdirectory**
+ **HLS outputs – Output settings – Name modifier**
+ **HLS outputs – Output settings – Segment modifier**
**To set the destination for most downstream systems**
1. Complete the **URL** fields in the **HLS group destinations** section. Specify two destinations if the channel is set up as a standard channel, or one destination if it is set up as a single-pipeline channel.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/hls-destinations-s3-specify.html)
1. Leave the **Credentials** section blank in both the **HLS group destinations** sections. 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 [Access requirements for the trusted entity](trusted-entity-requirements.md).
1. In the **CDN** settings section, choose `Hls S3`.
1. Complete the **CDN settings** field only if MediaLive must set a canned ACL whenever it sends this output to the Amazon S3 bucket.
Use of a canned ACL typically only applies if your organization is not the owner of the Amazon S3 bucket. You should have discussed the use of a canned ACL with the bucket owner when you discussed the [destination for the output](origin-server-hls-s3.md#setting-dss-hls-canned-acl).
# Fields for the output destination – sending to MediaStore
When you [planned the destinations for the HLS output group](origin-server-ems.md), you might have decided to send the output to MediaStore. You must design the destination path or paths for the output. You must then enter the different portions of the path into the appropriate fields on the console.
**Topics**
+ [Design the path for the output destination](hls-destinations-ems-design.md)
+ [Complete the fields on the console](hls-specify-destination-ems.md)
# Design the path for the output destination
Perform this step if you haven't yet designed the full destination path or paths. If you've already designed the paths, go to [Complete the fields on the console](hls-specify-destination-ems.md).
**To design the path**
1. Collect the data endpoint for the container or containers. You [previously obtained](origin-server-ems.md) this information from the MediaStore user. For example:
`a23f.data.mediastore.us-west-2.amazonaws.com`
1. Design the portions of the destination paths that follow the data endpoint (for MediaStore).
**Topics**
+ [The syntax for the paths for the outputs](#hls-syntax-ems)
+ [How MediaLive constructs the paths](#hls-how-construct-urls-ems)
+ [Designing the folders and baseFilename](#hls-path-ems)
+ [Designing the nameModifier](#hls-nameModifier-design-ems)
+ [Designing the segmentModifier](#hls-segmentModifier-design-ems)
## The syntax for the paths for the outputs
An HLS output always includes three categories of files:
+ The main manifest
+ The child manifests
+ The media files
The following table describes the parts that make up the destination paths for these three categories of files.
The destination paths for these three categories of files are identical up to and including the *baseFilename*, which means that MediaLive sends all these categories of files to the same folder. The modifiers and file extensions are different for each category of file. When sending to MediaStore, you must send all the files to the same folder. The downstream systems expect all the files to be together.
| File | Syntax of the path | Example |
| --- | --- | --- |
| Main manifest files | protocol dataEndpoint path baseFilename extension | The path for a main manifest in the path *delivery* in the container, and with the file name *index*:mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8 |
| Child manifest files | protocol dataEndpoint path baseFilename nameModifier extension | The path for the child manifest for the high-resolution renditions of the output`mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index-high.m3u8` |
| Media files (segments) | protocol dataEndpoint path baseFilename nameModifier optionalSegmentModifier counter extension | The path for the file for the 230th segment might be:mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index-high-00230.ts |
## How MediaLive constructs the paths
These paths are constructed as follows:
+ The user of the AWS service should have provided you with the container names.
+ For MediaStore, you must determine the following:
+ The folders
+ The baseFilename
+ The modifier
+ The segmentModifier
See the sections that follow.
+ MediaLive inserts the underscore before the counter.
+ MediaLive generates the counter, which is always five digits starting at 00001.
+ MediaLive inserts the dot before the extension.
+ MediaLive selects the extension:
+ For manifest files – always` .m3u8`
+ For media files – .ts for files in a transport stream, or .mp4 for files in an fMP4 container
## Designing the folders and baseFilename
Design a folder path and baseFilename that suits your purposes.
If you have two destinations for each output, the destination paths must be different from each other in some way. Follow these guidelines:
+ 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.
Therefore, if the buckets or containers are different, the folder path and file names for the two destinations can be different from each other, or they can be the same. For example:
`mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8`
`mediastoressl://fe30.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8`
or
`mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8`
`mediastoressl://fe30.data.mediastore.us-west-2.amazonaws.com/redundant/index.m3u8`
+ If the buckets or containers are the same, the folder path and file names for the two destinations must be different from each other. For example:
`mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8`
`mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/redundant/index.m3u8`
## Designing the nameModifier
Design the `nameModifier` portions of the file name. The child manifests and media files include this modifier in their file names. This `nameModifier` distinguishes each output from the other, so it must be unique in each output. Follow these guidelines:
+ For an output that contains video (and possibly other streams), you typically describe the video. For example, **-high** or **-1920x1080-5500kpbs** (to describe the resolution and the bitrate).
+ For an output that contains only audio or only captions, you typically describe the audio or captions. For example, **-aac** or **-webVTT**.
+ It’s a good idea to start the `nameModifier` with a delimiter, such as a hyphen, in order to separate the` baseFilename` from the `nameModifier`.
+ The `nameModifier` can include [data variables](variable-data-identifiers.md).
## Designing the segmentModifier
Design the segmentModifiers portion of the destination path. The segmentModifier is optional, and if you include it, only the media file names include it.
A typical use case for this modifier is to use a data variable to create a timestamp, to prevent segments overriding each other if the channel restarts. For example, assume that you include the timestamp **\$1t\$1-**. Segment 00001 might have the name `index-120028-00001`. If the output restarts a few minutes later (which causes the segment counter to restart), the new segment 00001 will have the name `index-120039-00001`. The new file won't overwrite the file for the original segment 00001. Some downstream systems might prefer this behavior.
# Complete the fields on the console
After you have designed the output names and destination paths, you can set up the HLS output group.
The following fields configure the location and names of the HLS media and manifest files (the destination).
+ **Output group – HLS group destination** section
+ **Output group – HLS settings – CDN** section
+ **Output group – Location – Directory structure **
+ **Output group – Location – Segments per subdirectory**
+ **HLS outputs – Output settings – Name modifier**
+ **HLS outputs – Output settings – Segment modifier**
**To set the destination for most downstream systems**
1. Complete the **URL** fields in the **HLS group destinations** section. Specify two destinations if the channel is set up as a standard channel, or one destination if it is set up as a single-pipeline channel.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/hls-specify-destination-ems.html)
1. Leave the **Credentials** section blank in both the **HLS group destinations** sections. 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 [Access requirements for the trusted entity](trusted-entity-requirements.md).
1. In the **CDN** settings section, choose `Hls media store`.
1. If the MediaStore user gave you values to [configure the connection](origin-server-http.md), enter those values in the fields in the **CDN** settings section.
# Fields for the output destination – sending to MediaPackage
When you [planned the output to MediaPackage](hls-choosing-hls-vs-emp.md), you might have decided to send the output by creating an HLS output group. (Or you might have decided to create a [MediaPackage output group](creating-mediapackage-output-group.md).)
You must design the destination path or paths for the output. You must then enter the different portions of the path into the appropriate fields on the console.
You can use an HLS output group to send to standard MediaPackage or toMediaPackage v2. The two versions use different protocols:
+ MediaPackage uses WebDAV.
+ MediaPackage v2 uses Basic PUT.
**Topics**
+ [Design the path for the output destination](hls-destinations-emp-design.md)
+ [Complete the fields on the console](hls-specify-destination-emp.md)
+ [Standard MediaPackage example](hls-example-mediapackage.md)
+ [MediaPackage v2 example](hls-example-mediapackage-v2.md)
# Design the path for the output destination
Perform this step if you haven't yet designed the full destination path or paths. If you've already designed the paths, go to [Complete the fields on the console](hls-specify-destination-emp.md).
**To design the path**
1. Collect the information you [previously obtained](origin-server-hls-emp.md) from the MediaPackage user:
+ The two URLs (input endpoints is the MediaPackage terminology) for the channel. See the information after this procedure.
+ If you are using standard MediaPackage, obtain the user name and password. If you are using MediaPackage v2, you don't use user credentials.
1. You must design the portions of the destination paths that follow the URLs.
**Topics**
+ [Collect the information for standard MediaPackage](hls-destinations-emp-info.md)
+ [Collect the information for MediaPackage v2](hls-destinations-emp-info-v2.md)
+ [The syntax for the paths for the outputs](hls-syntax-emp.md)
+ [Designing the nameModifier](hls-nameModifier-design-emp.md)
+ [Designing the segmentModifier](hls-segmentModifier-design-emp.md)
# Collect the information for standard MediaPackage
For standard MediaPackage, the two URLs for a channel look like these examples:
`6d2c.mediapackage.us-west-2.amazonaws.com/in/v2/9dj8/9dj8/channel`
`6d2c.mediapackage.us-west-2.amazonaws.com/in/v2/9dj8/e333/channel`
Where:
`mediapackage` indicates that the input endpoints uses version 1 of the MediaPackage API
`channel` always appears at the end of the URL. It is the base filename for all the files for this destination.
The two URLs are always identical except for the folder just before `channel`.
# Collect the information for MediaPackage v2
For MediaPackage v2, the two URLs for a channel look like these examples:
`mz82o4-1.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/1/curling/index`
`mz82o4-2.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/2/curling/index`
Where:
| Element | Description |
| --- | --- |
| mz82o4-1 and mz82o4-2 | Indicate that the two endpoints are for a redundant channel in MediaPackage. The prefixes are always -1 and -2 |
| mediapackagev2 | Indicates that the input endpoints uses version 2 of the MediaPackage API |
| live-sports/1/curling and live-sports/2/curling | Folders for the redundant ingests. One folder always includes /1/, and the other folder always includes /2/ |
| index | Always appears at the end of the URL. It is the base filename for all the files for this destination. |
# The syntax for the paths for the outputs
An HLS output always includes three categories of files:
See the following sections.
+ The main manifest
+ The child manifests
+ The media files
The following table describes the parts that make up the destination paths for these three categories of files.
The destination paths for these three categories of files are identical up to and including the *baseFilename*, which means thatMediaLive sends all these categories of files to the same folder. The modifiers and file extensions are different for each category of file. When sending to MediaPackage, you must send all the files to the same folder. The downstream systems expect all the files to be together.
| File | Syntax of the path | Example |
| --- | --- | --- |
| Main manifest files | protocol channelURL extension | The path for output. Here is an example that uses MediaPackage v2 `https://mz82o4-2.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/2/curling/index.m3u8` |
| Child manifest files | protocol channelURL nameModifier extension | Here is an example for the path for the child manifest for the high-resolution renditions of the curling output (in a destination that uses MediaPackage v2):`https://mz82o4-1.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/1/curling/index-high.m3u8` |
| Media files (segments) | protocol channelURL nameModifier optionalSegmentModifier counter extension | Here is an example for the path for the file for the 230th segment (in a destination that uses MediaPackage v2):https://mz82o4-1.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/1/curling/index-high-00230.ts |
These paths are constructed as follows:
+ The MediaPackage user should have provided you with the channel URLs. The URLs cover the portion of the path up to and including the baseFilename:
+ With standard MediaPackage, the baseFilename is always `channel`.
+ With MediaPackage v2, the baseFilename is always `index`.
+ You must specify the following:
+ The modifier
+ The segmentModifier
See the sections that follow.
+ MediaLive inserts the underscore before the counter.
+ MediaLive generates the counter, which is always five digits starting at 00001.
+ MediaLive inserts the dot before the extension.
+ MediaLive selects the extension:
+ For manifest files – always` .m3u8`
+ For media files – .ts for files in a transport stream, or .mp4 for files in an fMP4 container
# Designing the nameModifier
Design the `nameModifier` portions of the file name. The child manifests and media files include this modifier in their file names.
This `nameModifier` distinguishes each output from the other, so it must be unique in each output.
+ For an output that contains video (and possibly other streams), you typically describe the video. For example, if you have three renditions, you might use **-high**, **-medium** and **-low**. Or each modifier could accurately describe the resolution and the bitrate (**-1920x1080-5500kpbs**).
+ For an output that contains only audio or only captions, you typically describe the audio or captions. For example, **-aac** or **-webVTT**.
It’s a good idea to start the `nameModifier` with a delimiter, such as a hyphen, in order to separate the` baseFilename` from the `nameModifier`.
The `nameModifier` can include [data variables](variable-data-identifiers.md).
# Designing the segmentModifier
Design the segmentModifiers portion of the destination path. The segmentModifier is optional, and if you include it, only the media file names include it.
A typical use case for this modifier is to use a data variable to create a timestamp, to prevent segments overriding each other if the channel restarts. For example, assume that you include the timestamp **\$1t\$1-**. Segment 00001 might have the name `index-120028-00001`. If the output restarts a few minutes later (which causes the segment counter to restart), the new segment 00001 will have the name `index-120039-00001`. The new file won't overwrite the file for the original segment 00001. Some downstream systems might prefer this behavior.
# Complete the fields on the console
After you have designed the output names and destination paths, you can set up the HLS output group.
The following fields configure the location and names of the HLS media and manifest files (the destination).
+ **Output group – HLS group destination** section
+ **Output group – HLS settings – CDN** section
+ **Output group – Location – Directory structure **
+ **Output group – Location – Segments per subdirectory**
+ **HLS outputs – Output settings – Name modifier**
+ **HLS outputs – Output settings – Segment modifier**
**To set the destination**
1. Complete the **URL** fields in the **HLS group destinations** section. Specify two destinations if the channel is set up as a standard channel, or one destination if it is set up as a single-pipeline channel.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/hls-specify-destination-emp.html)
1. Enter the input user name. For the password (if applicable), enter the name of the password stored on the AWS Systems Manager Parameter Store. Don't enter the password itself. For more information, see [Requirements for AWS Systems Manager password parameters](requirements-for-EC2.md).
1. In the **CDN** settings section, choose the appropriate connection type:
+ To send to standard MediaPackage, choose `Hls webdav`.
+ To send to MediaPackage v2, choose `Basic PUT`.
1. If the downstream system gave you values to [configure the connection](origin-server-http.md), enter those values in the fields in the **CDN** settings section.
# Standard MediaPackage example
This example shows how to set up the destination fields if the downstream system for the HLS output group is standard MediaPackage.
Assume that you want to stream the curling game and to create three outputs: high, medium, and low bitrate.
| Field | Value |
| --- | --- |
| CDN settings in HLS settings section | hls webdav |
| URL in HLS group destination A section | 6d2c.mediapackage.us-west-2.amazonaws.com/in/v2/9dj8/9dj8/channel |
| Credentials in HLS group destination A section | MediaPackage accepts only authenticated requests, so you must enter a user name and a password that is known to MediaPackage. For the password, enter the name of the password stored on the AWS Systems Manager Parameter Store. Don't enter the password itself. For more information, see [Requirements for AWS Systems Manager password parameters](requirements-for-EC2.md). |
| URL in HLS group destination B section | 6d2c.mediapackage.us-west-2.amazonaws.com/in/v2/9dj8/e333/channel |
| Credentials in HLS group destination B section | Enter a user name and password for the URL for destination B. The credentials are probably the same for both URLs, but they might not be. |
| Name modifier in HLS outputs section | Choose **Add output** twice: two more **Output** lines are added to this section, for a total of three lines. In each line, enter a modifier: **-high**, **-medium**, and **-low**. |
| Directory Structure and Segments Per Subdirectory in Location section | MediaPackage doesn't use these fields, therefore leave them blank. |
As a result, files are created with the following names:
+ One main manifest: **channel.m3u8**
+ One child manifest for each output: **channel-high.m3u8**, **channel-medium.m3u8**, **channel-low.m3u8**
+ TS files for each output:
+ **channel-high-00001.ts**, **channel-high-00002.ts**, **channel-high-00003.ts**, and so on
+ **channel-medium-00001.ts**, **channel-medium-00002.ts**, **channel-medium-00003.ts**, and so on
+ **channel-low-00001.ts**, **channel-low-00002.ts**,** channel-low-00003.ts**, and so on
The files will be published to both URL inputs on MediaPackage.
# MediaPackage v2 example
This example shows how to set up the destination fields if the downstream system for the HLS output group is standard MediaPackage.
Assume that you want to stream the curling game and to create three outputs: high, medium, and low bitrate.
| Field | Value |
| --- | --- |
| CDN settings in HLS settings section | **basic PUT** |
| URL in HLS group destination A section | mz82o4-1.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/1/curling/index |
| Credentials in HLS group destination A section | Leave blank. MediaPackage v2 doesn't use credentials to authenticate. |
| URL in HLS group destination B section | mz82o4-2.ingest.hnycui.mediapackagev2.us-west-2.amazonaws.com/in/v1/live-sports/2/curling/index. |
| Credentials in HLS group destination B section | Leave blank. MediaPackage v2 doesn't use credentials to authenticate. |
| Name modifier in HLS outputs section | Choose **Add output** twice: two more **Output** lines are added to this section, for a total of three lines. In each line, enter a modifier: **-high**, **-medium**, and **-low**. |
| Directory Structure and Segments Per Subdirectory in Location section | MediaPackage doesn't use these fields, therefore leave them blank. |
As a result, files are created with the following names:
+ One main manifest: **index.m3u8**
+ One child manifest for each output: **index-high.m3u8**, **index-medium.m3u8**, **index-low.m3u8**
+ TS files for each output:
+ **index-high-00001.ts**, **index-high-00002.ts**, **index-high-00003.ts**, and so on
+ **index-medium-00001.ts**, **index-medium-00002.ts**, **index-medium-00003.ts**, and so on
+ **index-low-00001.ts**, **index-low-00002.ts**,** index-low-00003.ts**, and so on
The files will be published to both URL inputs on MediaPackage.
# Fields for the output destination – sending to an HTTP server
When you [planned the destinations for the HLS output group](origin-server-http.md), you might have decided to send the output to an HTTP server.
You must design the destination path or paths for the output. You must then enter the different portions of the path into the appropriate fields on the console.
**Topics**
+ [Design the path for the output destination](hls-destinations-design-step.md)
+ [Complete the fields on the console](hls-specify-destination.md)
+ [Example for an HTTP or HTTPS server](hls-example-most-downstreamsystems.md)
+ [Akamai example](hls-example-akamai.md)
# Design the path for the output destination
Perform this step if you haven't yet designed the full destination path or paths. If you've already designed the paths, go to [Complete the fields on the console](hls-specify-destination.md).
**To design the path**
1. Collect the information that you [previously obtained](origin-server-http.md) from the operator of the downstream system:
+ The connection type for the downstream system – Akamai, basic 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.
1. As part of the planning with the operator of the downstream system, you should have determined if you want to implement redundant manifests. You should also have determined if the downstream system requires custom manifests. Given these two decisions, read the appropriate section:
+ If you are implementing redundant manifests, see [Creating redundant HLS manifests](hls-redundant-manifests.md), then return to this section.
+ If you are implementing custom paths for manifests, see [Customizing the paths inside HLS manifests](hls-manifest-paths.md), then return to this section.
+ If you are not implementing either of those features, continue keep reading this section.
1. Design the portions of the destination paths that follow the bucket or buckets. For details, see the sections that follow.
**Topics**
+ [The syntax for the paths for the outputs](#hls-syntax-http)
+ [Designing the folders and baseFilename](#hls-baseFilename-design)
+ [Designing the nameModifier](#hls-nameModifier-design)
+ [Designing the segmentModifier](#hls-segmentModifier-design)
## The syntax for the paths for the outputs
The following table describes the parts that make up the destination paths for these three categories of files.
The destination paths for these three categories of files are identical up to and including the *baseFilename*, which means thatMediaLive sends all these categories of files to the same folder. The modifiers and file extensions are different for each category of file.
| File | Syntax of the path | Example |
| --- | --- | --- |
| Main manifest files | protocol domain path baseFilename extension | The URL for a main manifest with the file name */index*:http://203.0.113.55/sports/delivery/curling/index.m3u8 |
| Child manifest files | protocol domain path baseFilename nameModifier extension | The URL for the child manifest for the high-resolution renditions of the output`http://203.0.113.55/sports/delivery/curling/index-high.m3u8` |
| Media files (segments) | protocol domain path baseFilename nameModifier optionalSegmentModifier counter extension | The URL for the file for the 230th segment might be:http:// 203.0.113.55/sports/delivery/curling/index-high-00230.ts |
These destination paths are constructed as follows:
+ The operator at the downstream system [should have provided you](origin-server-http.md) with the protocol, domain and part of the path. For example:
`http://203.0.113.55/sports/`
The protocol is always HTTP or HTTPS.
+ The operator might have provided the following. Otherwise, you decide them:
+ The folders
+ The baseFilename
+ The modifier
+ The segmentModifier
See the sections that follow.
+ MediaLive inserts the underscore before the counter.
+ MediaLive generates the counter, which is always five digits starting at 00001.
+ MediaLive inserts the dot before the extension.
+ MediaLive selects the extension:
+ For manifest files – always` .m3u8`
+ For media files – `.ts` for files in a transport stream, and `.mp4` for files in an fMP4 container
## Designing the folders and baseFilename
For the `folder` and `baseFilename` portion of the destination path, follow these guidelines:
+ For a single-pipeline channel, you need only one `baseFilename`.
+ For a standard channel when you are *not *implementing [redundant manifests](hls-opg-redundant-manifest.md), you need two `baseFilenames`. The two `baseFilenames` can be identical or different. Before you create different `baseFilenames`, make sure that the downstream system can work with that setup.
+ For a standard channel when you *are* implementing redundant manifests, see [Fields for redundant manifests](hls-opg-redundant-manifest.md).
## Designing the nameModifier
Design the `nameModifier` portions of the file name. The child manifests and media files include this modifier in their file names. This `nameModifier` distinguishes each output from the other, so it must be unique in each output. Follow these guidelines:
+ For an output that contains video (and possibly other streams), you typically describe the video. For example, **-high** or **-1920x1080-5500kpbs** (to describe the resolution and the bitrate).
+ For an output that contains only audio or only captions, you typically describe the audio or captions. For example, **-aac** or **-webVTT**.
+ It’s a good idea to include a delimiter, to clearly separate the` baseFilename` from the `nameModifier`.
+ The` nameModifier` can include [data variables](variable-data-identifiers.md).
## Designing the segmentModifier
Design the segmentModifiers portion of the destination path. The segmentModifier is optional, and if you include it, only the media file names include it.
A typical use case for this modifier is to use a data variable to create a timestamp, to prevent segments overriding each other if the channel restarts. For example, assume that you include the timestamp **\$1t\$1-**. Segment 00001 might have the name `/index-120028-00001`. If the output restarts a few minutes later (which causes the segment counter to restart), the new segment 00001 will have the name `/index-120039-00001`. The new file won't overwrite the file for the original segment 00001. Some downstream systems might prefer this behavior.
# Complete the fields on the console
The following fields configure the location and names of the HLS media and manifest files (the destination).
+ **Output group – HLS group destination** section
+ **Output group – HLS settings – CDN** section
+ **Output group – Location – Directory structure **
+ **Output group – Location – Segments per subdirectory**
+ **HLS outputs – Output settings – Name modifier**
+ **HLS outputs – Output settings – Segment modifier**
**To set the destination**
1. Complete the **URL** fields in the **HLS group destinations** section. Specify two destinations if the channel is set up as a standard channel, or one destination if it is set up as a single-pipeline channel.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/hls-specify-destination.html)
1. If the downstream system requires user authentication from MediaLive, in each **HLS group destination** section, complete the **Credentials** section. Enter a user name and a password provided by the downstream system. For the password, enter the name of the password stored on the AWS Systems Manager Parameter Store. Don't enter the password itself. For more information, see [Requirements for AWS Systems Manager password parameters](requirements-for-EC2.md).
1. In the **CDN** settings section, choose the option that the downstream system told you to use—Akamai, PUT, or WebDAV.
1. If the downstream system gave you values to [configure the connection](origin-server-http.md), enter those values in the fields in the **CDN** settings section.
# Example for an HTTP or HTTPS server
This example shows how to set up the destination fields if the downstream system is an HTTPS server that uses basic PUT.
Assume that you want to stream the curling game and to create three outputs: high, medium, and low bitrate.
| Field | Value |
| --- | --- |
| CDN settings in HLS settings section | Hls basic putChange the other CDN fields according to the instructions from the downstream system. |
| URL in HLS group destination A section | For example:**https://203.0.113.55/sports/curling/index** |
| Credentials in HLS group destination A section | If the downstream system requires authenticated requests, enter the user name provided by the downstream system. For the password, enter the name of the password stored on the AWS Systems Manager Parameter Store. Don't enter the password itself. For more information, see [Requirements for AWS Systems Manager password parameters](requirements-for-EC2.md). |
| URL in HLS group destination B section | For example:**https://203.0.113.82/sports/curling/index** |
| Credentials in HLS group destination B section | Enter a user name and password for the URL for destination B, if applicable. The credentials are probably the same for both URLs, but they might not be. |
| Name modifier in HLS outputs section | Choose **Add output** twice: two more **Output** lines are added to this section, for a total of three lines. In each line, enter a modifier: **-high**, **-medium**, and **-low**. |
| Directory Structure and Segments Per Subdirectory in Location section | Assume that the downstream system doesn't use these fields. |
As a result, files are created with the following names:
+ One main manifest: `index.m3u8`
+ One child manifest for each output: `index-high.m3u8`, `index-medium.m3u8`, `index-low.m3u8`
+ TS files for each output:
+ `index-high-00001.ts`, `index-high-00002.ts`, `index-high-00003.ts`, and so on
+ `index-medium-00001.ts`, `index-medium-00002.ts`, `index-medium-00003.ts`, and so on
+ `index-low-00001.ts`, `index-low-00002.ts`, ` index-low-00003.ts`, and so on
The files will be published to two hosts at the downstream system, and in a folder called `sports` on each host.
# Akamai example
This example shows how to set up the destination fields if the downstream system is an Akamai server.
Assume that you want to stream the curling game and to create three outputs: high, medium, and low bitrate.
| Field | Value |
| --- | --- |
| CDN settings in HLS settings section | HLS akamai Select this setting if you are using Akamai Token Authentication. Change the other CDN fields according to the instructions from Akamai.HLS basic put Select this setting if you are using digest authentication. Change the other CDN fields according to the instructions from Akamai. |
| URL in HLS group destination A section | For example:**https://p-ep50002.i.akamaientrypoint.net/50002/curling/index**Mapping this URL to the Akamai terminology: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/hls-example-akamai.html) |
| Credentials in HLS group destination A section | If Akamai requires authenticated requests, enter a user name and a password that is known to Akamai. For the password, enter the name of the password stored on the AWS Systems Manager Parameter Store. Don't enter the password itself. For more information, see [Requirements for AWS Systems Manager password parameters](requirements-for-EC2.md). |
| URL in HLS group destination B section | For example:**https://b-ep50002.i.akamaientrypoint.net/50002-b/curling/index**Mapping this URL to the Akamai terminology: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/hls-example-akamai.html) |
| Credentials in HLS group destination B section | Enter a user name and password for the URL for the other destination, if applicable. The credentials are probably the same for both URLs, but they might not be. |
| Name modifier in HLS outputs section | Choose **Add output** twice: two more **Output** lines are added to this section, for a total of three lines. In each line, enter a modifier: **-high**, **-medium**, and **-low**. |
| Directory Structure and Segments Per Subdirectory in Location section | Complete the fields according to the instructions from Akamai. |
As a result, files are created with the following names:
+ One main manifest: **index.m3u8**
+ One child manifest for each output: **index-high.m3u8**, **index-medium.m3u8**, **index-low.m3u8**
+ TS files for each output:
+ `index-high-00001.ts`, `index-high-00002.ts`, `index-high-00003.ts`, and so on
+ `index-medium-00001.ts`, `index-medium-00002.ts`, `index-medium-00003.ts`, and so on
+ `index-low-00001.ts`, `index-low-00002.ts`,` index-low-00003.ts`, and so on
The files will be published to two places:
+ On the Akamai host **p-ep50002.i.akamaientrypoint.net** in a folder called **50002**
+ On the host **b-ep50002.i.akamaientrypoint.net** in a folder called **50002-b**
# Fields for the HLS container
The following fields configure the container in each output.
+ **HLS outputs** –** Output settings **– **HLS settings** section
These fields control the content of the manifest and structure of the segments. By comparison, fields described in [Fields for contents of manifests](hls-other-features.md#hls-manifest-contents) control how many manifests and segments are in the output.
**To configure the container**
1. In **HLS Settings**, choose the appropriate option. For information on the options, see the list after this procedure.
1. For **Standard hls**, more fields appear. Choose **Transport/container configuration** and **PID settings**. More fields appear.
1. Change any fields. Typically, you change the fields in these two sections only if the downstream system provides you with values.
**About HLS containers**
MediaLive supports these types of containers:
+ **Standard hls** – Choose this type of container if you want to package the streams (encodes) in a transport stream (TS). Choose this container type for all the outputs in the output group (except for outputs that are part of an audio rendition group). Each output might contain these encodes:
+ One video encode
+ One video encode with embedded captions
+ One video encode (and optionally embedded captions) and one or more audio encodes
+ One captions encode
+ **Fmp4 hls** – Choose this type of container if you want to package the streams (encodes) as fragmented MP4. Choose this container type for all the outputs in the output group (except for outputs that are part of an audio rendition group). Each output might contain these encodes:
+ One video encode
+ One video encode with embedded captions
+ One captions encode
+ **Audio-only** – Choose this type of container for each audio-only output that is part of an audio rendition group. The rendition group can be part of a TS (transport stream) or part of an fMP4 package. For information about creating an audio rendition group, see [Audio rendition groups for HLS](audio-renditions.md).
+ **Frame capture** – Choose this type of container to create a JPEG file of frame captures in the output group. This container is used to implement trick-play. For more information about this feature and for instructions on setting it up in the channel, see [Trick-play track via the Image Media Playlist specification](trick-play-roku.md).
# Fields for customizing the paths inside the manifests
Inside the main manifest, there are paths to each child manifest. Inside each child manifest, there are paths to the media files for that manifest.
You can optionally change the syntax of these paths. Typically, you only need to change the syntax if the downstream system has special path requirements.
The following fields relate to custom paths inside the manifests:
+ **HLS output group – Location** – the **Base URL content** fields.
+ **HLS output group – Location** – the **Base URL manifest** fields.
For more information about setting up custom paths in manifests, see [Customizing the paths inside HLS manifests](hls-manifest-paths.md).
# Fields for redundant manifests
MediaLive supports redundant manifests as specified in the HLS specification. You can enable this feature in a standard channel.
The following fields relate to redundant manifests:
+ **HLS output group – Manifests and Segments – Redundant manifests** field
+ **HLS output group – Location – the Base URL manifest** fields
+ **HLS output group – Location – the Base URL content** fields
You can’t enable this feature in an HLS output group that has MediaPackage as the downstream system.
For more information about setting up for redundant manifests, see [Creating redundant HLS manifests](hls-redundant-manifests.md).
# Fields for the video, audio, and captions streams (encodes)
The following fields relate to the encoding of the video, audio, and captions encodes in each output.
+ **Stream settings** section
For information about creating encodes, see the following sections:
+ [Set up the video encode](creating-a-channel-step6.md)
+ [Set up the audio encodes](creating-a-channel-step7.md)
+ [Set up the captions encodes](creating-a-channel-step8.md)
# Fields for other HLS features
**Topics**
+ [Fields for connection retries](#hls-reconnection-fields)
+ [Fields for contents of manifests](#hls-manifest-contents)
+ [Fields for segments](#hls-segment-fields)
+ [Fields for resiliency](#hls-resiliency)
+ [Fields for DRM](#hls-drm)
+ [Fields for SCTE-35 ad avails](#hls-ad-markers)
+ [Fields for captions](#hls-captions)
+ [Fields for ID3 metadata](#hls-id3)
## Fields for connection retries
The following fields in the **Output group – HLS settings – CDN settings** section configure the behavior for reconnecting to the downstream system:
+ **Connection retry interval**
+ **Num retries**
+ **Filecache duration**
+ **Restart delay**
For details about a field, choose the **Info** link next to the field in the MediaLive console.
## Fields for contents of manifests
The following fields in the **HLS output group – Manifests and Segments** section configure the information to include in the HLS child manifests:
+ **Output selection**
+ **Mode**
+ **Stream inf resolution**
+ **Manifest duration format**
+ **Num segments**
+ **I-frame only playlists** – This field is used to implement trick-play via I-frames. For more information, see [Trick-play track via I-frames](trick-play-i-frames.md).
+ **Program date time (PDT)** – This field is used to include or exclude the `EXT-X-PROGRAM-DATE-TIME` tag in manifest files. The tag information helps downstream players to synchronize the stream to the source that's selected in the **PDT clock** field.
+ **Program date time (PDT) period** – This field is used to set the time interval for insertion of `EXT-X-PROGRAM-DATE-TIME` tags, in seconds.
+ **Program date time (PDT) clock** – This field is used to select the time source of the PDT. Output timecode or UTC time can be selected.
+ **Client cache**
+ **Timestamp delta microseconds**
+ **Codec specification**
+ **Manifest compression**
For details about a field, choose the **Info** link next to the field in the MediaLive console.
## Fields for segments
The following fields configure media segments in the output.
+ The following fields in the **HLS output group – Manifests and Segments** section:
+ **TS file mode**
+ **Segment length**
+ **Keep segments**
+ **Min segment length**
+ **HLS outputs** – **Output settings** – **H.265 Packaging type**. This field applies only to fMP4 outputs. MediaLive ignores the value in this field for other types.
For details about a field, choose the **Info** link next to the field.
## Fields for resiliency
The following field relates to implementing resiliency in an HLS output.
+ **HLS output group** – **HLS Settings** section – **Input loss action**
Optionally change the value of **Input loss action**.
**Setting up for most downstream systems**
If you're sending this HLS output to a downstream system other than AWS Elemental MediaPackage, choose the **Info** link to decide which option to choose. For more information, see [Handling loss of video input](feature-input-loss.md).
**Setting up for MediaPackage**
If you're sending this HLS output to AWS Elemental MediaPackage, set this field to match how you set the [channel class](channel-class.md):
+ If the channel is a standard channel (to support input redundancy on MediaPackage), set this field to **PAUSE\$1OUTPUT**.
With this setup, if MediaLive stops producing output on one pipeline, MediaPackage detects the lack of content on its current input and switches to the other input. Content loss is minimized.
(If you set this field to **EMIT\$1OUTPUT**, MediaLive sends filler frames to MediaPackage. MediaPackage doesn't consider filler frames to be lost content, and therefore doesn't switch to its other input.)
+ If the channel is a single-pipeline channel, set this field to **EMIT\$1OUTPUT**.
With this setup, if the pipeline fails in MediaLive then MediaPackage continues delivering to its own downstream system (although the content will be filler frames).
(If you set this field to **PAUSE\$1OUTPUT**, MediaPackage stops updating its endpoint, which might cause problems at the downstream system.)
## Fields for DRM
Complete the **DRM **section only if you are setting up for DRM using a static key to encrypt the output.
+ In **Key provider** settings, choose **Static key**.
+ Complete the other fields as appropriate. For details about a field, choose the **Info** link next to the field.
In a static key setup, you enter an encryption key in this section (along with other configuration data) and then give that key to the other party (for example, by sending it in an email). A static key is not really a DRM solution and is not highly secure.
MediaLive supports only a static key as an encryption option. To use a DRM solution with a key provider, you must deliver the output to AWS Elemental MediaPackage, by creating a[ MediaPackage output group](creating-mediapackage-output-group.md) instead of an HLS output group. You then encrypt the video using MediaPackage. For more information, see the AWS Elemental MediaPackage User Guide.
## Fields for SCTE-35 ad avails
Complete the **Ad markers** section if you plan to include SCTE-35 messages in the output and to decorate the HLS manifest. See [Processing SCTE 35 messages](scte-35-message-processing.md) and specifically [Enabling passthrough for HLS outputs](scte-35-passthrough-or-removal.md#procedure-to-enable-passthrough-hls).
## Fields for captions
The following fields relate to embedded captions in an HLS output. If your plan includes creating at least one embedded captions encode in this HLS output, then the following fields apply:
+ In the **Captions** section, the **Caption language setting**.
You can optionally set up the HLS manifest to include information about the languages of the embedded captions.
+ **HLS settings** section – **Caption language mappings**
You can optionally set up the HLS manifest to include information about each CC (caption channel) number and language.
For detailed instructions about both these fields, see [Language information in HLS manifests](set-up-the-hls-manifest.md).
## Fields for ID3 metadata
Complete the **ID3 **section if you want to insert timed ID3 metadata or ID3 segment tags into all the outputs in this output group. For detailed instructions, see [Inserting ID3 timed metadata when creating the MediaLive channel](insert-timed-metadata.md).