

# Setting up for input switching


When you plan for a MediaLive channel that includes multiple inputs that you will switch between, there are special requirements that you must consider. 

This section assumes that you are familiar with the general procedures for designing a channel, as described in [Planning the outputs in the channel](planning-the-channel-in-workflow.md) and for creating a channel, as described in[Creating a channel from scratch](creating-channel-scratch.md).

**Topics**
+ [

# Plan the outputs
](ips-step-plan-outputs.md)
+ [

# Assess the sources
](ips-step-plan-inputs.md)
+ [

# Organize sources into static and dynamic inputs
](ips-step-design-inputs.md)
+ [

# Design the selectors for each input
](ips-step-plan-attachments.md)
+ [

# Plan the input switches in the schedule
](ips-step-plan-switches.md)
+ [

# Create the inputs and channel
](ips-step-create-inputs-channel.md)
+ [

# Set up the schedule with input switches
](ips-set-up-schedule.md)

# Plan the outputs
Step 1: Plan outputs

Plan the output side of the MediaLive channel in the normal way:
+ Identify all the output groups.
+ Identify the types of outputs in each output group.
+ Identify the video, audio, and captions encodes for each output.

For more information, see [Planning a MediaLive workflow](container-planning-workflow.md). 

After you have completed this step, you have a list of output group types, and a list of the number of video, audio, and captions outputs in each output group.

# Assess the sources
Step 2: Assess sources

When planning a multiple-input MediaLive channel, you must identify all the sources that you need. You must then assess the audio and captions in each source to ensure that the source is suitable for an input-switching scenario.

**Result of this Step**

After this step, you have a set of sources that you can successfully set up as inputs and attach to the channel in order to implement input switching in the channel. You have categorized these sources by their type: live sources or file sources.

**Topics**
+ [

# Identify the sources
](ips-collect-sources.md)
+ [

# Assess the video in the sources
](ips-assess-video.md)
+ [

# Assess the audio in the sources
](ips-assess-audio.md)
+ [

# Assess the captions in the sources
](ips-assess-captions.md)

# Identify the sources
Identify sources

1. Identify all the sources that you will need through the lifetime of the MediaLive channel or at least until the next planned maintenance period.

1. Note which sources are push inputs and which are pull inputs. Make sure that you don't exceed the [limits](eml-limitations-and-rules.md#limits-inputs). 

1. Note which sources are live sources and which are file sources. For information on whether a source is a live or file (VOD) source, see [Input types supported in MediaLive](inputs-supported-containers.md).

# Assess the video in the sources
Assess video

There are no special requirements for the video when planning a multiple-input MediaLivechannel. Assuming that AWS Elemental MediaLive supports the video codec that is in a source, you can use that source as an input for the channel. 

There is no requirement for the sources to have matching video codecs.

# Assess the audio in the sources
Assess audio

MediaLive provides flexibility in extracting audio from sources in a multiple-input MediaLive channel. It also has some special requirements for the audio in these sources. 

**To assess the audio in the sources**

1. Read the information lower down about flexibility to get a sense of how MediaLive supports a wide variety of audio sources.

1. Then read each of the requirements for information on specific constraints in the audio sources. Make sure that the audio in each source meets these requirements.

1. If you reject a source, you might want to contact the upstream system to determine if it could provide a more suitable version of the source content. 

## Flexibility in using audio


When assessing the audio, note the following rules. These rules provide flexibility in extracting audio, and therefore allow you to use a variety of sources:
+ Different languages in a source can use different codecs. For example, in your sources English might be in AAC while Spanish is in MPEG-2.
+ The method of identifying an audio language in the source doesn't have to be the same in all the sources in the multiple-input channel. 

  For example, in source 1 you can identify the languages by PID. In source 2, you can identify by language code.

## First requirement: each language must have the same coding mode in all sources


Each output language must be present in every source, and the coding mode must be the same in all sources. 

For example, assume that the channel contains an Archive output group that contains one audio encode for English 2.0 and one audio encode for French 2.0: 
+ Assume that you have a source that contains AAC 2.0 audio in English and Dolby Digital 5.1 in French. 
+ Assume that you have a second source that contains AAC 2.0 audio in English and AAC 5.1 audio in French.

  For English, this source contains audio with the same codec and coding mode as the first source. For French, it contains the same coding mode as the first source but a different codec.

  This source is acceptable. The fact that in a comparison of source 1 and source 2, the codecs are different for French isn't relevant. The requirement is that the *coding modes* are the same. 
+ Assume that you have a third source that contains AAC 2.0 audio in English and AAC 2.0 audio in French. 

  This source is *not* acceptable because for French, the audio has a different coding mode from the first source.

## Second requirement: each language must provide the highest coding mode required


For each language, every source must include audio that can produce all the highest coding mode among all the outputs in the channel. 

For example, assume that the channel contains an Archive output group that contains one audio encode for Spanish AAC 2.0. The channel also contains one HLS output group that contains one audio encode for Spanish Dolby Digital 5.1:
+ Assume that you have an source that contains Dolby Digital 5.1 audio in Spanish. 

  This source contains audio that can produce all the desired output audio encodes for Spanish. You must set up the Archive output to remix the audio down to 2.0. You don't need to set up the HLS output to remix the audio.
+ Assume that you have a second source that contains AAC 2.0 in Spanish. 

  This source is *not* acceptable. This source can't produce Spanish Dolby Digital 5.1 for the HLS output. 

## Third requirement: mp4 sources should not contain variations of the same language


An MP4 file that contains multiple variations of a language might produce undesirable output audio. For best results, the file should contain only one version of a language: 
+ For example, assume that one MP4 source contains AAC 5.1 audio in English. The channel output requires one audio encode for English 2.0. Therefore, in the output you set up the audio encode to down mix from 5.1 to 2.0.
+ Assume that you have a second source that contains AAC 2.0 in English in track 2, and Dolby Digital 5.1 audio in English in track 3. 

  MediaLive extracts audio from MP4 files by language code and it extracts from the first track that contains that language. In this example, it extracts track 2, which contains AAC 2.0. It ignores track 3. On the output side, MediaLive will try to remix this source, resulting in audio that has poor quality. 

## Fourth requirement: all sources must contain dolby if producing passthrough encode


If one of the outputs includes an encode that is set up with the Passthrough codec, then all the sources must include Dolby Digital, Dolby Digital Plus, or Dolby Atmos in all the required language or languages. 

If any single source doesn't include one of these codecs, you can't use it in the multiple-input channel.

The Passthrough option for a codec allows for the ability to ingest audio that is in Dolby Digital, Dolby Digital Plus, or Dolby Atmos and in any coding mode, and pass it through without transcoding it.

# Assess the captions in the sources
Assess captions

 There are special requirements for the captions in sources for a MediaLive multiple-input channel. 

**To assess the captions in the sources**

1. Read each of the requirements that follow for information on specific constraints in the captions sources. Make sure that the captions in each source meets these requirements.

1. If you reject a source, you might want to contact the upstream system to determine if it could provide a more suitable version of the source content. 

## First requirement: a source must contain all required captions languages and formats


With a multiple-input channel, for every output there must be a captions asset in the source that can produce the captions in that output. If a source doesn't have all the source captions to produce all the output captions, it can't be used as a source in a multiple-input channel.

For example, assume that the channel contains an Archive output group that contains one output with one captions encode for embedded captions in English, French, Spanish, and German. The channel also contains one HLS output group that contains four captions outputs, one each for English, French, Spanish, and German Web VTT captions.

Every source must include a captions source that can produce both embedded and Web VTT captions. The source can contain one captions source that can produce both output types, or the source can contain two captions sources:
+ Assume that you have a source that contains embedded captions in the four languages.

  This source is acceptable because embedded captions can produce embedded captions in the output and Web VTT captions in the output.
+ Assume that you have a source that contains DVB Sub in the four languages.

  This source is *not* acceptable because DVB Sub captions can't produce embedded captions in the output.
+ Assume that you have a source that contains embedded captions in English, French, German, and Bulgarian.

  This source is *not* acceptable because one of the languages is Bulgarian instead of Spanish.
+ Assume that you have a source that contains embedded captions in English and French.

  This source is *not* acceptable because it is missing two of the output languages.

## Second requirement: for embedded passthrough all sources must contain languages in the same order


When there is at least one output that has embedded captions and there are at least two sources that have embedded captions, the languages must be in the same order in those sources. 

*Passthrough *means that an output requires embedded captions encodes in one or more languages, and a source contains embedded captions (typically in four languages). For example, the output requires English and Spanish embedded captions. A source contains embedded captions in English and Spanish, and possibly in two other languages. 

If two sources have the embedded captions languages in a different order, you can't use both the sources in the multiple-input channel. You must use only one of the sources. 

Look again at the example from the preceding requirement:
+ Assume that you have a source that contains embedded captions with the languages in the four channels in this order: English, French, Spanish, and German. 

  Assume that you have a second source that contains embedded captions with the languages in a different order: French, Spanish, German, and English. 

  Only one of these sources is acceptable. 

When this scenario applies to your channel, you should decide which sources to keep and which ones to reject. One rule you could follow is the following: 
+ Compare the order of the captions languages in those sources.
+ Identify the order of the most important source, or identify the order that most sources follow.
+ Accept only the sources that follow this order. Reject the other sources.

**Note**  
This requirement applies only to embedded passthrough.  
If the channel doesn't contain any outputs that contain embedded captions, then you can use any source that contains embedded captions because the order of the languages in the sources isn't relevant. The embedded captions aren't passed through. They are converted to another format, such as DVB-Sub. 

# Organize sources into static and dynamic inputs
Step 3: Organize sources into inputs

This section is a supplement to the information in [Working with inputs](creating-input.md). It provides information that applies to inputs used in a multiple-input MediaLive channel. 

After you follow step 2 to assess the sources, you end up with a set of sources that are suitable for your multiple-input channel. You must now organize these sources into three types of MediaLive inputs: static live inputs, static file inputs, and dynamic file inputs.

**Result of this step**

After this step, you have a list of the following:
+ Sources that you will set up as static live inputs. Each source becomes one input (and one input attachment).
+ Sources that you will set up as static file inputs. Each source becomes one input (and one input attachment).
+ Sources that you will set up as dynamic files inputs. Several sources become one input (and one input attachment).

## Identify the live sources
Identify live sources

Make a note of the sources that are live sources. Each of these sources becomes a static live input.

## Identify and organize file sources
Identify and organize file sources

You must assess your files sources and determine if you should implement some sources as dynamic inputs, rather than as static inputs.

A static input is always associated with the same source. A dynamic input can be associated with a different source each time that you attach it to the channel. It is therefore more flexible and can help you work with the limit on the number of inputs attached to a channel. For general information about dynamic inputs, see [Static inputs and dynamic inputs](how-dynamic-inputs-work.md).

**To organize the sources**

1. Organize the file sources into sets, where the sources in each set are all stored in the same source location with the same access credentials, such as the same bucket in Amazon S3. 

   For example, you might have a set of file sources in the bucket called "prerolls," and another set in the bucket called "filler". Each bucket has different access credentials, so each one is its own set.

1. Read this step if you have inputs with embedded captions that you are converting (instead of passing through). If you don't have inputs with embedded captions, or if you do have inputs with embedded captions but they are always passed through to the output, then skip this step.
   + Within each set, identify the file sources that contain embedded captions. Determine if there is at least one output that is converting these captions rather than passing them through.
   + In each file source that contains embedded captions, identify the order of the languages.
   + Where necessary, subdivide the set according to language order.

     For example, you might have one set of file sources in an Amazon S3 bucket where the languages are in the order English, French, Spanish, and German. You might have another set in the same bucket where the order is French, Spanish, German, and English. Divide this set into two sets.

1. Make a list of the sets that you identified. For example, you might have these sets: 
   + File sources from the Amazon S3 "preroll" bucket with embedded captions in the order English, French, Spanish, and German
   + File sources from the Amazon S3 "filler" bucket with embedded captions in the order French, Spanish, German, and English
   + File sources from the Amazon S3 "filler" bucket with embedded captions in a different order, such as English, French, Spanish, and German

1. Decide whether each set of file sources becomes a static file input or a dynamic file input. Follow these rules:
   + Any set that contains more than one file source becomes one dynamic input. 
   + Any set that contains only one file source can become a static input. However, if you think you might later use other file sources from that location (for example, from that Amazon S3 bucket), you might want to treat the set as a dynamic input, in order to not exceed the [limit for file inputs](eml-limitations-and-rules.md#limits-inputs).

# Design the selectors for each input
Step 4: Design selectors for inputs

After you follow step 3 to organize sources into different inputs and input types (static and dynamic), you must identify the content to extract from each MediaLive input. 

**Result of This Step**

After this step you have:
+ Names for all the inputs
+ A list of video, audio, and captions selectors for each input

**Topics**
+ [

# Plan the input and input attachment names
](ips-plan-input-names.md)
+ [

# Plan the video selectors
](ips-plan-video-sels.md)
+ [

# Plan the audio selectors
](ips-plan-audio-sels.md)
+ [

# Planning the captions selectors
](ips-plan-captions-sels.md)

# Plan the input and input attachment names
Plan input names

You should plan the names for the input and the input attachment. Here are some tips:
+ Use the same name for the input and input attachments.
+ Include an indicator of whether the entity is static or dynamic.
+ For a static input, include either the name of the video source or a description of the video source. 
+ For a dynamic input, include an indicator of its characteristics, which you determined in step 2. Doing so ensures that you do not attach an unsuitable video source when you specify the URI in the input switch action.

For example, for a static input:
+ `static-filler`
+ `static-live-studio-feed`

For example, for a dynamic input:
+ `dynamic-s3-preroll-bucket-embedded-EN-FR-ES-DE`
+ `dynamic-s3-preroll-bucket-embedded-FR-ES-DE-EN`

# Plan the video selectors
Plan video selectors

You can extract only one video from each MediaLive input. If a given input contains more than one video, then create a video selector to extract that specific video. If a given input contains only one video, there is no need to create a video selector. AWS Elemental MediaLive automatically finds and extracts that video. On the output side, MediaLive automatically uses that one video asset. 

# Plan the audio selectors
Plan audio selectors

There are several rules you must follow when planning the audio selectors for MediaLive inputs. When you set up the audio selectors for an input, you specify the language to extract but you don't specify the format of the audio in that input. AWS Elemental MediaLive extracts that input so it can be included in the output. The output expects to be able to find the specific extracted language. 

## Rule 1: Plan the same number of selectors in every input


The selectors in each MediaLive input must extract sufficient assets to produce every output audio encode. In addition, every input must have the same number of selectors.

For example, assume you have an output that requires AAC 2.0 audio in English and French. You have a second output that requires Dolby 5.1 audio in English and French. You have a third output that requires Dolby 5.1 audio in French, Spanish, and Portuguese:
+ If the first input contains Dolby Digital 5.1 in the four languages, you must create four selectors—one for each language. The audio extracted by these four selectors can produce all the languages. It can produce Dolby Digital 5.1 for the first output, and it can produce AAC 2.0 for the second because you can set up that output for remixing.

  Although the channel has seven output audio encodes, you don't need seven selectors.
+ If the second input contains Dolby Digital 5.1 in French (but no other language), and also contains AAC 2.0 in English, Spanish, and Portuguese (but not in French), you create four selectors. The selector for French will find that audio only in the Dolby Digital 5.1. The selectors for the other languages will find those audio assets only in the AAC 2.0.
+ If the third input contains Dolby Digital 5.1 in the four languages, and also contains AAC 2.0 in the four languages, you still create only four selectors.

  Although you might think to create selectors to extract the AAC 2.0 audio for French and English just for this input, you mustn't do this because the first input doesn't have these selectors. Remember that every input must have the same number of selectors.

## Rule 2: Plan a separate selector for Dolby Digital Plus 7.1


If the MediaLive channel includes at least one output with Dolby Digital Plus 7.1, create one selector in every input for that audio asset. On the output side, in every audio encode for Dolby Digital Plus 7.1, you will map the audio encode to that selector.

After you have identified all the selectors for all the inputs, you might end up with a list like this: 
+ Selector for English
+ Selector for French
+ Selector for Spanish
+ Selector for Portuguese
+ Selector for EAC3 passthrough (EAC3 is another name for Dolby Digital Plus)

Each of these selectors applies to all inputs, regardless of the audio format in that input. 

## Rule 3: Plan the same selector names in every input


Every MediaLive selector for a specific language must have the same name across all the inputs. This rule exists because each output references the selectors only once. The output doesn't reference the selector once for each different input.

We recommend that you give the selectors names that include the language. Don't include the format unless you create a selector for Dolby Digital Plus 7.1. 

# Planning the captions selectors
Plan captions selectors

When you set up the captions selectors for a MediaLive input, you specify both the format and the language to extract from the input. Each input has the number of selectors that is appropriate to the captions formats in that input. Therefore, each input might contain a different number of selectors. The method for extracting captions is different from the method for extracting audio. 

## Rule 1: Plan the number of selectors for an input that is appropriate to the input and output


In each input, you must create the number of selectors that is appropriate to the input format and output format:
+ For example, if you want to extract embedded in order to pass through the captions, you create one selector.
+ If you want to extract embedded in order to convert them to TTML, you create one selector for each language.

After you have identified all the selectors for all the inputs, you might end up with a list like this: 
+ Selector for embedded passthrough – applies to input 1, input 3, and input 4
+ Selector for embedded, English – applies to input 1, input 3, and input 4
+ Selector for embedded, French – applies to input 1, input 3, and input 4
+ Selector for DVB Sub, English – applies to input 2
+ Selector for DVB Sub, French – applies to input 2
+ Selector for Teletext passthrough – applies to all inputs

Note that inputs 1, 3, and 4 each contain four selectors. Input 2 contains three selectors. 

## Rule 2: Plan the same selector names in every input


Every unique selector must have the same selector name across all the inputs. This rule exists because each output references the selectors only once. The output doesn't reference the selector once for each different input where the selector exists.

We recommend that you give each selector a name that includes the language and the source format. Descriptive names help you to choose the correct selector on the output side. 

# Plan the input switches in the schedule
Step 5: Plan input switches

After you design the selectors for each input (step 4), you must plan the order that you want MediaLive to follow when it ingests these inputs.

**Result of This Step**

By following this step, you have identified one input as being the first that you will add to the channel. 

You have also identified an ordered list of input switches. You have the following for each switch:
+ An action name for the switch. 
+ The name of the input attachment associated with the switch.
+ The switch input identified as either static or dynamic.
+ The type of switch—fixed, follow, or immediate.

**Topics**
+ [

# Plan the action names
](ips-plan-action-names.md)
+ [

# Plan the order of input switches
](ips-order-switches.md)
+ [

## Example of a list of input switches
](#ips-ordered-list-examples)
+ [

# Handling the transition when the next input is fixed or immediate
](ips-transition-gap.md)
+ [

# Handling the transition when the next input is follow
](transition-follow-success.md)
+ [

## **Prepare input—reducing latency when the next input is immediate**
](#ips-plan-immediate-prepare-input)

# Plan the action names
Plan action names

You should plan the names for the input switch action in the MediaLive schedule. Action names must be unique in the schedule for each channel.

For a static input, you might want to name the actions so that they indicate which input applies. For example, for each switch to the input named static-live-studio-feed:
+ `static-live-studio-feed-action-1`
+ `static-live-studio-feed-action-2`
+ `static-live-studio-feed-action-3`

For the input switch action for a dynamic input, you might use the input name (or part of the name) plus the URL (or part of the URL) of the file. For example:
+ `dyn-preroll-EN-FR-ES-DE-ad-ward-cars-1`
+ `dyn-preroll-EN-FR-ES-DE-ad-zel-cafe`
+ `dyn-preroll-EN-FR-ES-DE-ad-ward-cars-2`

# Plan the order of input switches
Plan order of switches

We recommend that you plan the order of the input switches before you create the actions in the MediaLive schedule.

**To plan the order of input switches**

1. In the first position, put the input attachment that you want MediaLive to ingest first. Make a note that this input will be an immediate switch in the schedule.

1. Make a list of switches and the input attachment to use for each switch. Decide on the start type for each switch—fixed, immediate, or follow. For more information, see [Fixed, immediate, and follow switches](ips-switch-types.md) and [Rules and limits for input switches](ips-limits.md). 

   You should be able to organize the fixed and follow input switches into an ordered list. You might not be able to include the immediate switches in the ordered list because you don't know their start times. See the [example](ips-step-plan-switches.md#ips-ordered-list-examples) after this procedure.

   Note the following about switching to an input:
   + You can switch to an input attachment as many times as you want.
   + When you switch to a dynamic input, you must provide the URL that applies for that usage of the dynamic input. In the list that you make, specify the URL for each usage.

1. Read the information later in this section about handling the transition between switches. For each input attachment in your list, make a note of how to handle the transition.

**About Models for the Schedule**  
There are two models for setting up input switches in the schedule:
+ In the recommended model, you use only the schedule to control the ingest of all inputs. With this model, the order of the input attachments in the channel isn't relevant. You set up the schedule so that the first input switch is an immediate switch to the input that you want to ingest first. As soon as the channel starts and before the channel starts to ingest, the channel performs that immediate switch.

  The steps earlier in this section show how to design the schedule for this model.
+ In the other model, the first input attachment is the first input that MediaLive ingests. You set up the schedule to perform its input switch only after that first ingest. 

  We don't recommend this model because you must look at the order of input attachments and at the schedule. With the first model, you monitor the order of ingest from one place—the schedule.

## Example of a list of input switches


This example shows a list of planned input switches. The first input is an immediate switch to a file input. Then there are several short file inputs that are follow switches, so that the switch occurs at the end of the previous input. These inputs run one after another, but the plan is to interrupt these at any time with an immediate switch to the first live input. After that, the schedule switches back and forth between two live inputs. You don't know the exact timing for the switches, so you will set up these switches as immediate switches. 

Ordered list: action name, start type, input attachment name
+ startup, immediate, banner
+ static-1, follow, short-clip-12
+ static-2, follow, short-clip-32
+ static-3, follow, short-clip-77
+ static-4, follow, short-clip-18

Immediate switches to occur at any time:
+ static-live-studio, immediate, live-1
+ static-live-alternate, immediate, live-2

# Handling the transition when the next input is fixed or immediate
Handling a fixed or immediate transition

When planning the schedule, you should ensure that there is no gap when switching from a file input (input A) to an input (input B) that starts at a fixed time or that starts immediately. Input B can be a file or a live input. If the current input ends before the switch start time, there is potential for a gap. 

The **Source end behavior** field in each input attachment controls the gap. (This field appears in the **Input attachments** page, in the **General input settings** section of the channel.) There are two options to ensure a smooth transition in this situation:
+ If you set the **Source end behavior** field for input A to **LOOP**, then when input A finishes, MediaLive goes back and ingests it again until the start time of input B occurs. 
+ If you set the **Source end behavior** field for input A to **CONTINUE**, then input A is ingested only once; when the input finishes, the channel follows the behavior specified in the **Input Loss Behavior** set of fields (although without the "repeat frames" logic). When the start time of input B occurs, the input loss behavior ends and the channel switches to input B.

  (To display this field, in **General input settings** for **Global configuration**, for **Input loss behavior**, choose **Input loss behavior**. More fields appear. For more information, see [Handling loss of video input](feature-input-loss.md).)

# Handling the transition when the next input is follow
Handling a follow transition

When planning the schedule, you should ensure that a switch from one input to a "follow input" can succeed.

A follow input (input B) won't succeed if the current input (input A) is set up to loop. When AWS Elemental MediaLive reaches the file end, it starts to ingest again from the beginning of the file. 

The **Source end behavior** field in each input attachment controls looping. (This field appears in the **Input attachments** page, in the **General input settings** section of the channel.) 
+ Always set the **Source end behavior** for input A to **CONTINUE**. When input A finishes, the channel immediately switches to input B.

When you create the channel, it is important to set the **Source end behavior** to **CONTINUE** in every input attachment where the next planned input in the schedule will be a follow input. If you don't set up the input with **CONTINUE**, you won't be able to set up the schedule with the next input as a follow input. You will have to cancel the schedule action, modify the input attachment, and try the schedule action again.

## **Prepare input—reducing latency when the next input is immediate**


You might have an input switch that you have identified as an immediate input switch, but you don't know when the switch will need to occur. You only know that you will be given just a few seconds advance notice. In this situation, you might want to prepare the input in advance by creating a prepare input action. For more information, see [Preparing inputs in AWS Elemental MediaLive](feature-prepare-input.md).

# Create the inputs and channel
Step 6: Create inputs and channel

After you perform the planning in steps 1 to 5, you are ready to create the inputs and create the MediaLive channel.

In a multiple-input channel, all the inputs must already exist in the channel before you start the channel. You can't add an input while the channel is running. Therefore, you should identify all the inputs that you might need until the next planned maintenance period.

**Topics**
+ [

# Create the inputs
](ips-create-inputs-tips.md)
+ [

# Identify the first input for the channel
](ips-plan-first-input.md)
+ [

# Create the channel
](ips-create-channel-tips.md)

# Create the inputs


This section is a supplement to the information in [Working with inputs](creating-input.md). It provides information that applies specifically to creating inputs for use in a MediaLive channel that contains multiple input attachments.

Follow the steps in [Creating an input](create-input.md)for creating a channel, with the following notes.
+ Create the inputs that you identified in the previous steps in this section.
+ Make sure that you set up each input as the correct type (static live, static file, or dynamic file).

  There are no special steps for creating a static live input or static file input. 

  To create a dynamic input, you must enter a variable in the URL for the file source. When this variable is present, MediaLive recognizes the input as a dynamic input. For more information, see [Setting up dynamic inputs](dynamic-inputs.md).

# Identify the first input for the channel
Identify first input

Identify an input that you will set up as the first input in the list of input attachments for the MediaLive channel:
+ This input won't be the first input to ingest because you will use the schedule to switch to the first input to ingest.
+ It can't be a dynamic file input. It must be either a live input or a static file input in order for the channel to start.

# Create the channel


This section is a supplement to the information in [Creating a channel from scratch](creating-channel-scratch.md). It provides information that applies specifically to creating a MediaLive channel that contains multiple input attachments.

Note the following points, and then follow the steps for creating a channel as described in [Creating a channel from scratch](creating-channel-scratch.md).

## Channel and input details pane


On the **Channel and input details **pane for the channel, in the [Input specifications](input-specification.md)section, set up each option to meet or exceed the most demanding of your inputs.

## Input attachments pane


On the **Input attachments **pane for the channel, set up the input attachments for the [inputs that you created](ips-create-inputs-tips.md).

**To set up each input attachment**

1. Choose **Add **in the **Input attachments **pane. 

1. Choose an input. Enter the name that you decided on when you [planned the attachments](ips-step-plan-attachments.md). 

1. Choose **Confirm** to display fields for general settings, for video selector fields, audio selector fields, and captions selector fields. 

1. Complete these fields as appropriate.

Note the following points:
+ Attach all the inputs that you identified. If you omit an input, you won't be able to attach it unless you stop the channel.

  You should have already [identified the first input attachment](ips-order-switches.md). Make sure that you create this attachment first, so that it appears first in the channel. 
+ Add the remaining input attachments in any order. 
+ In the **General input settings** section for each input attachment, set **Source end behavior** to work correctly. For information, see [Handling the transition when the next input is fixed or immediate](ips-transition-gap.md).
+ In the **General input settings** section for each input attachment, set up the following sets of fields according to the plan that you created when you [planned the attachments](ips-step-plan-attachments.md): 
  + The fields in **Video selector**
  + The fields in**Audio selectors**
  + The fields in **Caption selectors** 

## Output groups


On the **Output groups **pane for the channel, follow the regular procedure to create all the output groups that you identified in [Plan the outputs](ips-step-plan-outputs.md). 

# Set up the schedule with input switches
Step 7: Set up the schedule

After you create the inputs and the channel (step 6), you must create actions in the MediaLive schedule to set up the input switches that you want. For detailed information about creating input switch actions, see [Creating actions in the schedule (console)](schedule-using-console-create.md). 

Follow these guidelines when setting up the schedule:
+ You should create at least some of the fixed input switches and follow input switch actions before you start the channel. 
+ The first input switch in a new channel should be an immediate input switch. You should create this input switch before you start the channel. Setting up in this way ensures that the order of ingest of inputs is always being controlled by the schedule.
+ For other immediate switches, you might be able to add the switches to the schedule before you start the channel. Or you might be able to add them only after the channel is running. You should have an idea of which of these strategies applies to your plan.
+ Plan to update the schedule regularly. Remember that you can add actions to the schedule without stopping the channel.