# Customizing the paths inside HLS manifests When you create an HLS output group in a standard MediaLive channel, you can set up custom manifests. Note that you can't set up custom manifests in a MediaPackage output group, or in an HLS output group if the downstream system is MediaPackage. MediaPackage works only with the default paths. You can customize the main manifest by changing the paths to the child manifests. You can also customize each child manifest by change the paths the media files. Typically, you only need to change the syntax if the downstream system has special path requirements. Akamai CDNs usually require you to change the syntax. **Note** The information in this section on HLS manifests assumes that you are familiar with the general steps for creating a channel, as described in [Creating a channel from scratch](creating-channel-scratch.md). The key fields in the console that relate to this feature are in the **Location** grouping of the **HLS output group** section on the **Create channel** page. To review the step where you complete these fields, see [The procedure](creating-hls-output-group.md#hls-create-procedure). **Topics** + [Procedure to set up custom paths](hls-custom-manifests-procedure.md) + [How manifests work](hls-manifests-how-work.md) + [Rules for custom paths](hls-custom-paths-rules.md) + [Guidance for setting up for custom paths](hls-custom-paths-guidance.md) + [Examples of custom paths](hls-custom-paths-examples.md) # Procedure to set up custom paths Customizing the manifest paths involves working with the following fields: + **HLS output group – Location** – the **Base URL manifest** fields + **HLS output group – Location** – the **Base URL content** fields **To configure custom paths in manifests** 1. Speak to the downstream system to find out if custom paths are required. The main manifests might need custom paths to the child manifests, the child manifests might need custom paths to the media files, or both main and child manifests might need custom paths. See [How manifests work](hls-manifests-how-work.md). 1. Design the paths, paying attention to the [syntax and the rules for constructing the paths](hls-destinations-design-step.md#hls-syntax-http). See this [guidance for different downstream systems](hls-custom-paths-guidance.md). See [these examples](hls-custom-paths-examples.md). 1. Complete one or both of these fields in the **Location** section of the HLS output group page: + **Base URL manifest A** and **Base URL manifest B**. For a single-pipeline channel, complete only field A. For a standard channel, complete field A and field B. + **Base URL content A** and **Base URL content B**. For a single-pipeline channel, complete only field A. For a standard channel, complete field A and field B. # How manifests work The following sections describe how MediaLive handles manifest paths. ## How manifest paths work by default The manifests that MediaLive creates include information about the paths to other files, specifically: + The content inside the main manifest includes a path to each child manifest. By default, the syntax of this path is the following: ``` baseFilename nameModifier extension ``` For example: ``` curling-high.m3u8 ``` The path is relative to the location of the main manifest. + The content inside each child manifest includes a path to its media files. By default, the syntax of this path is the following: ``` baseFilename nameModifier optionalSegmentModifier counter extension ``` For example: ``` curling-high-000001.ts ``` The path is relative to the location of the child manifest. ## How custom paths work If the default paths inside the manifests are not suitable for the way that the downstream system handles the three sets of files, you can complete the *base URL* fields: + Complete the **Base URL manifest** fields so that MediaLive constructs custom paths to the child manifests. + Complete the **Base URL content** fields so that MediaLive constructs custom paths to the media files. When you customize the paths, the syntax changes. + When you complete the **Base URL manifest** fields, the syntax for the child manifest path (inside the main manifest) is the following: ``` baseURLManifest baseFilename nameModifier extension ``` For example: ``` http://viewing/sports/curling-high.m3u8 ``` + When you complete the **Base URL content** fields, the syntax for the media file paths (inside the child manifests) is the following: ``` baseURLContent baseFilename nameModifier optionalSegmentModifier counter extension ``` For example: ``` http://viewing/media/sports/curling-high-000001.ts ``` ## How MediaLive constructs these paths The custom paths to the child manifests are constructed as follows: + You complete the **Base URL manifest** fields, or the **Base URL content** fields, or both. For example: ``` http://198.51.100/sports/viewing/ ``` Note the slash at the end of the value. + MediaLive prepends that value to the [default path](#hls-default-manifest-paths). For example: ``` http://198.51.100/sports/viewing/curling-high.m3u8 ``` # Rules for custom paths After you have set up to customize the manifests in a MediaLive HLS output group, you should share the following rules with your contact person at the downstream system. The general rule is that it’s the responsibility of the downstream system to ensure that the custom path work in their environment. MediaLive doesn’t validate the values in any way. Therefore: + If the protocol is specified (it is optional), it must be identical to the protocol that you specified in the **Destination URL** fields. + The **Base URL manifest** and **Base URL content** fields for the same pipeline can have the same value or different values. They can be the same or different in any portion (the domain, path). + The values can result in a relative path or an absolute path. + A relative path to the child manifest is always relative to the location of the main manifest. + A relative path to the media files is always relative to the location of the child manifest. + The paths must end with a slash. # Guidance for setting up for custom paths The content in the customized path in an HLS output must be appropriate for the system that is downstream of MediaLive. Following is some guidance for using the *base URL* fields for different downstream systems. **Setting up for custom paths if you control the downstream system** You might control the downstream system. For example, the downstream systems might be Amazon S3 or MediaStore that sends content to Amazon CloudFront. Your handling of the HLS files might require that you move one or more of the sets of files around. In this case, you could complete these *base URL* fields to match the paths of the final location of the files. **Setting up for custom paths if the downstream packager is MediaPackage** If the downstream package is MediaPackage, leave the **Base URL** fields empty. MediaPackage doesn’t use this information. **Setting up for custom paths if you use a third-party downstream system** If you use a third-party downstream system, the downstream system must tell you whether to complete these **Base URL** fields. # Examples of custom paths Following are examples of the different ways that you might customize the manifests in a MediaLive HLS output group. In all these examples, assume the following: + In the main manifest, the default path to the child manifests is this relative path: ``` curling-high.m3u8 ``` + In the child manifest, the default path to the media files is this relative path: ``` curling-high-000001.ts ``` **Example 1** The downstream system is going to move the files from the location where MediaLive pushes them. The downstream system will move the files in such a way that the child manifests are still in the same relative location to the parent manifests, and the media files are still in the same relative location to the child manifests. Therefore, you don’t need to customize the paths. The default paths will still work after the move. **Example 2** You want the main manifest and the child manifests to include absolute paths to their respective files. You set up as follows: + Complete the **Base URL manifest A** field to specify this absolute path: ``` http://198.51.100/sports/viewing/ ``` Inside the main manifest, the path to the child manifest will now be the following: ``` http://198.51.100/sports/viewing/curling-high.m3u8 ``` + Complete the **Base URL content** field to specify this absolute path: ``` http://203.0.113.55/sports/viewing/ ``` Inside the child manifests, the paths to the media files will now be the following: ``` http://203.0.113.55/sports/viewing/curling-high-000001.ts ``` This example illustrates that the domain for the two sets of files could be different. **Example 3** You want the parent manifest to include absolute paths to the child manifests. But you want the child manifests to include paths to the media files that are relative to the child manifest. In this case, you customize the path to the child manifests, but you continue to use the default paths to the media files. + You complete the **Base URL manifest A** field to specify this absolute path: Inside the main manifest for pipeline A, the path to the child manifest will now be the following: ``` http://198.51.100/sports/viewing/curling-high.m3u8 ``` + You don’t complete the **Base URL content A** field. Inside the child manifests, the paths to the media files will still be the default: ``` curling-high-000001.ts ```