# Setup: Creating inputs Setup: Creating inputs This section describes how to create inputs for the content sources for an AWS Elemental MediaLive channel. You must create these inputs before you start to create the channel. To create an input, you must perform these steps: + You must arrange for the operator at the upstream system to perform some setup. + You must create inputs in MediaLive. These two steps create a connection between an address on the upstream system and an address on MediaLive. The source content moves from the specified address on the upstream system to the specified address on MediaLive as either a *push* by the upstream system or a *pull* by MediaLive. The connection information is contained in the input that you create. The setup you perform is different for each combination of upstream system (format and delivery protocol) and input type. If you haven't already done so, you must identify the upstream system and input type for each content source. See [Assess the upstream system](evaluate-upstream-system.md). **Topics** + [ # Getting ready ](input-create-getready.md) + [CDI input](input-create-cdi-push.md) + [CDI input – Partner CDI input](input-create-cdi-partners.md) + [Elemental Link input](input-create-link-device.md) + [HLS input](input-create-hls-pull.md) + [MediaConnect input](input-create-push-mediaconnect.md) + [MediaConnect Router input](input-create-mediaconnect-router.md) + [MP4 input](mp4-pull-input.md) + [RTMP pull input](input-create-rtmp-pull.md) + [RTMP push input](input-create-rtmp-push.md) + [RTMP VPC input](rtmp-push-vpc-input.md) + [RTP push input](input-create-rtp-push.md) + [RTP VPC input](rtp-push-vpc-input.md) + [SMPTE 2110 input](input-create-s2110.md) + [SRT Caller input](input-caller-srt.md) + [SRT Listener input](input-listener-srt.md) + [TS file input](ts-file-input.md) + [ # Next steps ](input-create-nextsteps.md) # Getting ready Before you create any input, you should plan the workflow. Read the following sections: + [Preparing the upstream and downstream systems in a workflow](container-planning-uss-dss.md) – You must set up for delivery from the upstream system. The task of creating an input is part of that delivery setup. You must coordinate with your upstream system and content provider. + [Implementing pipeline redundancy](plan-redundancy-mode.md) – You must decide if you want to implement pipeline redundancy—whether you set up a standard channel or a single-pipeline channel. Implementing pipeline redundancy provides resiliency in the channel processing pipeline. + [Implementing automatic input failover](automatic-input-failover.md) – You must decide if you want to implement automatic input failover. Implementing automatic input failover provides resiliency upstream of the channel, for one of the channel's inputs. # Setting up a CDI input CDI input This section describes how to create a CDI push input. With a CDI source, the upstream system *pushes* the content to MediaLive. To perform this setup, you must work with an Amazon VPC user, with an operator at the upstream system, and you must work within MediaLive. **Note** Make sure that the content provider is using the latest version of the [AWS CDI SDK](https://aws.amazon.com/media-services/resources/cdi/) on their CDI source device. **Topics** + [ # Request setup on the VPC ](setup-vpc-cdi-vpc.md) + [ # Create a CDI input ](setup-input-cdi-vpc.md) + [ # Ensure correct setup on the upstream system ](setup-uss-cdi-vpc.md) + [ # Result of this procedure ](setup-result-cdi-vpc.md) # Request setup on the VPC Step 1: Set up VPC An Amazon VPC user must set up the VPC, and identify subnets and security groups that both the upstream system and MediaLive will use. **To set up the VPC** 1. Provide the Amazon VPC user with the following guidelines. + Guideline for the subnets – Request two subnets. You need two subnets because a CDI input is always a [standard-class input](class-channel-input.md), even if your channel is a single-pipeline channel. For information about input classes, see [Choosing the channel class and input class](class-channel-input.md). These rules apply: + The two subnets must be in different Availability Zones. + Each subnet must have a private CIDR block (a range of IP addresses). + Each subnet must have at least two unused addresses in that block—one for the upstream system and one for the CDI input. + Any other VPC-based sources (source B) that you create for use in the same channel as this CDI source (source A) must be in subnets that are in the same Availability Zones as source A. The two subnets of the source B can be different from the source A, but the Availability Zones of those two subnets must be the same as the Availability Zones of source A. + Guideline for the security group – the security groups or groups for each subnet must follow these rules: + The combined inbound rules of the security groups must allow inbound traffic from the IP addresses of the upstream system that is in that subnet. + The subnet must have an EFA-enabled security group. To create this type of security group and for information about its rules, see the [Amazon Elastic Compute Cloud User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html). 1. After the Amazon VPC user has performed the setup, obtain the following information: + The ID of the VPC. For example: `vpc-3f139646` + The IDs of the two subnets. For example, one subnet might have this ID: `subnet-1122aabb` + The IDs of the security groups for the subnet or subnets. For example: `sg-51530134` # Create a CDI input Step 2: Create input After the Amazon VPC user has set up on the VPC, you can create the CDI input in MediaLive. This section describes how to create a regular CDI input. Create this type of input if you don't plan to support automatic input failover for the CDI source attached to the channel. (If you do plan to implement it, create [CDI *partner inputs*](input-create-cdi-partners.md) instead. ) **Topics** + [ ## Create the CDI input ](#cdi-push-create) + [ ## IAM role and ARN ](#cdi-push-role-and-remember-arn) ## Create the CDI input **To create a CDI push input** 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **AWS CDI**. 1. Complete the **VPC settings** section: + Choose **Select subnets and security groups**. + For **Subnets**, choose one of the subnets that you obtained. The dropdown list shows subnets in all VPCs, identified as follows: ` ` For example: **subnet-1122aabb us-west-2a 10.30.30.0/24 vpc-3f139646 Subnet for MLive push inputs** If the list of subnets is empty, choose **Specify custom VPC**, and enter the subnet ID in the field. (You need to enter only the subnet ID, for example, **subnet-1122aabb**.) + In **Subnets**, choose the second subnet. This second time, the dropdown list shows only the subnets in the same VPC as the first subnet. + For **Security groups**, choose the security group or groups that you obtained, following the same process as for the subnets. The dropdown list shows security groups belonging to the VPC that you chose, identified as follows: ` ` For example: **sg-51530134 Security group for MLive push inputs vpc-3f139646** 1. Complete the **Role ARN** section to choose a role for MediaLive to use with this input. For more information, see [IAM role and ARN](#cdi-push-role-and-remember-arn). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. These endpoints have a private IP address from the subnet range, and they specify port 5000. For example: `10.30.30.33:5000` `10.30.30.44:5000` 1. Provide the upstream system with these endpoints: + If you will set up the channel as a standard channel, provide both endpoints. The upstream system must push the content to both endpoints. + If you will set up the channel as a single-pipeline channel, provide only the first endpoint. The upstream system must push to this one endpoint. ## IAM role and ARN This section describes how to complete the **Role ARN** section on the **Create input** pane of the MediaLive console, when you create a CDI input. You must choose a role for MediaLive to assume when it creates a CDI input. To create the input, MediaLive must obtain the network interfaces for the two endpoints in the input. These endpoints are in the CIDR range of the subnets that you identified. As soon as you choose **Create** for this input, MediaLive requests these network interfaces from Amazon VPC. The role that you choose ensures that MediaLive succeeds in its request to Amazon VPC. **Note** This section on the MediaLive console is identical to the **IAM role** section on the **Create channel** page (also on the MediaLive console). The difference in the two usages is that on the **Create input** page, you are attaching the role to the input. On the **Create channel** page, you are attaching the role to the channel. You can use the same role (for example, the **MediaLiveAccessRole**) in both usages. There are two general scenarios for choosing a role, depending on whether your organization has a designated administrator. ### Your organization has a designated administrator Your organization might have an administrator who manages this service. That administrator has likely set up one or more roles: + Ask the administrator or your manager which role to use. Or if only one role is listed in **Use existing role**, choose that role. + If the only role that is listed is **MediaLiveAccessRole**, choose that role. In addition, if the **Update** button is displayed beside this role name, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. ### Your organization has no administrator Your organization might not have a designated service administrator. In this case, if none of your colleagues have set up a suitable role, you might have to create one yourself and then choose it. + You can create the default role, called **MediaLiveAccessRole**. To first check if someone else has already created this role (only one person needs to create it for all users in your AWS account), look at **Create role from template**: + If this option is grayed out, this task has been done. In that case, choose **Use existing role**, and then choose **MediaLiveAccessRole** from the list. + If this option is not grayed out, choose **Create role from template**, and then choose **Create IAM role**. Next, choose that role from the list. If MediaLive does not let you create the role, speak to an administrator in your organization about your IAM permissions. + If the **MediaLiveAccessRole** has already been created and the **Update** button is displayed beside it, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. # Ensure correct setup on the upstream system Step 3: Set up upstream After you create the CDI input, you must make sure that the operator at the upstream system sets up correctly with your VPC, and that they push content to the correct locations in MediaLive. **To set up for a standard channel** If the planned channel is a [standard channel](plan-redundancy.md), you must ensure that the operator at the upstream system provides two sources. 1. Provide the operator with this information: + The IDs of the VPC, two subnets, and the security groups that the Amazon VPC user gave you in [step 1](setup-vpc-cdi-vpc.md). + The two endpoints (URLs) that MediaLive generated when you created the CDI input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-result-cdi-vpc.md). These URLs each have a private IP address from the subnet range, and they specify port 5000. For example: `10.30.30.33:5000` `10.40.40.44:5000` 1. Make sure that the operator sets up properly for a standard channel. They must do the following: + Set up two output interfaces. Set up one upstream system with one output interface in one of the subnets, and set up the other upstream system with one output interface in the other subnet. These interfaces are the addresses in the purple boxes in [the diagram after this procedure](setup-result-cdi-vpc.md). + Make sure that the two content sources are identical in terms of video resolution and bitrate. + Push to the correct URLs on MediaLive. For example, they must push to: `10.30.30.33:5000` `10.40.40.44:5000` **To set up for a single-pipeline channel** + There will be one upstream system that sends content to only one of the subnets in the VPC. + The content will flow from the VPC to one of the endpoints on the input. The other endpoint will never be used. + MediaLive will ingest the single source content. 1. Provide the operator with this information: + The IDs of the VPC, one of the subnets, and all of the security groups that the Amazon VPC user gave you. + Only the first of the two endpoints (URLs) that MediaLive generated when you created the CDI input. These endpoints are the addresses in the blue box in [the diagram after this procedure](setup-result-cdi-vpc.md). The URL has a private IP address from the subnet range, and it specifies port 5000. `10.30.30.33:5000` 1. Make sure that the operator sets up properly for a single-pipeline channel. They must: + Set up one upstream system. + Set up one output interfaces. The interface is the address in one of the purple boxes in [the diagram after this procedure](setup-result-cdi-vpc.md). + Push to the correct URL on MediaLive. For example, they must push to: `10.30.30.33:5000` # Result of this procedure The results of this setup are illustrated in the diagram that follows. There are three main components: + The upstream system (purple boxes). + The VPC, with subnets (green boxes), and VPC security groups (yellow boxes). + The CDI input (blue box). The CDI input has one or two *endpoint* URLs (the addresses in the blue box). These endpoints are elastic network interfaces (ENIs) on your VPC. MediaLive has permission to use these ENIs for its inputs. MediaLive has permission (through the IAM trusted entity role) to automatically manage the ENIs for its inputs. The upstream system has two outputs. Each output has an IP address in one of the specified subnets in your VPC. The upstream system has permission (through the rules in one or more Amazon VPC security groups) to push content to these endpoints. The upstream system pushes the source content to both endpoints (if you are setting up a standard channel) or to one endpoint (if you are setting up a single-pipeline channel). The upstream system has IP addresses in the VPC subnets, and the CDI input has endpoints in the same VPC subnets. In this way, the delivery of the content from the upstream system to MediaLive takes place within the security of the VPC. The two IP addresses on the CDI input are fixed for the lifetime of the input. They are fixed, regardless of changes such as modifying other information in the input, or attaching the input to a different channel. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Diagram showing VPC subnets, security groups, and upstream systems connecting to CDI input in MediaLive.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\cdi-vpc-uss-input.png) # Creating a partner CDI push input in Amazon VPC CDI input – Partner CDI input A partner CDI input is a specific configuration of a CDI input. If you want to support automatic input failover for the CDI source attached to the channel, you must set up the two CDI inputs as *partners*. For more information about partner CDI inputs, see [Creating CDI inputs as partner inputs](feature-cdi-partner.md). The two inputs always work together, as the two inputs in an automatic failover pair. The two inputs can be used only together, as a failover pair. You create a set of partner CDI inputs in two steps: + Create the first partner CDI input in the usual way. + Then, create the second partner input from the first input. **To create the first partner CDI input** + If you already have a regular CDI input, you can use it as the first partner. Skip this step and go to the step for creating the second partner, below. If not, [create the input in the usual way](setup-input-cdi-vpc.md). MediaLive creates the input and automatically creates two endpoints on that input. These endpoints each have a private IP address from the subnet range, and they specify port 5000. For example: `10.30.30.33:5000` `10.30.30.44:5000` Don’t provide this information to the upstream system until you have created the second partner. **To create the second partner CDI input** 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. 1. On the list of inputs, choose the first partner input. The details for the input appear. In the **Endpoints** section, you can see the endpoints that apply to this input. For example: `10.30.30.33:5000` `10.30.30.44:5000` 1. At the top of the page, choose **Create partner input**. 1. On the confirmation dialog, optionally choose to copy the tags, if any, from the first input. 1. Choose **Confirm**. The **Input details** page for this input appears, showing information about the new input. + In **Details**, the **Name** shows that the input has the same name as the first input, with the suffix "- partner". + In **Details**, the partner **CDI ID **field shows the ID of the first input. + In **Endpoints**, the endpoints for the input are identical to the two endpoints for the first input, except that the port numbers are different. For example: `10.30.30.33:5001` `10.30.30.44:5001` # Setting up an Elemental Link input Elemental Link input This section describes how to create an Elemental Link push input. The AWS Elemental Link device *pushes* the content to MediaLive. To perform this setup, you must work with an operator of the AWS Elemental Link device. **Topics** + [ # Obtain information ](setup-input-link-obtain-info.md) + [ # Create an Elemental Link input ](setup-uss-input-link.md) + [ # Result of this procedure ](setup-link-result.md) # Obtain information Step 1: Obtain information Obtain the following information from the operator of the AWS Elemental Link device: + The name of the device or devices that will provide your source. For example: **hd-re87jr7crey** You need two device names for a standard-class input, or one device name for a single-class input. For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). + The Region that the device is configured for, so that you can set MediaLive for that Region. These rules apply: + Both devices must be in the same Region. + The device, the input for that device, and the channel that uses the input must all be in the same Region. # Create an Elemental Link input Step 2: Create input After you have obtained information about the AWS Elemental Link hardware device, you can create an Elemental Link input. **To create a Link input** 1. Make sure that you have the information from [step 1](setup-input-link-obtain-info.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. Set the AWS Region to match the Region where the AWS Elemental Link device exists. 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **Elemental Link**. 1. In the **Input devices** section, for **Input class**, choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT 1. In **Input devices**, choose one or two devices to attach to this input as the source. From the dropdown lists, choose the device names you previously obtained. The lists show only the devices that are set up in the current Region. + If the input is a standard-class input, complete both fields, to provide two source devices. + If the input is a single-class input, complete the first field and leave the second field empty. 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. The **Details** pane appears for the input, showing details about the input and the MediaLive device that it uses, including the following: + **ID** – A unique numerical ID for the input. + **ARN** – An input ARN that includes that numerical ID. + **Input device** – The unique ID of the AWS Elemental Link device. + **Device thumbnail** – A thumbnail of the content that is currently being pushed by the device, if there is any being pushed. The device generates the thumbnails by capturing a video frame approximately every 5 seconds. # Result of this procedure Result of this procedure As a result of this setup, an Elemental Link input (the blue box) exists that identifies the AWS Elemental Link device or devices (the purple box) that are connected to MediaLive. There is no other setup for you to perform, because the AWS Elemental Link device is designed to work seamlessly with MediaLive. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to and ingests the content that AWS Elemental Link is pushing. ![\[Diagram showing AWS Elemental Link device connecting to Link input in MediaLive.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\link-uss-input.png) # Setting up an HLS input HLS input This section describes how to create an HLS input. With an HLS input, MediaLive connects to the upstream system when the channel starts and *pulls* the sources. To perform this setup, you must work with an operator at the upstream system. **Topics** + [ # Obtain information ](setup-hls-http.md) + [ # Create an HLS input ](setup-input-hls.md) + [ # Ensure correct setup on the HLS upstream server ](setup-uss-hls.md) + [ # Result of this procedure ](setup-hls-result.md) # Obtain information Step 1: Obtain information Obtain the following information from the operator at the upstream system: + The locations (URLs) on the upstream server where the M3U8 manifest files are stored. There are two URLs for a standard-class input, or one URL for a single-class input. For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). See the tables later in this section for the URL format and for examples. Make a note of the full URLs. + The user name and password (credentials) to access the upstream server, if the upstream system requires authenticated requests, and to access the license server, if the [HLS source is encrypted](uss-obtain-info.md). You might need credentials for the upstream system, or for the license server, or both. If you need credentials for both, the credentials must be identical for both servers. When you [discussed any encryption requirements](planning-hls-input-encrypted.md) with the upstream system, you should have made sure that the license server uses the same credentials as the upstream system. Note that these user credentials relate to user authentication, not to the protocol. User authentication is about whether the upstream system or license server will accept your request. The protocol is about whether the request is sent over a secure connection. **Upstream server is an HTTP or HTTPS server** | | | | --- |--- | | Format of URL | http//:[:port]//.m3u8orhttps//:[:port]//.m3u8 | | Example | https://203.0.113.13/sports/curling.m3u8 and`https://198.51.100.54/sports/curling.m3u8` | **Upstream server is AWS Elemental MediaStore** | | | | --- |--- | | Format of URL | mediastoressl:////.m3u8 | | Example | Assume that the data endpoint for the container for one of the content sources is the following: **eri39n.data.mediastore.us-west-2.amazonaws.com**. Assume that the `M3U8` file is called `curling.m3u8`, and it is stored in the container, in the path `sports/canada`. The URL for one of the content sources would be: **mediastoressl://eri39n.data.mediastore.us-west-2.amazonaws.com/sports/canada/curling.m3u8**. | **Upstream server is Amazon S3** | Upstream server | Format of URL | | --- | --- | | Format of URL | s3ssl:////.m3u8 | | Example | `s3ssl://amzn-s3-demo-bucket/movies/main/mlaw.m3u8` and `s3ssl://amzn-s3-demo-bucket1/movies/redundant/mlaw.m3u8` | # Create an HLS input Step 2: Create input After you have obtained information from the upstream system, you can create an HLS input. **To create an HLS pull input** 1. Make sure that you have the information from [step 1](setup-input-link-obtain-info.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **HLS**. 1. In the **Input class** section, choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT 1. In the **Input sources** section, enter the URLs you previously obtained: + If the input is a standard-class input, complete both fields, to provide two URLs. + If the input is a single-class input, complete the first field with the URL that you obtained and leave the second field empty. 1. If the upstream system and/or the license server (if the HLS source is encrypted) requires that you provide user credentials, you must also enter the user name and password key for accessing the location. These credentials are stored on the Systems Manager Parameter Store. For more information, see [About the feature for creating password parameters](requirements-for-EC2.md#about-EC2Password). If one of the servers (upstream system or license server) requires credentials and the other doesn't, MediaLive presents them to both. But the server that doesn't need them simply ignores them. 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and adds it to the list of inputs. The input specifies either one or two sources. The sources don't appear in the list, but if you choose the **Name** link, the details page shows them. # Ensure correct setup on the HLS upstream server Step 3: Set up upstream An operator at the upstream server must set up the source content on the upstream system. Make sure that the operator sets up as follows: + They set up to deliver the correct number of sources: + If the MediaLive channel is a standard channel, the operator must set up two sources for the content. They must make sure that the two sources are identical in terms of video resolution and bitrate. + If the MediaLive channel is a single-pipeline channel, the operator must set up one source for the content. + They set up to make the M3U8 manifest files available at the agreed URLs. These are the URLs that you obtained in [step 1](setup-input-link-obtain-info.md), and that you configured into the HLS input. They correspond to the URLs shown in [the diagram after this procedure](setup-hls-result.md). # Result of this procedure As a result of this setup, an HLS input exists that specifies one or two *source* URLs. These sources are the URLs for the source content on the upstream server. When you start the channel, MediaLive will connect to the upstream system at this source location or locations and pull the HLS manifests into MediaLive: + For a channel set up as a standard channel, MediaLive expects the upstream system to provide two sources and will therefore attempt to pull from both source locations. + For a channel set up as a single-pipeline channel, MediaLive expects the upstream system to provide one source and will therefore attempt to pull from one source location. ![\[Diagram showing two GET requests to upstream origin servers for curling sports content.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\hls-pull-uss-input.png) # Setting up a MediaConnect input MediaConnect input This section describes how to create a MediaConnect input. With a MediaConnect input, the service provider pushes content through AWS Elemental MediaConnect to MediaLive. (From the point of view of MediaLive, the upstream system is MediaConnect. The upstream system is not the service provider.) To perform this setup, you must work with an AWS Elemental MediaConnect user. **Topics** + [ # Set up AWS Elemental MediaConnect ](setup-emx-flows.md) + [ # Create a MediaConnect input ](setup-input-emx.md) + [ # Result of this procedure ](setup-result-emx.md) # Set up AWS Elemental MediaConnect Step 1: Set up MediaConnect A MediaConnect user must set up MediaConnect with flows to deliver source content to MediaLive. **To set up flows for a standard channel** 1. Provide the MediaConnect user with this information: + Information about the provider of the source content. + The AWS Region for the channel that you that will create. The AWS Elemental MediaConnect flows and the MediaLive channel (and input) must be in the same Region. If the flows and the MediaLive channel aren't in the same Region, then the MediaConnect operator will have to set up a distribution to move the source content to the same Region as the MediaLive input. 1. Discuss with the MediaConnect user whether you need new flows: + You need new flows if the source content doesn't yet have flows in MediaConnect. + You can reuse existing flows so long as you follow these rules: + Each flow doesn't exceed its maximum output bandwidth. + Each flow doesn't exceed its maximum number of outputs from the flow. (MediaLive automatically creates an output on each flow after you create the input in the next step, [Create a MediaConnect input](setup-input-emx.md).) 1. If you decide you need new flows, ask the MediaConnect user to create two flows. + They should assign flow names that are identical except for a suffix. For example, **sports\$1event\$1A** and **sports\$1event\$1B**. These suffixes will help you, the MediaLive user, to match the flows to the input pipelines in MediaLive. + They should set up each flow in a different Availability Zone. (If the flows are in the same Availability Zone then you, the MediaLive user, won't be able to create the MediaLive inputs.) + They should speak to the service provider about the following: + To determine how to complete the source information for each flow. + To make sure that the service provider delivers two sources. + To make sure that the two sources have identical video resolution and bitrate. + They should not create outputs or entitlements. 1. Obtain the following information from the MediaConnect user: + The ARNs for the flows. For example: `arn:aws:mediaconnect:us-west-1:111122223333:flow:1bgf67:sports_event_A` `arn:aws:mediaconnect:us-west-1:111122223333:flow:9pmlk76:sports_event_B` Note that the ARNs include the flow names as the last portion. **To set up flows for a single-pipeline channel** 1. Provide the MediaConnect user with this information: + Information about the provider of the source content. + The AWS Region for the channel that you will create. The AWS Elemental MediaConnect flow and the MediaLive channel (and input) must be in the same Region. If the flow and the MediaLive channel aren't in the same Region, then the MediaConnect operator will have to set up a distribution to move the source content to the same Region as the MediaLive input. 1. Discuss with the MediaConnect user whether you need a new flow: + You need a new flow if the source content doesn't yet have a flow in MediaConnect. + You can reuse an existing flow so long as you follow these rules: + The flow doesn't exceed its maximum output bandwidth. + The flow doesn't exceed its maximum number of outputs from the flow. (MediaLive automatically creates an output on the flow after you create the input in the next step, [Create a MediaConnect input](setup-input-emx.md).) 1. If you decide you need a new flow, ask the MediaConnect user to create one flow. + They should speak to the service provider to determine how to complete the source information for the flow. + They should not create an output or entitlement. 1. Obtain the ARN for the flow from the MediaConnect user. For example: `arn:aws:mediaconnect:us-west-1:111122223333:flow:1bgf67:sports_event_A` Note that the ARN includes the flow name as the last portion. # Create a MediaConnect input Step 2: Create input After MediaConnect is set up, you can create the MediaConnect input. A MediaLive user performs this step. Create your input before you create the channel that ingests the input. **Topics** + [ ## Create the MediaConnect input ](#emx-push-create) + [ ## IAM role and ARN ](#mediaconnect-push-role-and-remember-arn) ## Create the MediaConnect input **To create an input** 1. Make sure that you have the information from [step 1](setup-emx-flows.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **MediaConnect**. 1. Complete the **MediaConnect flows** section: + **Channel and input class** – choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT + **ARN for flow A** – specify the ARN for the flow that you identified as the first flow. If you created a second flow, then for **ARN for flow B**, specify the ARN for the second flow. 1. Complete the **Role ARN** section to choose a role for MediaLive to use with this input. For information, see [IAM role and ARN](#mediaconnect-push-role-and-remember-arn). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. MediaLive always creates two endpoints, even if you specified only one flow (flow A) for the input. 1. At the same time, MediaLive automatically connects to the MediaConnect flows. + If you specified two flows for the input, MediaLive instructs AWS Elemental MediaConnect to create two outputs and attach them to the two flows that you created in the first stage. + If you specified only one flow for the input (to support a single-pipeline channel), MediaLive instructs AWS Elemental MediaConnect to create one output and to attach it to the single flow that you created in the first stage. If MediaConnect has two flows for the channel, it runs the flows in different Availability Zones—one zone for flow A, another zone for flow B. Similarly, MediaLive runs each pipeline in a different Availability Zone—one zone for pipeline A, another zone for pipeline B. MediaLive coordinates with AWS Elemental MediaConnect to ensure that MediaLive runs the channel pipelines in the same two Availability Zones as AWS Elemental MediaConnect. This setup ensures maximum resiliency if one flow fails. ## IAM role and ARN This section describes how to complete the **Role ARN** section on the **Create input** pane of the MediaLive console. You must choose a role for MediaLive to assume when it creates a MediaConnect input. The role ensures that MediaLive succeeds in its request to MediaConnect to create outputs on the flows. MediaLive sends this request as soon as you choose **Create** for this input. **Note** This section on the MediaLive console is identical to the **IAM role** section on the **Create channel** page (also on the MediaLive console). The difference in the two usages is that on the **Create input** page, you are attaching the role to the input. On the **Create channel** page, you are attaching the role to the channel. You can use the same role (for example, the **MediaLiveAccessRole**) in both usages. There are two general scenarios for choosing a role, depending on whether your organization has a designated administrator. ### Your organization has a designated administrator Your organization might have an administrator who manages this service. That administrator has likely set up one or more roles: + Ask the administrator or your manager which role to use. Or if only one role is listed in **Use existing role**, choose that role. + If the only role that is listed is **MediaLiveAccessRole**, choose that role. In addition, if the **Update** button is displayed beside this role name, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. ### Your organization has no administrator Your organization might not have a designated service administrator. In this case, if none of your colleagues have set up a suitable role, you might have to create one yourself and then choose it. + You can create the default role, called **MediaLiveAccessRole**. To first check if someone else has already created this role (only one person needs to create it for all users in your AWS account), look at **Create role from template**: + If this option is grayed out, this task has been done. In that case, choose Use existing role, and then choose **MediaLiveAccessRole** from the list. + If this option is not grayed out, choose **Create role from template**, and then choose **Create IAM role**. Next, choose that role from the list. If MediaLive does not let you create the role, speak to an administrator in your organization about your IAM permissions. + If the **MediaLiveAccessRole** has already been created and the **Update** button is displayed beside it, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. # Result of this procedure The results of this setup are illustrated in the diagram that follows. There are three main components: + The upstream system (purple box) + One or two MediaConnect flows (red boxes). + One MediaConnect input in MediaLive. Each MediaConnect flows has a source that the upstream system is pushing to. Each flow also has one output for the use of MediaLive. The MediaConnect input in MediaLive specifies the ARNs for those outputs. The upstream system pushes the source content to the source on the AWS Elemental MediaConnect flow or flows. The flows push the content to MediaLive. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Diagram showing two flows from upstream system to MediaConnect input in MediaLive.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\emx-push-uss-input.png) # Setting up a MediaConnect Router input MediaConnect Router input This section describes how to create a MediaConnect Router input. With a MediaConnect Router input, the service provider pushes content through AWS Elemental MediaConnect to MediaLive. (From the point of view of MediaLive, the upstream system is MediaConnect. The upstream system is not the service provider.) To perform this setup, you must work with an AWS Elemental MediaConnect user or a user with rights to both services. It's important to note there are several considerations to consider when you want to use a MediaConnect Router input. + First, a MediaConnect Router Input can not be updated. That means its settings are set at creation. + Second, you cannot delete the MediaConnect Router Input if its connected to a router output in MediaConnect. + Finally, a MediaConnect Router Input can only be attached to one router output in MediaConnect. **Topics** + [ # Create a MediaConnect Router input ](setup-input-mediaconnect-router.md) # Create a MediaConnect Router input Step 1: Create input Unlike MediaConnect Inputs, with MediaConnect Router Inputs there is no MediaConnect setup step required to create an input. Instead, you can creating the input in MediaLive makes it available in the MediaConnect router I/O interface as an available destination. Create your input before you create the channel that ingests the input. **Topics** + [ ## Create the MediaConnect input ](#emx-router-create) ## Create the MediaConnect input **To create an input** 1. Make sure that you have the information from [step 1](setup-emx-flows.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **MediaConnect Router**. 1. Complete the **MediaConnect Router Input settings** section: + **Channel and input class** – choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT + **Pipeline 0 Availability Zone** – Specify the availability zone you want your channel to create pipeline 0 in. If you're creating a STANDARD\$1INPUT, then for **Pipeline 1 Availability Zone **, specify the availability zone you want your channel to create pipeline 1 in. + **Do you want to enable custom encryption?** – Specify an AES-256 key in hexadecimal format that's 64 characters: + **Secret Arn** – You can select an existing secret arn you're also going to specify in MediaConnect Router. They must match for the workflow to work. 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically displays the availability zones that input. MediaLive The router output ARN should be empty as this input is not associated. # Setting up an MP4 input MP4 input This section describes how to set up the source content on the upstream system, and how to create an MP4 input that connects the content source to MediaLive. With an MP4 input, MediaLive connects to the upstream system when the channel starts and *pulls* the sources. To perform this setup, you must work with an operator at the upstream system. **Topics** + [ # Obtain information ](setup-mp4-obtain-info.md) + [ # Create an MP4 input ](setup-input-mp4.md) + [ # Ensure correct setup on the MP4 upstream system ](setup-uss-mp4.md) + [ # Result of this procedure ](setup-result-mp4.md) # Obtain information Step 1: Obtain information Obtain the following information from the operator at the upstream system: + The URLs on the upstream system for the source file or files. There are two URLs for a standard-class input, or one URL for a single-class input. For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). See the table later in this section for the URL format and for examples. Make a note of the full URLs. + The user name and password to access the upstream system, if the upstream system requires authenticated requests. Note that these user credentials relate to user authentication, not to the protocol. User authentication is about whether the upstream system will accept your request. The protocol is about whether the request is sent over a secure connection. The following tables show the format of the URLs on the different types of upstream systems that MediaLive supports for MP4 input. **Upstream server is an HTTP or HTTPS server** | | | | --- |--- | | Format of URL | //:/.mp4 | | Example | https://203.0.113.13/filler-videos/oceanwaves.mp4`https://198.51.100.54/filler-videos/oceanwaves.mp4` | **Upstream server is AWS Elemental MediaStore** | | | | --- |--- | | Format of URL | mediastoressl:////.mp4 | | Example | Assume that the data endpoint for the container for one of the content sources is the following: **f31z.data.mediastore.us-west-2.amazonaws.com**. Assume that the file is called `oceanwaves.mp4`, and it is stored in the container, in the path `filler-video`. The URL for one of the source files would be: **mediastoressl://f31z.data.mediastore.us-west-2.amazonaws.com/filler-video/oceanwaves.mp4** | **Upstream server is Amazon S3** | Upstream server | Format of URL | | --- | --- | | Format of URL | s3ssl:////.mp4 | | Example | `s3ssl://amzn-s3-demo-bucket/filler-videos/main/oceanwaves.mp4` `s3ssl://amzn-s3-demo-bucket/filler-videos/redundant/oceanwaves.mp4` With MediaLive, the S3 bucket name must not use dot notation, which means it mustn't use . (dot) between the words in a name. | # Create an MP4 input Step 2: Create input After you have obtained information from the upstream system, you can create an MP4 input. **To create an MP4 pull input** 1. Make sure that you have the information from [step 1](setup-mp4-obtain-info.md). 1. If this input is being used in a multiple-input channel, you should have decided whether to set it up as a static input or a [dynamic input](dynamic-inputs.md). You might need to modify the URLs you obtained from the upstream system: + If the input is a static input, don't modify the URLs. + If the input is a dynamic input, set up the URL as an optional absolute portion and a required variable portion (\$1urlPath\$1). For examples, see the table after this procedure. We recommend that you use the format /\$1urlPath\$1. 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **MP4**. 1. In the **Input class** section, choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT 1. In the **Input sources** section, enter the URLs you previously obtained: + If the input is a standard-class input, complete both fields, to provide two URLs. + If the input is a single-class input, complete the first field with the URL that you obtained and leave the second field empty. If the upstream system requires that you provide user credentials, you must also enter the user name and password key for accessing the location. These credentials are stored on the Systems Manager Parameter Store. For more information, see [About the feature for creating password parameters](requirements-for-EC2.md#about-EC2Password). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and adds it to the list of inputs. The input specifies either one or two sources. The sources don't appear in the list, but if you choose the **Name** link, the details page shows them. ## Formats for the URL in a dynamic input The following table describes the different formats for the URL in a dynamic input. | Format | Description | Example | Example of the \$1urlPath\$1 | | --- | --- | --- | --- | | /\$1urlPath\$1 | URL has only the protocol in the absolute portion | s3ssl://\$1urlPath\$1 | amzn-s3-demo-bucket/my-movie.mp4 | | /\$1urlPath\$1 | URL has the protocol and path in the absolute portion | mediastoressl://f31z.data.mediastore.us-west-2.amazonaws.com/movies/\$1urlPath\$1 | my-movie.mp4 | | \$1urlPath\$1 | URL has only the variable portion | \$1urlPath\$1 | s3ssl://amzn-s3-demo-bucket/my-movie.mp4 | # Ensure correct setup on the MP4 upstream system Step 3: Set up upstream system An operator at the upstream server must set up the source content on the upstream system. Make sure that the operator sets up as follows: + They set up to deliver the correct number of sources: + If the MediaLive channel is a standard channel, the operator must set up two file sources. They must make sure that the two files are identical in terms of video resolution and bitrate. + If the MediaLive channel is a single-pipeline channel, the operator must set up one file source. + They set up to make the content available at the agreed URLs. These URLs are the URLs that you obtained [earlier in this section](setup-mp4-obtain-info.md), and that you configured into the MP4 input. They correspond to the URLs shown in [the diagram after this procedure](setup-result-mp4.md). # Result of this procedure As a result of this setup, a MediaLive input exists that specifies one or two *source* URLs. These sources are the URLs for the source content on the upstream server. When you start the channel, MediaLive will connect to the upstream system at this source location or locations and pull the content: + For a standard channel, MediaLive expects the upstream system to provide two sources and will therefore attempt to pull from both source locations. + For a single-pipeline channel, MediaLive expects the upstream system to provide one source and will therefore attempt to pull from one source location. ![\[Diagram showing MP4 input retrieval from two S3 bucket locations in MediaLive.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/mp4-pull-uss-input.png) # Setting up an RTMP pull input RTMP pull input This section describes how to set up the source content on the upstream system, and how to create an RTMP pull input that connects the upstream system to MediaLive. With an RTMP Pull input, MediaLive connects to the upstream system when the channel starts and *pulls* the sources. To perform this setup, you must work with an operator at the upstream system. **Topics** + [ # Obtain information ](setup-rtmp-pull-obtain-info.md) + [ # Create an RTMP pull input ](setup-input-rtmp-pull.md) + [ # Ensure correct setup on the RTMP upstream system ](setup-uss-rtmp-pull.md) + [ # Result of this procedure ](setup-result-rtmp-pull.md) # Obtain information Step 1: Obtain information Obtain the following information from your contact person at the upstream system: + The application name and application instance for the source content. (The application instance is also known as the *stream* or *stream key*.) There are two sources for a standard-class input , or one source for a single-class input. For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). The operator of the upstream system might already have rules for assigning these names. If not, you might have names that you would like to use. Make sure that you and the operator of the upstream system are clear about these names. In this example, the application name and instance name are identical. But they could be different: Application name: `live`, and instance name `curling` Application name: `live`, and instance name `curling` + The public IP addresses that MediaLive will pull the source content from. These addresses must include port 1935. For example: `rtmp://203.0.113.13:1935` `rtmp://198.51.100.54:1935` + The user name and password to access the upstream system, if the upstream system requires authenticated requests. Note that these user credentials relate to user authentication, not to the protocol. User authentication is about whether the upstream system will accept your request. The protocol is about whether the request is sent over a secure connection. # Create an RTMP pull input Step 2: Create input After you have obtained information from the upstream system, you can create an HLS input. **To create an RTMP pull input** 1. Make sure that you have the information from [step 1](setup-rtmp-pull-obtain-info.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **RTMP (pull)**. 1. In the **Input class** section, choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT 1. In the **Input sources** section, enter the URLs you previously obtained: + If the input is a standard-class input, complete both fields, to provide two URLs. + If the input is a single-class input, complete the first field with the URL that you obtained and leave the second field empty. For example: `rtmp://203.0.113.13:1935/live/curling` If the upstream system requires that you provide user credentials, you must also enter the user name and password key for accessing the location. These credentials are stored on the Systems Manager Parameter Store. For more information, see [About the feature for creating password parameters](requirements-for-EC2.md#about-EC2Password). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and adds it to the list of inputs. The input specifies either one or two sources. The sources don't appear in the list, but if you choose the **Name** link, the details page shows them. When you start the channel, MediaLive will connect to the upstream system at this source location or locations and pull the content: + If you will set up the channel as a standard channel, MediaLive expects the upstream system to provide two sources and will therefore attempt to pull from both source locations. + If you will set up the channel as a single-pipeline channel, MediaLive expects the upstream system to provide one source and will therefore attempt to pull from one source location. # Ensure correct setup on the RTMP upstream system Step 3: Set up upstream An operator at the upstream server must set up the source content on the upstream system. Make sure that the operator sets up as follows: + They set up to deliver the correct number of sources: + If the MediaLive channel is a standard channel, set up two sources for the content. Make sure that the two source contents are identical in terms of video resolution and bitrate. + If the MediaLive channel is a single-pipeline channel, set up one source for the content. + They set up to make the content available at the agreed URLs, and they use the agreed application names and instance names. These URLs are the URLs that you obtained [earlier in this section](setup-mp4-obtain-info.md), and that you configured into the RTMP input. They correspond to the URLs shown in [the diagram after this procedure](setup-result-rtmp-push.md). # Result of this procedure As a result of this setup, an RTMP pull input exists that specifies one or two *source* URLs. These sources are the URLs for the source content on the upstream system. At runtime of the channel, the input will connect to two URLs (for a standard channel) or one URL (for a single-pipeline channel), and pull the source content identified by the application name and instance name into MediaLive. ![\[Diagram showing two GET requests to rtmp URLs for upstream systems input.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\rtmp-pull-uss-input.png) # Setting up an RTMP push input RTMP push input This section describes how to set up an upstream system that uses the RTMP Push protocol to deliver source content from the public internet. It describes how to set up the source content on the upstream system, how to create an input security group, and how to create an input that connects the upstream system to MediaLive. With an RTMP Push input, the upstream system *pushes* the content to MediaLive. To perform this setup, you must work with an operator at the upstream system. **Topics** + [ # Obtain information ](setup-rtmp-push-obtain-info.md) + [ # Create an input security group ](setup-isg-rtmp.md) + [ # Create an RTMP push input ](setup-input-rtmp-push.md) + [ # Ensure correct setup on the upstream system ](setup-uss-rtmp-push.md) + [ # Result of this procedure ](setup-result-rtmp-push.md) # Obtain information Step 1: Obtain information Obtain the following information from your contact person at the upstream system: + The application name and application instance for the source content. (The application instance is also known as the *stream* or *stream key*.) There are two sources for a standard-class input, or one source for a single-class input. For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). The operator of the upstream system might already have rules for assigning these names. If not, you might have names that you would like to use. Make sure that you and the operator of the upstream system are clear about these names. In this example, the application name and instance name are identical. But they could be different: Application name: `live`, and instance name `curling` Application name: `live`, and instance name `curling` + The public network IP addresses. These are the sets of IP addresses where the source or sources for the content will appear on the public network. You need this information to create the input security group. For example: + For one source: `203.0.113.19, 203.0.113.58, 203.0.113.25` + For the other source: `198.51.100.19, 198.51.100.59, 198.51.100.21` These addresses are the addresses shown in the red boxes in [the diagram after this procedure](setup-result-rtmp-push.md). # Create an input security group Step 2: Create input security group You must create an input security group. The security group must allow the *public network IP addresses* to push to MediaLive. Following from the earlier example, it must allow these addresses: 203.0.113.19, 203.0.113.58, 203.0.113.25, 198.51.100.19, 198.51.100.59, 198.51.100.21 For details about creating an input security group, see [Creating an input security group](create-input-security-groups.md). # Create an RTMP push input Step 3: Create input After you have created the input security group, you can create the RTMP push input. **To create an RTMP push input** 1. Make sure that you have the information from [step 1](setup-rtmp-push-obtain-info.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. 1. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **RTMP (push)**. 1. In the **Network mode** section, choose **Public**. 1. In the **Input security group** section, specify the group to attach to this push input. You can choose an existing group, or you can create a group. The security group must allow the public network IP addresses to push to MediaLive. Following from the example in step 1, it must allow these addresses: 203.0.113.19, 203.0.113.58, 203.0.113.25, 198.51.100.19, 198.51.100.59, 198.51.100.21 For more information about security groups, see [Working with input security groups](working-with-input-security-groups.md). 1. In the **Channel and input class** section, choose the class for this input: + STANDARD + SINGLE-PIPELINE For more information, see [Implementing pipeline redundancy](plan-redundancy-mode.md). 1. In the **Input destinations** section, in the **Destination** section, enter the application names and application instances you previously obtained: + If the input is a standard-class input, complete both fields, to specify two sources. + If the input is a single-class input, complete the first field with the information that you obtained and leave the second field empty. For example: **Application name: **`live` **Application instance:** `curling` 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. The endpoints include the application name, the application instance, and the port 1935. For example: `198.51.100.99:1935/live/curling` `192.0.2.18:1935/live/curling` Note that the IP addresses are addresses that MediaLive creates. They aren't the public addresses that you used in the security group. For a diagram that shows the role of all the IP addresses, see [Result of this procedure](setup-result-rtmp-push.md) in the section about setting up an RTMP push source. MediaLive always creates two endpoints: + If you will set up the channel as a standard channel, both endpoints will be used. + If you will set up the channel as a single-pipeline channel, only the first endpoint will be used. MediaLive won't expect to receive content at the second endpoint. # Ensure correct setup on the upstream system Step 4: Set up upstream system You must make sure that the upstream system pushes content to the correct locations in MediaLive. **To set up for a standard channel** Follow this procedure if the MediaLive channel is a [standard channel](plan-redundancy.md). 1. Provide the operator with this information: + The two endpoints (URLs) that MediaLive generated when you created the RTMP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-result-rtmp-push.md). The URLs include port 1935. For example: `198.51.100.99:1935/live/curling` `192.0.2.18:1935/live/curling` 1. Make sure that the operator sets up properly for a single-pipeline channel or a standard channel. If your channel is a single-pipeline channel, the operator delivers only one source, even though the input is a standard (dual-pipeline) input. The operator must do the following: + Deliver one source. + Make sure that the sources appear on the agreed IP addresses on the public network. For example: + The sources could appear on these addresses: `203.0.113.19, 203.0.113.58, 203.0.113.25` + The operator can ignore the other addresses: `198.51.100.19, 198.51.100.59, 198.51.100.21` You used these addresses when you created the input security group. If the upstream system doesn't use these addresses, MediaLive will refuse the push. + Push to one URL on MediaLive, and use the agreed application name and instance name. For example: Push to this URL: `198.51.100.99:1935/live/curling` Ignore the other URL: `192.0.2.18:1935/live/curling` If your channel is a standard channel, the operator must do the following: + Deliver two sources that are identical in terms of video resolution and bitrate. + Make sure that the sources appear on the agreed IP addresses on the public network. For example: + For one source: `203.0.113.19, 203.0.113.58, 203.0.113.25` + For the other source: `198.51.100.19, 198.51.100.59, 198.51.100.21` You used these addresses when you created the input security group. If the upstream system doesn't use these addresses, MediaLive will refuse the push. + Push to the correct URLs on MediaLive, and use the agreed application name and instance name. For example, they must push to: `198.51.100.99:1935/live/curling` `192.0.2.18:1935/live/curling` # Result of this procedure As a result of this setup, an RTMP push input exists that specifies one or two *endpoint* URLs. These endpoints are on MediaLive and are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). The upstream system has been set up to push the source content to the two endpoints (for a standard channel) or to the first endpoint (for a single-pipeline channel). An input security group has been associated with the input. This input security group has a CIDR block that covers the IP addresses where the pushed source will appear on the public network, which ensures that MediaLive accepts the pushed content. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Upstream system diagram showing IP addresses and RTMP inputs for MediaLive streaming.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\rtmp-push-uss-input.png) # Setting up an RTMP VPC input RTMP VPC input This section describes how to set up content that uses the RTMP Push protocol to deliver source content from an upstream system that is in your VPC from Amazon Virtual Private Cloud (Amazon VPC). This section describes how to set up the source content on the upstream system, and how to create an input that connects the upstream system to MediaLive. With an RTMP Push input, the upstream system *pushes* the content to MediaLive. To perform this setup, you must work with an Amazon VPC user, and with an operator at the upstream system. **Topics** + [ # Request setup on the VPC ](setup-vpc-rtmp-vpc.md) + [ # Create an RTMP input ](setup-input-rtmp-vpc.md) + [ # Ensure correct setup on the upstream system ](setup-uss-rtmp-vpc.md) + [ # Result of this procedure ](setup-rtmp-vpc-result.md) # Request setup on the VPC Step 1: Set up VPC An Amazon VPC user must set up the VPC, and identify subnets and security groups that the upstream system and MediaLive will use. **To set up the VPC** 1. Provide the Amazon VPC user with the following guidelines. + Guideline for the subnets – Request two subnets. These rules apply: + The two subnets must be in different Availability Zones. + Each subnet must have a private CIDR block (a range of IP addresses). + Each subnet must have at least two unused addresses in that block—one for the upstream system and one for the RTMP input. + Any other VPC-based sources (source B) that you create for use in the same channel as this RTMP source (source A) must be in subnets that are in the same Availability Zones as source A. The two subnets of the source B can be different from the source A, but the Availability Zones of those two subnets must be the same as the Availability Zones of source A. + Guideline for the security group – The security group or groups for each subnet must follow these rules: + The combined rules of the security groups must allow inbound traffic from the IP addresses of the upstream system in that subnet. + The combined rules of the security groups must allow outbound traffic to port 1935. 1. After the Amazon VPC user has performed the setup, obtain the following information: + The ID of the VPC. For example: `vpc-3f139646` + The IDs of the two subnets. For example, one subnet might have this ID: `subnet-1122aabb` + The IDs of the security groups for the subnet or subnets. For example: `sg-51530134` # Create an RTMP input Step 2: Create input After the Amazon VPC user has set up on the VPC, you can create the RTMP VPC push input in MediaLive. **Topics** + [ ## Create an RTMP VPC push input ](#rtmp-push-vpc-create) + [ ## IAM role and ARN ](#rtmp-push-role-and-remember-arn) ## Create an RTMP VPC push input **To create an RTMP VPC push input** 1. Make sure that you have the information from [step 1](setup-vpc-rtmp-vpc.md). 1. You should also have obtained information from the provider of the video content: the application name and application instance for the source content. (The application instance is also known as the *stream* or *stream key*.) For example: Application name: `live`, and instance name `curling` 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. 1. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **RTMP (push)**. 1. In the **Network mode** section, choose **VPC**. 1. Complete the **VPC settings** section: + Choose **Select subnets and security groups**. + For **Subnets**, choose one of the subnets that you obtained. The dropdown list shows subnets in all VPCs, identified as follows: ` ` For example: **subnet-1122aabb us-west-2a 10.1.128.0/24 vpc-3f139646 Subnet for MLive push inputs** If the list of subnets is empty, choose **Specify custom VPC**, and enter the subnet ID in the field. (You need to enter only the subnet ID, for example, **subnet-1122aabb**.) + In **Subnets**, choose the second subnet. This second time, the dropdown list shows only the subnets in the same VPC as the first subnet. + For **Security groups**, choose the security group or groups that you obtained, following the same process as for the subnets. The dropdown list shows security groups belonging to the VPC that you chose, identified as follows: ` ` For example: **sg-51530134 Security group for MLive push inputs vpc-3f139646** 1. Complete the **Role ARN** section to choose a role for MediaLive to use with this input. For more information, see [IAM role and ARN](setup-input-rtp-vpc.md#rtp-push-role-and-remember-arn). 1. In the **Input class** section, choose the class for this input: + STANDARD + SINGLE-PIPELINE 1. In the **Input destinations** section, in the **Destination** section, enter the application names and application instances you previously set up: + If the input is a standard-class input, complete both fields, to specify two sources. + If the input is a single-class input, complete the first field with the information that you obtained and leave the second field empty. For example: **Application name: **`live` **Application instance:** `curling` 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. These endpoints have a private IP address from the subnet range, and they specify port 1935. For example: `10.12.30.44:1935/live/curling` `10.99.39.15:1935/live/curling` 1. Provide the upstream system with these endpoints: + If you will set up the channel as a standard channel, provide both endpoints. The upstream system must push the content to both endpoints. + If you will set up the channel as a single-pipeline channel, provide only the first endpoint. The upstream system must push to this one endpoint. For example, provide these addresses: `10.12.30.44:1935/live/curling` `10.99.39.15:1935/live/curling` **Result of these procedures** As a result of this setup, each output of the upstream system has an IP address in one of the specified subnets in your VPC. The RTMP input has two IP addresses. These addresses are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). Each address is in one of those subnets. In this way, the delivery of the content from the upstream system to MediaLive takes place within the security of the VPC. For a description of this setup that includes a diagram, see [Result of this procedure](setup-rtmp-vpc-result.md) in the section about setting up an RTMP VPC source. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. ## IAM role and ARN This section describes how to complete the **Role ARN** section on the **Create input** pane of the MediaLive console. You must choose a role for MediaLive to assume when it creates an RTMP Push input. To create the input, MediaLive must obtain the network interfaces for the two endpoints in the input. These endpoints are in the CIDR range of the subnets that you identified. As soon as you choose **Create** for this input, MediaLive requests these network interfaces from Amazon VPC. The role that you choose ensures that MediaLive succeeds in its request to Amazon VPC. **Note** This section on the MediaLive console is identical to the **IAM role** section on the **Create channel** page (also on the MediaLive console). The difference in the two usages is that on the **Create input** page, you are attaching the role to the input. On the **Create channel** page, you are attaching the role to the channel. You can use the same role (for example, the **MediaLiveAccessRole**) in both usages. There are two general scenarios for choosing a role, depending on whether your organization has a designated administrator. ### Your organization has a designated administrator Your organization might have an administrator who manages this service. That administrator has likely set up one or more roles: + Ask the administrator or your manager which role to use. Or if only one role is listed in **Use existing role**, choose that role. + If the only role that is listed is **MediaLiveAccessRole**, choose that role. In addition, if the **Update** button is displayed beside this role name, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. ### Your organization has no administrator Your organization might not have a designated service administrator. In this case, if none of your colleagues have set up a suitable role, you might have to create one yourself and then choose it. + You can create the default role, called **MediaLiveAccessRole**. To first check if someone else has already created this role (only one person needs to create it for all users in your AWS account), look at **Create role from template**: + If this option is grayed out, this task has been done. In that case, choose **Use existing role**, and then choose **MediaLiveAccessRole** from the list. + If this option is not grayed out, choose **Create role from template**, and then choose **Create IAM role**. Next, choose that role from the list. If MediaLive does not let you create the role, speak to an administrator in your organization about your IAM permissions. + If the **MediaLiveAccessRole** has already been created and the **Update** button is displayed beside it, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. # Ensure correct setup on the upstream system Step 3: Set up upstream system You must make sure that the upstream system sets up correctly with your VPC and pushes content to the correct locations in MediaLive. **To set up for a standard channel** Follow this procedure if the MediaLive channel is a [standard channel](plan-redundancy.md). 1. Provide the operator with this information: + The IDs of the VPC, two subnets, and the security groups that the Amazon VPC user gave you. + The two endpoints (URLs) that MediaLive generated when you created the RTMP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-rtmp-vpc-result.md). The URL has a private IP address and includes port 1935. For example: `10.12.30.131:1935/live/curling` `10.99.39.40:1935/live/curling` 1. Make sure that the operator sets up properly for a standard channel. They must do the following: + Set up two separate upstream systems. They can't set up one upstream system with two output interfaces because you, the MediaLive user, will lose the redundancy that you want to achieve with a standard channel (with two independent pipelines). + Set up two output interfaces—one output interface in one of the subnets, and set up the other upstream system with one output interface in the other subnet. These interfaces are the addresses in the purple boxes in [the diagram after this procedure](setup-rtmp-vpc-result.md). + Make sure that the two content sources are identical in terms of video resolution and bitrate. + Push to the correct URLs on MediaLive, and use the agreed application name and instance name. For example, they must push to: `10.12.30.131:1935/live/curling` `10.99.39.40:1935/live/curling` **To set up for a single-pipeline channel** Follow this procedure if the MediaLive channel is a [single-pipeline channel](plan-redundancy.md). 1. Provide the operator with this information: + The IDs of the VPC, one subnet, and the security groups that the Amazon VPC user gave you. + Only the first of the two endpoints (URLs) that MediaLive generated when you created the RTMP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-rtmp-vpc-result.md). The URL has a private IP address and includes port 1935. For example: `10.12.30.131:1935/live/curling` 1. Make sure that the operator sets up properly for a single-pipeline channel. They must do the following: + Set up one upstream system. + Set up one output interface. The interface is the address in one of the purple boxes in [the diagram after this procedure](setup-rtmp-vpc-result.md). + Push to the correct URL on MediaLive. For example, they must push to: `10.12.30.131:1935/live/curling` # Result of this procedure As a result of this setup, an RTMP input exists that specifies one or two *endpoint* URLs. These addresses are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). These endpoints are elastic network interfaces on your VPC. MediaLive has permission to use these network interfaces for its inputs. MediaLive has permission (through the IAM trusted entity role) to automatically manage the network interfaces for its inputs. The upstream system has permission, through the Amazon VPC security group, to push content to these endpoints. The upstream system or systems have been set up to push the source content to the two endpoints (if you are setting up for a standard channel) or to one endpoint (if you are setting up for a single-pipeline channel). At least one VPC security group has been associated with each subnet. The CIDR block in each security group covers the two URLs that the upstream system pushes from, which ensures that MediaLive accepts the pushed content. Each output of the upstream system has an IP address in one of the specified subnets in your VPC. The RTMP input has two IP addresses, and each address is in one of those subnets. In this way, the delivery of the source content from the upstream system to MediaLive takes place within the privacy of the VPC. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Diagram showing RTMP input in MediaLive with upstream systems connecting to VPC subnets.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\rtmp-vpc-uss-input.png) # Setting up an RTP push input RTP push input This section describes how to set up an upstream system that uses the RTP Push protocol to deliver source content from an upstream system that is in your VPC from Amazon VPC. It describes how to set up the source content on the upstream system, and how to create an input that connects the upstream system to MediaLive. With an RTP push source, the upstream system *pushes* the content to MediaLive. To perform this setup, you must work with an operator at the upstream system. **Topics** + [ # Obtain information ](setup-rtp-push-obtain-info.md) + [ # Create an input security group ](setup-isg-rtp-push.md) + [ # Create an RTP input ](setup-input-rtp-push.md) + [ # Ensure correct setup on the upstream system ](setup-uss-rtp-push.md) + [ # Result of this procedure ](setup-result-rtp-push.md) # Obtain information Step 1: Obtain information Obtain the following information from your contact person at the upstream system: + The public network IP addresses. You need two sets of IP addresses because an RTP input is always a [standard-class input](class-channel-input.md), even if your channel is a single-pipeline channel. For information about input classes, see [Choosing the channel class and input class](class-channel-input.md). These are the sets of IP addresses where the source or sources for the content will appear on the public network. You need this information to create the input security group. For example: + For one source: `203.0.113.19, 203.0.113.58, 203.0.113.25` + For the other source: `198.51.100.19, 198.51.100.59, 198.51.100.21` # Create an input security group Step 2: Create an input security group You must create an input security group. The security group must allow the *public network IP addresses* to push to MediaLive. Following from the earlier example, it must allow these addresses: 203.0.113.19, 203.0.113.58, 203.0.113.25, 198.51.100.19, 198.51.100.59, 198.51.100.21 For details about creating an input security group, see [Creating an input security group](create-input-security-groups.md). # Create an RTP input Step 3: Create input After you have created the input security group, you can create the RTP push input. **To create an RTP push input** 1. Make sure that you have the information from [step 1](setup-rtp-push-obtain-info.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **RTP**. 1. In the **Network mode** section, choose **Public**. 1. In the **Input security group** section, specify a group to attach to this push input. You can choose an existing group, or you can create a group. For more information about security groups, see [Working with input security groups](working-with-input-security-groups.md). The security group must allow the public network IP addresses to push to MediaLive. Following from the example in step 1, it must allow these addresses: 203.0.113.19, 203.0.113.58, 203.0.113.25, 198.51.100.19, 198.51.100.59, 198.51.100.21 For more information about security groups, see [Working with input security groups](working-with-input-security-groups.md). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. These endpoints include the port 5000. For example: `198.51.100.99:5000` `192.0.2.18:5000` Note that the IP addresses are addresses that MediaLive creates. They aren't the public addresses that you used in the security group. For a diagram that shows the role of all the IP addresses, see [Result of this procedure](setup-result-rtp-push.md) in the section about setting up an RTP push source. MediaLive always creates two endpoints: + If you will set up the channel as a standard channel, both endpoints will be used. + If you will set up the channel as a single-pipeline channel, only the first endpoint will be used. MediaLive won't expect to receive content at the second endpoint. 1. Provide the upstream system with the following information: + If you will set up the channel as a standard channel, provide both locations. The upstream system must push the video streams to these locations. + If you will set up the channel as a single-pipeline channel, provide only the first location. The upstream system must push its one stream to this location. For example, provide these addresses: `198.51.100.99:5000` `192.0.2.18:5000` **Result of this procedure** As a result of this setup, an RTP push input exists that specifies two URLs. These URLs are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). The upstream system pushes the source content to these endpoints. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. For a description of this setup that includes a diagram, see [Result of this procedure](setup-result-rtp-push.md) in the section about setting up an RTP source. # Ensure correct setup on the upstream system Step 4: Set up upstream system You must make sure that the upstream system pushes content to the correct locations in MediaLive. **To set up for a standard channel** Follow this procedure if the MediaLive channel is a [standard channel](plan-redundancy.md). 1. Provide the operator with this information: + The two endpoints (URLs) that MediaLive generated when you created the RTP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-result-rtp-push.md). The URLs include port 5000. For example: `198.51.100.99:5000` `192.0.2.18:5000` 1. Make sure that the operator sets up properly for a standard channel. They must: + Deliver two sources that are identical in terms of video resolution and bitrate. + Make sure that the sources appear on the agreed IP addresses on the public network. For example: + For one source: `203.0.113.19, 203.0.113.58, 203.0.113.25` + For the other source: `198.51.100.19, 198.51.100.59, 198.51.100.21` You used these addresses when you created the input security group. If the upstream system doesn't use these addresses, MediaLive will refuse the push. + Push to the correct URLs on MediaLive. For example, they must push to: `198.51.100.99:5000` `192.0.2.18:5000` + Send over RTP, not UDP. The UDP protocol is not supported for an input into MediaLive. **To set up for a single-pipeline channel** Follow this procedure if the MediaLive channel is a [single-pipeline channel](plan-redundancy.md). 1. Provide the operator with this information: + Only the first of the two endpoints (URLs) that MediaLive generated when you created the RTP input. This endpoint is one of the addresses in the blue boxes in [the diagram after this procedure](setup-result-rtp-push.md). The URL includes port 5000. For example: `198.51.100.99:5000` 1. Make sure that the operator sets up properly for a single-pipeline channel. They must: + Make sure that the source appears on the agreed IP addresses on the public network. For example: `203.0.113.19, 203.0.113.58, 203.0.113.25` You used these addresses when you created the input security group. If the upstream system doesn't use these addresses, MediaLive will refuse the push. + Push to the correct URL on MediaLive. For example, they must push to: `198.51.100.99:5000` + Send over RTP, not UDP. The UDP protocol is not supported for an input into MediaLive. # Result of this procedure As a result of this setup, an RTP input exists that specifies one or two *endpoint* URLs. These endpoints are on MediaLive and are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). The upstream system has been set up to push the source content to the two endpoints (for a standard channel) or to the first endpoint (for a single-pipeline channel). An input security group has been associated with the input. This input security group has a CIDR block that covers the two URLs that the upstream system pushes, which ensures that MediaLive accepts the pushed content. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Upstream system diagram showing IP addresses, RTP inputs, and Input Security Group.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/rtp-push-uss-input.png) # Setting up an RTP VPC input RTP VPC input This section describes how to set up an upstream system that uses the RTP Push protocol to deliver source content from an upstream system that is in your Amazon Virtual Private Cloud (Amazon VPC). It describes how to set up the source content on the upstream system, and how to create an input that connects the upstream system to MediaLive. With an RTP VPC source, the upstream system *pushes* the content to MediaLive. To perform this setup, you must work with an Amazon VPC user, and with an operator at the upstream system. **Topics** + [ # Request setup on the VPC ](setup-vpc-rtp-vpc.md) + [ # Create an input for RTP push from Amazon VPC ](setup-input-rtp-vpc.md) + [ # Ensure correct setup on the upstream system ](setup-uss-rtp-vpc.md) + [ # Result of this procedure ](setup-rtp-vpc-result.md) # Request setup on the VPC Step 1: Set up VPC An Amazon VPC user must set up the VPC, and identify subnets and security groups that the upstream system and MediaLive will use. **To set up the VPC** 1. Provide the Amazon VPC user with the following guidelines. + Guideline for the subnets – Request two subnets. These rules apply: + You need two subnets because an RTP input is always a [standard-class input](class-channel-input.md), even if your channel is a single-pipeline channel. For information about input classes, see [Choosing the channel class and input class](class-channel-input.md). + The two subnets must be in different Availability Zones. + Each subnet must have a private CIDR block (a range of IP addresses). + Each subnet must have at least two unused addresses in that block—one for the upstream system and one for the RTP input. + Any other VPC-based sources (source B) that you create for use in the same channel as this RTP source (source A) must be in subnets that are in the same Availability Zones as source A. The two subnets of the source B can be different from the source A, but the Availability Zones of those two subnets must be the same as the Availability Zones of source A. + Guideline for the security group – The security group or groups for each subnet must follow these rules: + The combined rules of the security groups must allow inbound traffic from the IP addresses of the upstream system in that subnet. + The combined rules of the security groups must allow outbound traffic to port 5000. 1. After the Amazon VPC user has performed the setup, obtain the following information: + The ID of the VPC. For example: `vpc-3f139646` + The IDs of the two subnets. For example, one subnet might have this ID: `subnet-1122aabb` + The IDs of the security groups for the subnets. For example: `sg-51530134` # Create an input for RTP push from Amazon VPC Step 2: Create input After the Amazon VPC user has set up on the VPC, you can create the RTP VPC push input in MediaLive. **Topics** + [ ## Create the RTP input ](#rtp-vpc-push-create) + [ ## IAM role and ARN ](#rtp-push-role-and-remember-arn) ## Create the RTP input **To create an RTP VPC push input from Amazon VPC** 1. Make sure that you have the information from [step 1](setup-vpc-rtp-vpc.md). + The ID of the VPC. + The IDs of the two subnets. + The IDs of the security groups for the subnet or subnets. 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. 1. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **RTP**. 1. In the **Network mode** section, choose **VPC**. 1. Complete the **VPC settings** section: + Choose **Select subnets and security groups**. + For **Subnets**, choose one of the subnets that you obtained. The dropdown list shows subnets in all VPCs, identified as follows: ` ` For example: **subnet-1122aabb us-west-2a 10.1.128.0/24 vpc-3f139646 Subnet for MLive push inputs** If the list of subnets is empty, choose **Specify custom VPC**, and enter the subnet ID in the field. (You need to enter only the subnet ID, for example, **subnet-1122aabb**.) + In **Subnets**, choose the second subnet. This second time, the dropdown list shows only the subnets in the same VPC as the first subnet. + For **Security groups**, choose the security group or groups that you obtained, following the same process as for the subnets. The dropdown list shows security groups belonging to the VPC that you chose, identified as follows: ` ` For example: **sg-51530134 Security group for MLive push inputs vpc-3f139646** 1. Complete the **Role ARN** section to choose a role for MediaLive to use with this input. For more information, see [IAM role and ARN](#rtp-push-role-and-remember-arn). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. These endpoints have a private IP address from the subnet range, and they specify port 5000. For example: `rtp://10.12.30.44:5000` `rtp://10.99.39.15:5000`. 1. Provide the upstream system with these endpoints: + If you will set up the channel as a standard channel, provide both endpoints. The upstream system must push the content to both endpoints. + If you will set up the channel as a single-pipeline channel, provide only the first endpoint. The upstream system must push to this one endpoint. **Result of these procedures** As a result of this setup, each output of the upstream system has an IP address in one of the specified subnets in your VPC. The RTP input has two IP addresses. These addresses are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). Each address is in one of those subnets. In this way, the delivery of the content from the upstream system to MediaLive takes place within the security of the VPC. For a description of this setup that includes a diagram, see [Result of this procedure](setup-rtp-vpc-result.md) in the section about setting up an RTP VPC source. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. ## IAM role and ARN This section describes how to complete the **Role ARN** section on the **Create input** pane of the MediaLive console. You must choose a role for MediaLive to assume when it creates an RTP Push input. To create the input, MediaLive must obtain the network interfaces for the two endpoints in the input. These endpoints are in the CIDR range of the subnets that you identified. As soon as you choose **Create** for this input, MediaLive requests these network interfaces from Amazon VPC. The role that you choose ensures that MediaLive succeeds in its request to Amazon VPC. **Note** This section on the MediaLive console is identical to the **IAM role** section on the **Create channel** page (also on the MediaLive console). The difference in the two usages is that on the **Create input** page, you are attaching the role to the input. On the **Create channel** page, you are attaching the role to the channel. You can use the same role (for example, the **MediaLiveAccessRole**) in both usages. There are two general scenarios for choosing a role, depending on whether your organization has a designated administrator. ### Your organization has a designated administrator Your organization might have an administrator who manages this service. That administrator has likely set up one or more roles: + Ask the administrator or your manager which role to use. Or if only one role is listed in **Use existing role**, choose that role. + If the only role that is listed is **MediaLiveAccessRole**, choose that role. In addition, if the **Update** button is displayed beside this role name, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. ### Your organization has no administrator Your organization might not have a designated service administrator. In this case, if none of your colleagues have set up a suitable role, you might have to create one yourself and then choose it. + You can create the default role, called **MediaLiveAccessRole**. To first check if someone else has already created this role (only one person needs to create it for all users in your AWS account), look at **Create role from template**: + If this option is grayed out, this task has been done. In that case, choose **Use existing role**, and then choose **MediaLiveAccessRole** from the list. + If this option is not grayed out, choose **Create role from template**, and then choose **Create IAM role**. Next, choose that role from the list. If MediaLive does not let you create the role, speak to an administrator in your organization about your IAM permissions. + If the **MediaLiveAccessRole** has already been created and the **Update** button is displayed beside it, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. # Ensure correct setup on the upstream system Step 3: Set up upstream system You must make sure that the upstream system sets up correctly with your VPC and pushes content to the correct locations in MediaLive. **To set up for a standard channel** Follow this procedure if the MediaLive channel is a [standard channel](plan-redundancy.md). 1. Provide the operator with this information: + The IDs of the VPC, two subnets, and the security groups that the Amazon VPC user gave you. + The two endpoints (URLs) that MediaLive generated when you created the RTP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). The URLs have private IP addresses and include port 5000. For example: `10.12.30.44:5000` `10.99.39.15:5000` 1. Make sure that the operator sets up properly for a standard channel. They must: + Set up two output interfaces—one output interface in one of the subnets, and set up the other upstream system with one output interface in the other subnet. These interfaces are the addresses in the purple boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). + Deliver two sources that are identical in terms of video resolution and bitrate. + Push to the correct URLs on MediaLive. For example, they must push to: `10.12.30.131:5000` `10.99.39.40:5000` + Send over RTP, not UDP. The UDP protocol is not supported for an input into MediaLive. **To set up for a single-pipeline channel** Follow this procedure if the MediaLive channel is a [single-pipeline channel](plan-redundancy.md). 1. Provide the operator with this information: + The IDs of the VPC, one subnet, and the security groups that the Amazon VPC user gave you. + Only the first of the two endpoints (URLs) that MediaLive generated when you created the RTP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). The URL has a private IP address and includes port 5000. For example: `10.12.30.44:5000` `10.99.39.15:5000` 1. Make sure that the operator sets up properly for a standard channel. They must: + Set up one output interface. The interface is the address in one of the purple boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). + Push to the correct URL on MediaLive. For example, they must push to: `10.12.30.131:5000` `10.99.39.40:5000` + Send over RTP, not UDP. The UDP protocol is not supported for an input into MediaLive. # Result of this procedure As a result of this setup, an RTP input exists that specifies one or two *endpoint* URLs. These endpoints are elastic network interfaces (ENIs) on your VPC. MediaLive has permission to use these ENIs for its inputs. MediaLive has permission (through the IAM trusted entity role) to automatically manage the ENIs for its inputs. The upstream system has permission, through the Amazon VPC security group, to push content to these endpoints. Each address is in one of those subnets. In this way, the delivery of the content from the upstream system to MediaLive takes place within the security of the VPC. The upstream system or systems have been set up to push the source content to the two endpoints (if you are setting up for a standard channel) or to one endpoint (if you are setting up for a single-pipeline channel). At least one VPC security group has been associated with each subnet. The CIDR block in each security group covers the two URLs that the upstream system pushes from, which ensures that MediaLive accepts the pushed content. Each output of the upstream system has an IP address in one of the specified subnets in your VPC. The RTP input has two IP addresses, and each address is in one of those subnets. In this way, the delivery of the source content from the upstream system to MediaLive takes place within the privacy of the VPC. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Diagram showing RTP input from upstream systems to MediaLive through VPC subnets.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/rtp-vpc-uss-input.png) # Creating a SMPTE 2110 input SMPTE 2110 inputSMPTE 2110 inputs The guide now includes information about working with SMPTE 2110 inputs. This section describes how to set up the source content on the upstream system, and how to create an SMPTE 2110 input that connects the upstream system to MediaLive. Create the input before you create the channel that ingests the input. **Note** SMPTE 2110 inputs are supported only on AWS Elemental MediaLive Anywhere deployments. For more information about these deployments, see [Setting up AWS Elemental MediaLive Anywhere](setup-emla.md). With an SMPTE 2110 input, MediaLive connects to the multicast IP address when the channel starts and *pulls* the sources. To perform this setup, you must work with the video engineer in your organization who created the SDP files for the SMPTE 2110 source. **Topics** + [ # Obtain information ](setup-s2110-pull-obtain-info.md) + [ # Create a SMPTE 2110 input ](setup-input-s2110-pull.md) # Obtain information Step 1: Obtain information Obtain the following information from the video engineer who created the SMPTE 2110 SDP files: + The location (URL) and file name of all the SDP files for the video, audio, and ancillary streams for the SMPTE 2110 source. There should be only one video SDP file. There can be 0 or more audio SDP files, and 0 or more ancillary SDP files. + The number of video lines (v=) in the single video SDP file. If there is more than one video line, find out which line you must use. You need the number of lines because you will need to identify the line to use by specifying its position in a zero-based media index. For example, if you need to use the third video line, the index is 2. + The number of audio lines (a=) in each audio SDP file. You need the number of lines because you will need to create a zero-based media index of the audio lines whenever there is more than one SDP file, and/or whenever there is more than one audio line in an SDP file. For example, there might be two audio SDP files, one with one lines and one with two lines. For the first file, you will create an index with one member (0), and for the second file you will create an index with members 0 and 1. + A list of the audio selectors you must create and the IDs of the channel groups (audio tracks) to include in each selector. (You don't need this information for video or ancillary streams.) MediaLive assigns a track number to each channel group, starting with the first channel group in the first line in the first SDP file, and covering all the audio lines in all the audio SDP files. The tracks are numbered from 1. # Create a SMPTE 2110 input Step 2: Create input After you have obtained information from the upstream system, you can create a SMPTE 2110 input. **To create an SMPTE 2110 input** 1. Make sure that you have the information from [step 1](setup-s2110-pull-obtain-info.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **SMPTE 2110 Receiver Group** section as described in the table that follows this procedure. 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and adds it to the list of inputs. The input identifies the locations of the SDP files that contain information about the SMPTE 2110 streams. When you start the channel, MediaLive will retrieve the SDP files. It will obtain the location of the SMPTE 2110 streams from the files. It will connection to those locations and pull the content that you specified when you [attach the input to the channel](creating-a-channel-step2.md). **Fields for a SMPTE 2110 input** | Field | Description | | --- | --- | | Video SDP | Enter the URL for the video SDP file. If you obtained a number that identifies the video line to extract, enter it in the Media index field. This index is zero-based. So if you need to extract the third line, enter 2. | | Audio SDPs | Enter information for each for each audio SDP file and audio line combination.See the example after this table. | | Ancillary SDPs | Enter information for each for each ancillary SDP file and audio line combination.See the example after this table. | You might have obtained the following information about the SDP files and their media lines: + One video file at `http://172.18.8.19/curling_video.sdp`. You need to extract the third video (index member 2). + The following audio SDP files and their audio lines: `http://172.18.8.19/curling_audio_1.sdp` with one audio line. `http://172.18.8.19/curling_audio_2.sdp`, with two media lines. + One ancillary SDP file and their ancillary lines: `http://172.18.8.19/curling_ancill.sdp` with two media lines. You will set up the Receiver Group fields as follows: | SDP | SDP URL | Media index | | --- | --- | --- | | Video SDP | http://172.18.8.19/curling\$1video.sdp | 2 | | Audio SDP | http://172.18.8.19/curling\$1audio\$11.sdp | 0 | | | http://172.18.8.19/curling\$1audio\$12.sdp | 0 | | | http://172.18.8.19/curling\$1audio\$12.sdp | 1 | | Ancillary SDP | http://172.18.8.19/curling\$1ancill.sdp | 0 | | | http://172.18.8.19/curling\$1ancill.sdp | 0 | # Setting up an SRT Caller input SRT Caller inputWorking with SRT Caller input The guide now includes information about working with SRT Caller inputs. This section describes how to set up to ingest transport stream (TS) content that is sent from an upstream system that is set up as an SRT listener. This section describes how to set up the source content on the upstream system, and how to create an input that connects the upstream system to MediaLive. The transport stream source can be encrypted with AES. **Roles** With an SRT input, MediaLive has two roles and the upstream system has two roles: + For the SRT connection handshake: MediaLive is the SRT caller (the party that initiates the handshake). The upstream system is the SRT listener. The upstream system waits for MediaLive to call and initiate the SRT connection handshake that precedes the transmission of the source content. + For the transmission: After the connection is made, the upstream system is always the sender of the content. MediaLive is always the receiver of the content. In terms of the categorization of inputs into push and pull, an SRT input is a pull input. You don't use an input security group with an SRT input. **Topics** + [ # Get ready ](input-caller-srt-prereqs.md) + [ # Create an SRT input ](input-caller-srt-setup.md) + [ # Ensure correct setup in the upstream system ](setup-uss-srt-caller.md) + [ # Result of this procedure ](input-caller-srt-result.md) # Get ready Step 1: Get ready 1. Obtain the following information from the operator of the upstream system: + The IP address and port of the content, including the stream if the upstream system uses that. For example, **192.0.2.120:7001** with stream **mycontent**. You need two addresses for a standard-class input, or one address for a single-class input. For information about input classes and their uses, see [Choosing the channel class and input class](class-channel-input.md). + Whether the content is encrypted. If it is encrypted, find out if encryption uses AES 128, AES 192, or AES 256. Obtain the passphrase from the operator of the upstream system. + The stream ID, if the upstream system uses this identifier. The upstream system might require a stream ID, in which case you must obtain it. Otherwise the SRT handshake between the caller and listener will probably fail. + The preferred latency (in milliseconds) for implementing packet loss and recovery. Packet recovery is a key feature of SRT. 1. If the content is encrypted, you must store the passphrase that the operator gave you. Someone in your organization must store the passphrase in a secret in AWS Secrets Manager. For more information, see [Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). Create a secret of type **Other type of secret**. The result of creating the secret is an ARN that looks like this: `arn:aws:secretsmanager:region:123456789012:secret:Sample-abcdef` # Create an SRT input Step 2: Set up the input After you have obtained the necessary information from the upstream system, you can create the SRT input. **To set up an SRT input** 1. Make sure that you have the information that you [obtained from the upstream system](input-caller-srt-prereqs.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. Then choose **SRT caller**. 1. In the **Input class** section, choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT 1. In the **Source A** and **Source B** sections, enter the information that you obtained. 1. Complete the **Decryption** fields, if applicable: + **Enabled**: Check the box. More fields appear. + Select the appropriate algorithm. + If the list of ARNs is populated, select the ARN of the passphrase that you [created earlier](input-caller-srt-prereqs.md). If the list is empty, type the ARN into the entry field. 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and adds it to the list of inputs. The input specifies either one or two sources. The sources don't appear in the list, but if you choose the **Name** link, the details page shows them. # Ensure correct setup in the upstream system Step 3: Set up upstream An operator at the upstream server must set up the source content on the upstream system. Make sure that the operator sets up as follows: + They set up to deliver the correct number of sources: + If the MediaLive channel is a standard channel, set up two sources for the content. Make sure that the two source contents are identical in terms of video resolution and bitrate. + If the MediaLive channel is a single-pipeline channel, set up one source for the content. + They set up to make the content available at the agreed URLs, and they use the agreed application names and instance names. These URLs are the URLs that you obtained [earlier in this section](setup-mp4-obtain-info.md), and that you configured into the RTMP input. They correspond to the URLs shown in [the diagram after this procedure](setup-result-rtmp-push.md). # Result of this procedure Step 4: Result of this procedure As a result of this setup, an SRT caller input exists that specifies one or two *source* URLs. These sources are the URLs for the source content on the upstream system. At runtime of the channel, MediaLive (the caller) will perform a handshake with the upstream system (the listener). MediaLive will connect to two URLs (for a standard channel) or one URL (for a single-pipeline channel), and pull the source content into the channel. ![\[Diagram showing data packets flowing from upstream systems to SRT caller inputs in MediaLive.\]](http://docs.aws.amazon.com/medialive/latest/ug/images\srt-pull-uss-input.png) # Setting up an SRT Listener input SRT Listener inputWorking with SRT Listener input The guide now includes information about working with SRT Listener inputs. This section describes how to set up to receive transport stream (TS) content that is pushed from an upstream system that is set up as an SRT caller. This section describes how to set up the source content on the upstream system, and how to create an input that connects the upstream system to MediaLive. The transport stream source must be encrypted with AES. **Roles** With an SRT Listener input, MediaLive has two roles and the upstream system has two roles: + For the SRT connection handshake: MediaLive is the SRT listener (the party that waits for the connection). The upstream system is the SRT caller. The upstream system initiates the SRT connection handshake that precedes the transmission of the source content. + For the transmission: After the connection is made, the upstream system is always the sender of the content. MediaLive is always the receiver of the content. In terms of the categorization of inputs into push and pull, an SRT Listener input is a push input. You must use an input security group with an SRT Listener input to control which IP addresses are allowed to push content to MediaLive. **Topics** + [ # Get ready ](input-listener-srt-prereqs.md) + [ # Create an SRT Listener input ](input-listener-srt-setup.md) + [ # Provide connection information to the upstream system ](setup-uss-srt-listener.md) + [ # Result of this procedure ](input-listener-srt-result.md) + [ # Network locations for SRT Listener inputs ](input-listener-srt-network-locations.md) # Get ready Step 1: Get ready 1. Discuss the following information with the operator of the upstream system: + The IP address that the upstream system will push from. You need this address to create an input security group that allows traffic from this address. For more information about input security groups, see [Working with input security groups](working-with-input-security-groups.md). + The encryption algorithm that the upstream system will use: AES 128, AES 192, or AES 256. Encryption is required for SRT Listener inputs. Agree on a passphrase with the operator of the upstream system. The passphrase is used to generate the key for encrypting and decrypting the source content. + The stream ID, if the upstream system uses this identifier. The stream ID is an optional free-form string that the upstream system can send during the connection handshake. MediaLive accepts all connections regardless of the stream ID value. MediaLive logs the stream ID for monitoring and troubleshooting purposes only. + The preferred latency (in milliseconds) for implementing packet loss and recovery. Packet recovery is a key feature of SRT. The valid range is 120 to 15000 milliseconds. 1. You must store the passphrase that you agreed on with the operator. Someone in your organization must store the passphrase in a secret in AWS Secrets Manager. For more information, see [Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). Create a secret of type **Other type of secret**. The result of creating the secret is an ARN that looks like this: `arn:aws:secretsmanager:region:123456789012:secret:Sample-abcdef` **Important** Store SRT passphrases in Secrets Manager as plaintext (for example, `secretpassword123`). Do not use the key/value option or JSON format when creating the Secret, as this may cause interoperability issues with other services. Store the passphrase as plaintext only. Ensure your passphrase is between 10 and 79 characters. 1. Create or identify an input security group that includes the IP address of the upstream system. For information about creating input security groups, see [Creating an input security group](create-input-security-groups.md). # Create an SRT Listener input Step 2: Set up the input After you have obtained the necessary information from the upstream system and created an input security group, you can create the SRT Listener input. **To set up an SRT Listener input** 1. Make sure that you have the information that you [obtained from the upstream system](input-listener-srt-prereqs.md). 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. Then choose **SRT Listener**. 1. In the **Input class** section, choose the class for this input: + STANDARD\$1INPUT: MediaLive allocates two IP addresses for redundancy. + SINGLE\$1INPUT: MediaLive allocates one IP address. 1. In the **Input security group** section, select the input security group that you created or identified earlier. This security group must include the IP address of the upstream system that will push content to this input. 1. In the **SRT Listener settings** section, complete the following fields: + **Minimum latency**: Enter the latency value in milliseconds that you agreed on with the upstream system. The valid range is 120 to 15000 milliseconds. SRT will choose the maximum of the values proposed by the sender and receiver. + **Stream ID**: Optional. Enter the stream ID if the upstream system uses this identifier. 1. Complete the **Decryption** fields. Encryption is required for SRT Listener inputs: + **Algorithm**: Select the encryption algorithm that you agreed on with the upstream system: AES 128, AES 192, or AES 256. Encryption always uses AES, but the algorithm length can be negotiated between you and the sender. If you don't know what length to use, enter the lowest value. If the sender negotiates to use a longer length, MediaLive will always agree to that higher length. + **Passphrase secret ARN**: If the list of ARNs is populated, select the ARN of the passphrase that you [created earlier](input-listener-srt-prereqs.md). If the list is empty, type the ARN into the entry field. 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and allocates one or two IP addresses (depending on the input class). The input appears in the list of inputs with the allocated IP addresses and port 5050. # Provide connection information to the upstream system Step 3: Provide information to upstream After you create the SRT Listener input, you must provide connection information to the operator at the upstream system so they can configure their SRT caller to connect to MediaLive. **To obtain the connection information** 1. On the **Inputs** page, choose the name of the SRT Listener input that you just created. 1. On the input details page, in the **Destinations** section, note the IP addresses and port. For a standard-class input, there are two destinations. For a single-class input, there is one destination. The destinations will be in the format `srt://ip-address:5050`. For example: `srt://54.123.45.67:5050` `srt://54.123.45.68:5050` 1. Provide these destination URLs to the operator of the upstream system. The operator must configure their SRT caller to connect to these addresses. Make sure that the operator at the upstream system sets up as follows: + They set up to deliver the correct number of sources: + If the MediaLive channel is a standard channel, they must push to both destination addresses. Make sure that the two source contents are identical in terms of video resolution and bitrate. + If the MediaLive channel is a single-pipeline channel, they must push to the single destination address. + They configure their SRT caller to use the same encryption algorithm and passphrase that you agreed on. + They configure their SRT caller to use a latency value. SRT will negotiate and use the maximum of the latency values configured on both sides. + If you specified a stream ID in the input configuration, the upstream system can optionally send a stream ID value during connection. MediaLive accepts connections with any stream ID value (or no stream ID). The stream ID is logged for monitoring and troubleshooting purposes only. # Result of this procedure Step 4: Result of this procedure As a result of this setup, an SRT Listener input exists with one or two *destination* URLs. These destinations are the URLs that MediaLive allocated for receiving the source content. At runtime of the channel, the upstream system (the caller) will perform a handshake with MediaLive (the listener). The upstream system will connect to two URLs (for a standard channel) or one URL (for a single-pipeline channel), and push the source content into the channel. ![\[alt text not found\]](http://docs.aws.amazon.com/medialive/latest/ug/images\srt-push-uss-input.png) # Network locations for SRT Listener inputs Network locations SRT Listener inputs support the following network locations: + **AWS**: Standard cloud deployment. MediaLive allocates Elastic IP addresses for the input destinations. + **VPC**: Deployment in your Amazon Virtual Private Cloud. MediaLive allocates Elastic Network Interfaces (ENI) in your VPC for the input destinations. When you create an SRT Listener input in a VPC, you must specify the VPC subnets and security groups. + **ON\$1PREMISES**: MediaLive Anywhere deployment. For on-premises deployments, you must specify the IP addresses and network configuration when you create the input. # Creating a transport stream (TS) file input TS file input This section describes how to set up to ingest transport stream (TS) content that is stored as a file. **To create a TS file input** 1. You should have already arranged with the video content provider to set up the upstream system for your content. Make sure that the operator of the upstream system gives you the following information: + The full URLs of the locations where MediaLive will pull the TS files from. For example: `s3ssl://amzn-s3-demo-bucket/filler-videos/main/oceanwaves.ts` `s3ssl://amzn-s3-demo-bucket/filler-videos/redundant/oceanwaves.m2ts` 1. If this input is being used in a multiple-input channel, you should have decided whether to set it up as a static input or a [dynamic input](dynamic-inputs.md). You might need to modify the URLs you obtained from the upstream system: + If the input is a static input, don't modify the URLs. + If the input is a dynamic input, set up the URL as an optional absolute portion and a required variable portion (\$1urlPath\$1). For examples, see the table after this procedure. We recommend that you use the format /\$1urlPath\$1. 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **TS**. 1. In the **Input class** section, choose the class for this input: + STANDARD\$1INPUT + SINGLE\$1INPUT 1. In the **Input sources** section, enter the URLs you previously obtained: + If the input is a standard-class input, complete both fields, to provide two URLs. + If the input is a single-class input, complete the first field with the URL that you obtained and leave the second field empty. If the upstream system requires that you provide user credentials, you must also enter the user name and password key for accessing the location. These credentials are stored on the Systems Manager Parameter Store. For more information, see [About the feature for creating password parameters](requirements-for-EC2.md#about-EC2Password). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and adds it to the list of inputs. The input specifies either one or two sources. The sources don't appear in the list, but if you choose the **Name** link, the details page shows them. When you start the channel, MediaLive will connect to the upstream system at this source location or locations and pull the content: + For a standard channel, MediaLive expects the upstream system to provide two sources and will therefore attempt to pull from both source locations. + For a single-pipeline channel, MediaLive expects the upstream system to provide one source and will therefore attempt to pull from one source location. ## Formats for the URL in a dynamic input The following table describes the different formats for the URL in a dynamic input. | Format | Description | Example | Example of the \$1urlPath\$1 | | --- | --- | --- | --- | | /\$1urlPath\$1 | URL has only the protocol in the absolute portion | s3ssl://\$1urlPath\$1 | amzn-s3-demo-bucket/my-movie.ts | | /\$1urlPath\$1 | URL has the protocol and path in the absolute portion | mediastoressl://f31z.data.mediastore.us-west-2.amazonaws.com/movies/\$1urlPath\$1 | my-movie.ts | | \$1urlPath\$1 | URL has only the variable portion | \$1urlPath\$1 | s3ssl://amzn-s3-demo-bucket/my-movie.ts | # Next steps After you have created all the inputs that you need for a channel, you are ready to start creating the channel. See [Creating a channel from scratch](creating-channel-scratch.md).