Step 2: Design output names and destination paths - AWS Elemental MediaLive

Step 2: Design output names and destination paths

You should take some time to carefully plan the output names and destination paths for the HLS output.

Skip this step if the downstream system is MediaPackage.

To design outputs and destinations

  1. Read the information in About the path for output destinations for general information about the different portions of the output names and destination paths.

  2. Design the destination path.

    For the base_filename portion of the destination path, follow these guidelines:

    • For a single-pipeline channel, you need only one base_filename.

    • For a standard channel when you are not implementing redundant manifests, you need two base_filenames. The two base_filenames can be identical or different. Before you create different base_filenames, 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.

  3. Design the name_modifier portions of the destination path. The child manifests and media files include this modifier in their file names. This name_modifier 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 an underscore, to clearly separate the base_filename from the name_modifer.

    • The name_modifier can include data variables.

  4. Design the segment_modifiers portion of the destination path. The segment_modifier 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 $t$_. Segment 000002 might have the name curling_120028_000002. If the output restarts a few minutes later (which causes the segment counter to restart), the new segment 000002 will have the name curling_120039_000002. The new file won't overwrite the file for the original segment 000002. Some downstream systems might prefer this behavior.