

# How MediaPackage works
<a name="what-is-flow"></a>

AWS Elemental MediaPackage (MediaPackage) uses just-in-time format conversion to deliver over-the-top (OTT) video from a single source to a wide variety of playback devices or content delivery networks (CDNs).

The following sections describe how MediaPackage works.

**Topics**
+ [Live content processing](what-is-flow-live.md)
+ [VOD Content Processing](what-is-flow-vod.md)
+ [Live and VOD manifest reference](what-is-manifest.md)

# Live content processing
<a name="what-is-flow-live"></a>

In the processing flow for live content, encoders send live HLS streams to MediaPackage. MediaPackage then packages the content, formatting it in response to playback requests from downstream devices. 

The following sections describe the live processing flows.

**Topics**
+ [General MediaPackage live processing flow](what-is-flow-gen.md)
+ [Live input redundancy AWS Elemental MediaPackage processing flow](what-is-flow-ir.md)

# General MediaPackage live processing flow
<a name="what-is-flow-gen"></a>

The following outlines the general flow of live content in MediaPackage:

1. An upstream encoder (such as AWS Elemental MediaLive) sends an HLS live stream with digest authentication over WebDAV to the MediaPackage channel input URL, and includes the channel's access credentials (as supplied in MediaPackage). If you're using input redundancy, the encoder sends two identical HLS live streams to MediaPackage, one to each input URL on the channel. MediaPackage uses the stream from one input URL as the source content. If MediaPackage stops receiving content on the active input URL, it automatically switches to the other input URL for source content. Additionally, AWS scales resources up and down to handle the incoming traffic.

   For more information, see [Live input redundancy AWS Elemental MediaPackage processing flow](what-is-flow-ir.md).
**Note**  
To allow support for features like time-shifted viewing, MediaPackage stores all received content for a limited time. This stored content is only available for playback if it falls within the **startover window** that's defined on the endpoint. Stored content isn't available for playback if it's outside the startover window, or if you haven't defined a window on the endpoint. For more information, see [Time-shifted viewing reference in AWS Elemental MediaPackage](time-shifted.md).

1. A downstream device requests content from MediaPackage through the endpoint output URL. A downstream device is either a video player or a CDN. The output URL is associated with an endpoint for a specific streaming format (either Apple HLS, DASH-ISO, Microsoft Smooth Streaming, or CMAF).

1. When MediaPackage receives the playback request from the downstream device, it dynamically packages the stream according to the settings that you specified on the endpoint. Packaging can include adding encryption and configuring audio, video, and subtitles or captions track outputs.

   Be sure to order your inputs so that your preferred audio rendition is listed first in the audio section of the parent manifest. Do the same for the subtitles or captions. When packaging audio and subtitles or captions tracks, MediaPackage designates the first audio and captions or subtitles track as `DEFAULT=YES` and `AUTO-SELECT=YES`. This packaging overrides default and auto-select settings from the input.

1. MediaPackage delivers the output stream over HTTPS to the requesting device. As with input, AWS scales resources up and down to handle changes in traffic.

1. MediaPackage logs activity through Amazon CloudWatch. You can view information such as the number of content requests and amount of content that MediaPackage has received or delivered. For information about viewing MediaPackage metrics in CloudWatch, see [Monitoring AWS Elemental MediaPackage with Amazon CloudWatch metrics](monitoring-cloudwatch.md).

Throughout the content input and output processes, MediaPackage detects and mitigates potential infrastructure failures before they become a problem for viewers. 

The following illustration shows the overall process.

![\[MediaPackage workflow\]](http://docs.aws.amazon.com/mediapackage/latest/ug/images/bbl_flow1.png)


# Live input redundancy AWS Elemental MediaPackage processing flow
<a name="what-is-flow-ir"></a>

Achieve input redundancy in AWS Elemental MediaPackage by sending two streams to separate input URLs on a channel in MediaPackage. One of the streams becomes the primary, active source of content for the endpoints, while the other continues to passively receive content. If MediaPackage stops receiving content from the active stream, it switches over to the other input stream so that content playback isn't interrupted.

If you use MediaPackage with AWS Elemental MediaLive (for example), here's the flow of input redundancy:

1. You create a channel in MediaPackage, as described in [Creating a channel](channels-create.md). When MediaPackage provisions the channel, it creates two input URLs for the channel. If you're not using input redundancy, you can send a stream to either input URL. There's no requirement that you send content to both URLs.
**Note**  
When input redundancy became available, MediaPackage added a second input URL to existing channels and updated the existing URL to a new format. You can use either the existing URL or the new URLs for content input. 

1. You create an endpoint in MediaPackage as described in [Creating an endpoint](endpoints-create.md). 
**Important**  
If you use short output segments, depending on your playback device, you might see buffering when MediaPackage switches inputs. You can reduce buffering by using the time delay feature on the endpoint. Be aware that using a time delay introduces latency to end-to-end delivery of the content. For information about enabling time delay, see [Creating an endpoint](endpoints-create.md).

1. You create an input and channel in AWS Elemental MediaLive, and you add a MediaPackage output group to the channel in MediaLive. For more information, see [Creating a Channel from Scratch](https://docs.aws.amazon.com/medialive/latest/ug/creating-channel-scratch.html) in the *AWS Elemental MediaLive User Guide*. 

   If you use an HLS output group in AWS Elemental MediaLive, the input loss action on the HLS group's settings must be set to pause the output if the service doesn't receive input. If MediaLive sends a black frame or some other filler frame when it's missing input, then MediaPackage can't tell when segments are missing, and subsequently can't perform failover. For more information about setting the input loss action in MediaLive, see [Fields for the HLS Group](https://docs.aws.amazon.com/medialive/latest/ug/hls-group-fields.html) in the *AWS Elemental MediaLive User Guide*. 
**Important**  
If you use a different encoder (not AWS Elemental MediaLive) and you send two separate streams to the same channel in MediaPackage, the streams must have identical encoder settings and manifest names. Otherwise, input redundancy might not work correctly and playback could be interrupted if the inputs switch.

1. You start the channel in AWS Elemental MediaLive to send the streams to MediaPackage.

1. MediaPackage receives content on both of the input URLs, but only one of the streams is used for source content at a time. If the active stream is missing any segments, then MediaPackage automatically fails over to the other stream. MediaPackage continues to use this stream until failover is needed again.

   The formula that's used to determine if an input is missing segments is based on the segment lengths on the inputs and the endpoints. If an input is missing segments and quickly recovers, an endpoint with longer segment lengths won't switch inputs. This might result in different endpoints on the channel using different inputs (if one endpoint switches and the other doesn't). This is expected behavior and should not affect the content workflow.

# VOD Content Processing
<a name="what-is-flow-vod"></a>

In the processing flow for VOD content, AWS Elemental MediaPackage ingests file-based video content from Amazon S3. MediaPackage then packages the content, formatting it in response to playback requests from downstream devices. 

Here is the general processing flow for VOD content in MediaPackage:

1.  From the MediaPackage asset, you initiate ingest of the source content from an Amazon S3 bucket. This process can take several minutes. You receive an Amazon CloudWatch event when ingest is complete and the playback URLs are live.

1. A downstream device requests content from MediaPackage through the packaging configuration URL on the asset. A downstream device is either a video player or a CDN. The URL is associated with a configuration for a specific streaming format (either Apple HLS, DASH-ISO, Microsoft Smooth Streaming, or CMAF).

1. When MediaPackage receives the playback request from the downstream device, it dynamically packages the stream according to the settings that you specified in the packaging configuration. Packaging can include adding encryption and configuring audio, video, and subtitles or captions track outputs.

   Be sure to order your inputs so that your preferred audio rendition is listed first in the audio section of the parent manifest. Do the same for the subtitles or captions. When packaging audio and subtitles or captions tracks, MediaPackage designates the first audio and captions or subtitles track as `DEFAULT=YES` and `AUTO-SELECT=YES`. This packaging overrides default and auto-select settings from the input.

1. MediaPackage delivers the output stream over HTTPS to the requesting device. As with input, AWS scales resources up and down to handle changes in traffic.

1. MediaPackage logs activity through Amazon CloudWatch. You can view information like the number of content requests and amount of content that MediaPackage has delivered. For information about viewing MediaPackage VOD metrics in CloudWatch, see [Monitoring AWS Elemental MediaPackage with Amazon CloudWatch metrics](monitoring-cloudwatch.md).

Throughout the content input and output processes, MediaPackage detects and mitigates potential infrastructure failures before they become a problem for viewers. 

# Live and VOD manifest reference
<a name="what-is-manifest"></a>

AWS Elemental MediaPackage delivers live and video on demand (VOD) manifests to requesting devices. A live manifest indicates that the content isn't complete. New content continually becomes available through the playback endpoint. Alternatively, a VOD manifest indicates that the program is complete, or will be complete at a specified time in the future. 

This section describes the differences in live and VOD manifests, and explains when MediaPackage delivers each manifest type.

# Manifest properties
<a name="manifest-properties"></a>

These are the main properties in a manifest that determine if it's live or VOD:
+ For HLS and CMAF VOD manifests, `EXT-X-ENDLIST` is at the end of the bitrate manifests. In live manifests, this tag isn't present.
+ For MPEG-DASH VOD manifests, `type="static"` is in the `MPD` properties. In live manifests, `type=dynamic`.
+ For Microsoft Smooth VOD manifests, `IsLive` isn't present in the `SmoothStreamingMedia` properties. In live manifests, `IsLive=TRUE`.

For VOD, the scrub bar on playback devices also often shows that the program has a limited duration. This duration is equal to the length of the current manifest. If a playback request defines a specific playback window, this duration is equal to the length of that playback window. 

To determine if the manifest is live or VOD, see [Live and VOD manifest reference](what-is-manifest.md).

## When a manifest is VOD
<a name="manifest-complete"></a>

MediaPackage delivers a VOD manifest when the content of the program is complete. MediaPackage considers a program complete under the following conditions:

**There's an `end` parameter in the past.**  
When a playback request includes an `end` parameter that's set in the past, the content is complete. No new content is added to it. MediaPackage delivers a static, VOD manifest to downstream devices.  
For information about start and end parameters in playback requests, see [Time-shifted viewing reference in AWS Elemental MediaPackage](time-shifted.md).

**The manifest that the upstream encoder delivers to MediaPackage includes an `EXT-X-ENDLIST` tag.**  
When you stop the output from your encoder, the manifest that it sends to MediaPackage includes an `EXT-X-ENDLIST` tag. This tag tells MediaPackage that the content is complete, and no new content will be added. MediaPackage delivers a static, VOD manifest to downstream devices.  
If you manually stop an AWS Elemental MediaLive channel when one or both pipelines to MediaPackage are stopped, MediaLive doesn't include `EXT-X-ENDLIST` in the HLS manifest to MediaPackage. MediaPackage continues to produce a live manifest.   
If both pipelines are active when you stop the channel, MediaLive includes `EXT-X-ENDLIST`. MediaPackage delivers a VOD manifest to downstream devices.
If you restart the output from the encoder, the manifest from MediaPackage becomes live again. Playback devices might need to refresh to resume content playback.  
If you're using input redundancy and the active stream ends, MediaPackage fails over to the other incoming stream for input. The manifest isn't marked as complete unless both incoming streams end.