• Step 1: Identify the output group types for the downstream system (p. 73)
• Step 2: Identify the encode requirements for the output groups (p. 75)
• Step 3: Identify resiliency requirements (p. 76)
• Step 4: Assess the upstream system (p. 78)
• Step 5: Collect information about the source content (p. 83)
• Step 6: Coordinate with upstream system and create inputs (p. 87)
• Step 7: Arrange for delivery to downstream systems (p. 111)
• Next steps (p. 120)
Step 1: Identify the output group types for the downstream system
The first step in planning any AWS Elemental MediaLive workflow is to determine which types of output groups (p. 4)you need to produce, based on the requirements and capabilities of the systems that are downstream of MediaLive.
Perform this work with the downstream system before you assess the upstream system (p. 78).
Decision making in a workflow starts with the downstream system, then works back to the upstream system.
Important
You should have already identified the downstream system or systems that you are going to send MediaLive output to, for this workflow. If you have not yet identified the downstream system, you must do some research before continuing with preparing your workflow. This guide can't help you to identify your downstream system. When you know what your downstream systems are, return to this section.
To identify the output group
1. Obtain the following information from your downstream system.
• The required output formats. For example, HLS.
• The application protocol for each. For example, HTTP.
2. Decide on the delivery mode for your outputs.
• You might have an output that is on a server that is on your EC2 instance in your VPC. Or you might have an output that is in Amazon S3. If one or both of these situations apply, you might want to set up for delivery via your VPC. For more information, see the section called “VPC delivery” (p. 515).
• If you don't have any of these types of outputs, you will deliver in the regular way.
3. Make sure that MediaLive includes an output group that supports the output format and protocol that the downstream system requires. See the section called “Supported containers and downstream systems” (p. 548).
4. If your preferred downstream system is another AWS media service, read this for information about choosing the service (p. 74).
5. If your downstream system supports Microsoft Smooth Streaming, see the section called “Options for Microsoft Smooth” (p. 75) for options.
6. Decide if you want to create an archive output group in order to produce an archive file of the content. An archive file is a supplement to streaming; it isn't itself a streaming output. Typically, you create an archive file as a permanent file version of the streaming output.
7. Decide if you want to create a frame capture output group in order to produce a frame capture output. A frame capture output is a supplement to streaming; it isn't itself a streaming output. This
Choosing among the AWS media services
type of output might be useful for your workflow. For example, you might use a frame capture output to create thumbnails of the content.
8. Make a note of the output groups that you decide on. You will need this information when you design the output groups (p. 131).
For example, after you have followed these steps, you might have this list of output groups:
• One HLS output group with AWS Elemental MediaPackage as the downstream system.
• One RTMP output group sending to the downstream system of a social media site.
• One Archive output group as a record.
Topics
• Choosing among the AWS media services (p. 74)
• Choosing between the HLS output group and MediaPackage output group (p. 74)
• Options for handling Microsoft Smooth output (p. 75)
Choosing among the AWS media services
If your preferred downstream system is another AWS media service, following are some useful tips for choosing the service to use:
• If you need to choose between AWS Elemental MediaPackage or AWS Elemental MediaStore for HLS outputs, follow these guidelines:
• Decide if you want to protect your content with a digital rights management (DRM) solution. DRM prevents unauthorized people from accessing the content.
• Decide if you want to insert ads in your content.
If you want either or both of these features, you should choose MediaPackage as the origin service because you will need to repackage the output.
If you do not want any of these features, you could choose MediaPackage or AWS Elemental
MediaStore. AWS Elemental MediaStore is generally a simpler solution as an origin service, but it lacks the repackaging features of MediaPackage.
• If you have identified AWS Elemental MediaPackage as an origin service, decide if you will produce the HLS output using an HLS output group or a MediaPackage output group. For guidelines on making this choice, see the next section (p. 74).
Choosing between the HLS output group and MediaPackage output group
If you want to deliver HLS output to AWS Elemental MediaPackage, you must decide if you want to create an HLS output group or a MediaPackage output group.
There are differences in the setup that you must follow for each type of output group:
• Read the information about channel class (p. 456) and decide whether you will create a standard channel or a single-pipeline channel. If you decide to create a single-pipeline channel, then you should create an HLS output group.
• The MediaPackage output requires less setup. AWS Elemental MediaLive is already set up with most of the information that it needs to package and deliver the output to the AWS Elemental MediaPackage channel that you specify.
Options for Microsoft Smooth
• For a MediaPackage output, the MediaLive channel and the AWS Elemental MediaPackage channel must be in the same AWS Region.
• In a MediaPackage output, there are some restrictions on setting up ID3 metadata. For details, see the section called “ID3 metadata” (p. 396).
Options for handling Microsoft Smooth output
If you are delivering to a Microsoft Smooth Streaming server, the setup depends on whether you want to protect your content with a digital rights management (DRM) solution. DRM prevents unauthorized people from accessing the content.
• If you don't want to implement DRM, then create a Microsoft Smooth output group.
• If you do want to implement DRM, you can create an HLS or MediaPackage output group to send the output to AWS Elemental MediaPackage, then use AWS Elemental MediaPackage to add DRM. You will then set up AWS Elemental MediaPackage to deliver to the Microsoft Smooth origin server.
Step 2: Identify the encode requirements for the output groups
After you have identified the output groups that you need to create, you must identify the requirements for the video and audio encodes that you will include in each output group. The downstream system controls these requirements.
Perform this work with the downstream system before you assess the upstream system (p. 78).
Decision making in a workflow starts with the downstream system, then works back to the upstream system.
Result of this procedure
After you have performed this procedure, you will know what output groups you will create, and you will know which video and audio codecs those output groups can support. Therefore, you should have output information that looks like this example.
Example
Output group Downstream system Video codecs supported by downstream system
Audio codecs supported by downstream system
HLS MediaPackage AVC AAC 2.0, Dolby Digital
Plus
RTMP social media site AVC AAC 2.0
Archive Amazon S3 The downstream
system doesn't dictate
To identify the video and audio codecs in each output group Perform this procedure on every output group that you identified.
Step 3: Identify resiliency requirements
1. Obtain the following video information from your downstream system:
• The video codec or codecs that they support.
• The maximum bitrate and maximum resolution that they can support.
2. Obtain the following audio information from your downstream system:
• The supported audio codec or codecs.
• The supported audio coding modes (for example, 2.0) in each codec.
• The maximum supported bitrate for audio.
• For an HLS or Microsoft Smooth output format, whether the downstream system requires that the audio is bundled in with the video or that each audio appears in its own rendition. You will need this information when you organize the assets in the MediaLive outputs.
3. Obtain the following captions information from your downstream system.
• The captions formats that they support.
4. Verify the video. Compare the video codecs that your downstream system requires to the video codecs that MediaLive supports for this output group. See the tables in the section called
“Supported codecs for outputs” (p. 551). Make sure that at least one of the downstream system's offered codecs is supported.
5. Verify the audio. Compare the audio codecs that your downstream system requires to the video codecs that MediaLive supports for this output group. See the tables in the section called
“Supported codecs for outputs” (p. 551). Make sure that at least one of the downstream system's offered codecs is supported.
6. Skip assessment of the caption formats for now. You will assess those requirements in a later section (p. 82).
7. Make a note of the video codecs and audio codecs that you can produce for each output group.
8. Decide whether you want to implement a trick-play track. For more information, see the section called “Trick-play track” (p. 495).
.
Step 3: Identify resiliency requirements
Resiliency is the ability of the channel to continue to work when problems occur. MediaLive includes two resiliency features that you must plan for now. You must decide which of these features you want to implement. You must make this decision now because these features affect how many sources you need for your content, which requires discussion with your upstream system.
Pipeline redundancy
You can set up a channel with two pipelines, to provide resiliency within the channel processing pipeline.
Pipeline redundancy is a feature that applies to the entire channel and to all the inputs attached to the channel. Early on in your planning of the channel, you must decide how you want to set up the pipelines.
You set up for pipeline redundancy by setting up the channel as a standard channel so that it has two encoding pipelines. Both pipelines ingest the source content and produce output. If the current pipeline fails, the downstream system can detect that it is no longer receiving content and can switch to the other output. There is no disruption to the downstream system. MediaLive restarts the second pipeline within a few minutes.
For more information on pipeline redundancy, see the section called “Pipeline redundancy” (p. 456).
Automatic input failover
Automatic input failover
You can set up two push inputs for automatic input failover, to provide resiliency for one input in the channel.
Automatic input failover is a feature that applies to individual inputs. You don't have to make a decision about implementing automatic input failover when planning the channel. You can implement it later on, when attaching a new push input, or when you want to upgrade an existing push input so that it implements automatic input failover.
To set up for automatic input failover, you set up two push inputs (that have the exact same source content) as an input failover pair. Setting up this way provides resiliency in case of a failure in the upstream system, or between the upstream system and the channel.
In the input pair, one of the inputs is the active input and one is on standby. MediaLive ingests both inputs, in order to always be ready to switch, but it usually discards the standby input immediately. If the active input fails, MediaLive immediately fails over and starts processing from the standby input, instead of discarding it.
You can implement automatic input failover in a channel that is set up for pipeline redundancy (a standard channel) or one that has no pipeline redundancy (a single-pipeline channel).
For more information about automatic input failover, see the section called “Automatic input failover” (p. 360).
Comparison of the two features
Following is a comparison of pipeline redundancy and automatic input failover.
• There is a difference in the failure that each feature deals with:
Pipeline redundancy provides resiliency in case of a failure in the MediaLive encoder pipeline.
Automatic input failover provides resiliency in case of a failure ahead of MediaLive, either in the upstream system or in the network connection between the upstream system and the MediaLive input.
• Both features require two instances of the content source, so in both cases your upstream system must be able to provide two instances.
With pipeline redundancy, the two sources can originate from the same encoder.
With automatic input failover, the sources must originate from different encoders, otherwise both sources will fail at the same time, and the input failover switch will fail.
• Pipeline redundancy applies to the entire channel. Therefore you should decide whether you want to implement it when you plan the channel. Automatic input failover applies to only one input. Therefore you could, for example, decide to implement automatic input failover only when you attach your most important push input.
• Automatic input failover requires that the downstream system be able to handle two instances of the output and be able to switch from one (when it fails) to the other. MediaPackage, for example, can handle two instances.
If your downstream system doesn't have this logic built in, then you can't implement automatic input failover.
Step 4: Assess the upstream system
Step 4: Assess the upstream system
As part of the planning of the MediaLive workflow, you must assess the upstream system that is the source of the content, to ensure that it is compatible with MediaLive. Then you must assess the source content to ensure that it contains formats that MediaLive can ingest and that MediaLive can include in the outputs you want.
You obtain the source content from a content provider. The source content is provided to you from an upstream system that the content provider controls. Typically, you have already identified the content provider. For more information about source content and upstream systems, see the section called “How MediaLive Works” (p. 1).
To assess the upstream system
1. Speak to the content provider to obtain information about the upstream system. You use this information to assess the ability of MediaLive to connect to the upstream system, and to assess the ability of MediaLive to use the source content from that upstream system.
For details about the information to obtain and assess, see the following sections:
• the section called “Assess source formats and packaging” (p. 78)
• the section called “Assess video content” (p. 80)
• the section called “Assess audio content” (p. 81)
• the section called “Assess captions” (p. 82)
2. Make a note of the following three characteristics of the source stream. You will need this information when you set up the channel (p. 147):
• The video codec
• The resolution of the video—SD, HD, or UHD
• The maximum input bitrate
At the end of this step, you will know the following:
• You will be confident that MediaLive can ingest the content.
• You will know what type of MediaLive input you will create to ingest the source content.
• You will have the information that you need to extract the video, audio, and captions from the source (from the MediaLive input).
• You will have the basic information for setting up the channel to transcode the content.
Assess source formats and packaging
Consult the following table for information about how to assess the source formats and packaging. Read across each row.
Information to obtain Verify the following
Number of sources that the content provider can
provide. If you plan to implement a resiliency
feature (p. 76), make sure that your content provider can deliver the required inputs:
• For automatic input failover, they must deliver two identical instances of the same source content.
Encrypted HLS content
Information to obtain Verify the following
• For pipeline redundancy, they must deliver two identical instances of the same source content.
• If you plan to implement both features, they must deliver four instances.
Delivery formats and protocols Find out what format and protocol the upstream system supports for delivery.
Make sure that this format is listed in the table in the section called “Supported input formats and protocols” (p. 541). If it is not listed, speak to your content provider about how they can add support for MediaLive.
Note that you don't need to verify this information for content delivered over CDI or content delivered from an AWS Elemental Link.
MediaLive can always handle these input types.
Whether the upstream system is using the latest
SDK Make sure that the content provider is using
the latest version of the AWS CDI SDK on their upstream CDI source device.
Whether the source content is a stream or VOD
asset Find out if the source content is a live stream or a
VOD asset.
Make sure that MediaLive supports the delivery for the format that you identified. See the table in the section called “Support for live and file inputs” (p. 544).
Whether the content is encrypted MediaLive can ingest encrypted content only from HLS content.
If the source content is HLS and it is encrypted, make sure that it is encrypted in a format that MediaLive supports. See the section called
“Encrypted HLS content” (p. 79). If MediaLive doesn't support the available encryption format, find out if you can obtain the content in unencrypted form.
Only if the source content is RTP, whether it
includes FEC. We recommend that the source content include
FEC because it is less likely to result in an output that has visual disruptions.
Handling encrypted source content in an HLS source
MediaLive can ingest an HLS source that is encrypted according to the HTTP Live Streaming specification.
Supported encryption format
MediaLive supports the following format for encrypted HLS sources:
• The source content is encrypted with AES-128. MediaLive doesn't support AES-SAMPLE.
• The source content is encrypted using either static or rotating keys.
Assess video content
• The manifest includes the #EXT-X-KEY tag with these attributes:
• The METHOD attribute specifies AES-128.
• The URI specifies the license server for the encryption key.
• The IV is blank or specifies the initialization vector (IV) to use. If the IV is blank, MediaLive uses the value in the #EXT-X-MEDIA-SEQUENCE tag as the IV.
• If both the upstream system and the license server require authentication credentials (user name and password), make sure that the same credentials are used on both servers. MediaLive does not support having different credentials for these two servers.
How decryption works
The content owner sets up the main manifest to include the #EXT-X-KEY with the method (AES-128), the URL to the license server, and the initialization vector (IV). The content owner places the encryption keys on the license server. When the MediaLive channel that uses this source starts, MediaLive obtains the main manifest and reads the #EXT-X-KEY tag for the URL of the license server.
MediaLive connects to the license server and obtains the encryption key. MediaLive starts pulling the content from the upstream system, and decrypts the content using the encryption key and the IV.
Assess video content
Consult the following table for information about how to assess video source. Read across each row.
NoteYou don't need to perform any assessment of the video being delivered over CDI or from an
NoteYou don't need to perform any assessment of the video being delivered over CDI or from an