# Setting up for input switching
You can set up a MediaLive channel to ingest multiple sequential inputs, rather than setting it up to ingest only one input. You set up this *multiple-input channel* by attaching more than one input to the channel, and then adding actions in the channel's schedule that specify when to switch from one input to another.
**Topics**
+ [About multiple-input channels and input switching](ips-overview.md)
+ [Rules and limits for input switches](ips-limits.md)
+ [Setting up for input switching](setup-ips.md)
+ [Deleting actions from the schedule](ips-manage-schedule.md)
+ [Starting and restarting a channel that has multiple inputs](ips-start-channel-multi-inputs.md)
# About multiple-input channels and input switching
You set up input switching in a MediaLive channel in order to ingest the inputs in a multiple-input channel.
**Topics**
+ [Multiple-input channels and the schedule](schedule-and-switching.md)
+ [Typical use cases](typical-use-cases.md)
+ [Fixed, immediate, and follow switches](ips-switch-types.md)
+ [Static inputs and dynamic inputs](how-dynamic-inputs-work.md)
+ [Input Prepare](ips-input-prepare.md)
# Multiple-input channels and the schedule
Input switching in a MediaLive channel works as follows: You create a channel that contains more than one input attachment. After the channel is created, you go into the schedule for that channel and add input switches, to create rules for moving from one input attachment to another. When you start the channel, the channel will automatically switch inputs according to the schedule.
To work successfully with multiple-input channels, remember the following.
**The schedule exists inside the channel**
The schedule does not exist separately from the channel. On the console, you find the schedule in the details page for an existing channel.
**There is no implicit switching**
With a multiple-input channel, you must add input switches to the schedule to instruct the channel to switch. A channel that contains more than one input attachment won't switch to the next input attachment in the list of input attachments unless the schedule specifies to do so.
**There is no "main" input**
With a multiple-input channel, you must think of the input attachments as a *pool* of inputs all with equal status. There isn't one input that is the main input, that the channel returns to when it has nothing else to ingest.
# Typical use cases
Scheduled input switching in a MediaLive channel supports the following use cases.
## Use case 1: One live feed and one file input alternating
You have a channel to process a live (streaming) feed from a specific source, perhaps for a sports tournament. Periodically (perhaps between individual sports events), the live feed should be replaced by file content (perhaps a filler such as a video of ocean waves). After a few minutes, the same live feed should be resumed.
You set up the channel with one live input and one file input. The first input is the live input.
Before you start the channel, you create a schedule that consists of actions to switch to the live input at the top of each hour—at 10:00 AM, 11:00 AM, and so on.
You then start the channel. As soon as each sports event has finished, you modify the schedule "on the spot" to switch to the video filler. The live feed continues for a few moments (perhaps showing the sports crowd or the players leaving the stadium), and then the channel switches to the filler video. At the top of each hour, the channel switches to the live feed.
## Use case 2: One live feed and file inputs, and the channel starts with a file input
You have the same requirements as for use case 1, except that you want to start the channel with a file clip, perhaps from the opening of the sports event. At the top of the first hour, you want to show the video filler. But at the top of the second and succeeding hours, you want to show highlights from earlier in the day.
You set up the channel with one live event (a live input) and several file inputs: one for the opening, one for the video filler, and several for the highlights. The first input is the file input for the opening event.
Before you start the channel, you create a schedule that contains one action to switch to the live input as soon as the file input has finished.
You then start the channel. As time goes on, you modify the schedule to add more actions, as for use case 1, to switch back and forth between the live input and the file inputs.
## Use case 3: Two live feeds
You have a channel to process live feed from two different sources. You want to insert ad content into the channel, as required. You want to insert this ad content using MediaLive. (You don't want to insert SCTE-35 messages that a downstream system will read in order to replace the avails with ad content.)
The live feeds might be the venue feed and the in-studio feed for the same sports event. You want to switch from one live feed to the other. You want to time the switches "on the spot" instead of according to a strict clock schedule. Occasionally, you want to switch from one live feed to an ad. When the ad is finished, you might want to return to one of the live feeds.
You set up the channel with two live inputs and several file inputs (one file for each ad).
Before you start the channel, you create a schedule that contains the first action in the schedule. That action is to switch to the first input, input A, that you want to the channel to ingest. You set the start time for input A to a time that is at least one minute earlier than the time that you start the schedule. You then start the channel. MediaLive immediately reads the schedule and switches to the input that is supposed to be the current action, which is input A. When appropriate, you modify the schedule on the spot to add actions to queue up one or more switches.
## Use case 4: VOD-to-live
You have a channel to process only MP4 file inputs, or mostly MP4 file inputs, on a 24/7 basis.
You set up the channel with a series of file inputs to run one after another. Each file is encoded from start to finish, and then the next file starts. Sometimes, you want to clip a file and play only part of that file.
You want this channel to run without stopping, until the next scheduled maintenance period, which might be in several weeks.
To overcome the limit of 20 inputs per channel, you take advantage of the *dynamic input* feature. You create some file inputs with a variable in the place of all or part of the path and file name. You set up the schedule to use this dynamic input over and over again, each time with a different file name slotted into the variable. You can set up several dynamic inputs.
# Fixed, immediate, and follow switches
In MediaLive, you can categorize input switches according to the start types for the switch.
+ Fixed – A fixed input switch starts at a specific time.
Fixed switches use UTC time. They don't use the timecode of the input.
+ Immediate – An immediate input switch starts as soon as possible. This type of switch is more like a fixed switch than a follow switch because it interrupts the current input. The advantage of this switch over a fixed switch is that you don't have to calculate any buffer in the start time.
+ Follow – A follow input switch starts when the previous input has ended (when MediaLive has reached the end of the file).
This start type is a property of the switch, not a property of the input itself. Therefore, in the schedule you can switch to a specific input with a fixed switch, and then later switch to the same input with a follow switch.
## Types of switches and types of inputs
The combination of types of switches and types of inputs (file and live) means that there are these types of switches:
+ A file input with a fixed start. The previous input can be a file or live input. At the specified start time, MediaLive stops ingesting the previous input and switches to the new input.
+ A file input with an immediate start. The previous input can be a file or a live input. As soon as possible after you enter this switch in the schedule, MediaLive stops ingesting the previous input and switches to the new input.
+ A file input that follows the previous input. The previous input must be a file input. It can't be a live input because a live input doesn't have an end, so the switch would never occur.
+ A live input with a fixed start. The previous input can be a file or live input. At the specified start time, MediaLive stops ingesting the previous input and switches to the new input.
+ A live input with an immediate start. The previous input can be a file or a live input. As soon as possible after you enter this switch in the schedule, MediaLive stops ingesting the previous input and switches to the new input.
+ A live input that follows the previous input. The previous input must be a file input. It can't be a live input because a live input doesn't have an end, so the switch would never occur.
The following table summarizes the inputs and start types.
| Current Input | Next Input | Possible Start Type |
| --- | --- | --- |
| File | File | Fixed or Immediate |
| File | File | Follow |
| File | Live | Fixed or Immediate |
| File | Live | Follow |
| Live | File | Fixed or Immediate |
| Live | Live | Fixed or Immediate |
## Follow chains
A series of follow input switches is called a *follow chain*. When each input ends, MediaLive automatically starts ingesting the next input. Here is a diagram of a follow chain:
```
Input A Fixed or Immediate File
Input B Follow File
Input C Follow File
Input D Follow File or Live
Input E Fixed or Immediate File or Live
```
The follow chain starts with the *reference action*—the input above the first follow. It ends with the last follow input. In the preceding example, the chain starts with the reference action input A and ends with input D. Inputs A, B, and C must be files because they must have a defined ending so that the next input can successfully follow. Input E breaks the chain because it is fixed or immediate.
# Static inputs and dynamic inputs
If your MediaLive channel includes files inputs, you should decide if you want to set up each input as a *static input* or as a *dynamic input*. Using dynamic inputs lets you increase the number of video sources that you can use in the channel, while still observing the limit on the number of inputs that you can attach to the channel.
You can set up file inputs as static or dynamic inputs. (Live inputs are always static inputs.)
To set up a static input, you specify a standard file URL. For example, `s3ssl://amzn-s3-demo-bucket/my-movie.mp4`.
To set up a dynamic input, you set up the all or part of the file URL with a variable. For example, `s3ssl://amzn-s3-demo-bucket/movies/$urlPath$`. Each time you set up in the schedule to switch to this input, you specify the value for the `$urlPath$`. For example, `s3ssl://amzn-s3-demo-bucket/movies/my-movie.mp4` in one input switch and `s3ssl://amzn-s3-demo-bucket/movies/mlaw.mp4` in another input switch.
You can set up for dynamic content in MP4 file inputs and transport stream (TS) file inputs.
The [procedure for setting up](ips-step-design-inputs.md) for input switching, later in this section, provides detailed information about deciding whether you should set up some inputs as dynamic inputs.
# Input Prepare
The MediaLive schedule includes an input prepare action that is a helper action for input switches.
For more information about input prepare, see [Preparing inputs in AWS Elemental MediaLive](feature-prepare-input.md).
# Rules and limits for input switches
This section describes the rules and limits that apply to input switches in the MediaLive schedule.
## Rules for types of inputs
There is flexibility in the number and types of inputs that you can set up for input switching. For example:
+ You can have both HLS live inputs and MediaConnect inputs attached to one channel.
+ You can have both RTMP push inputs used for a source from the public internet and an RTMP VPC push input.
But there are also some restrictions:
+ The number of push inputs and pull inputs that you can attach to a channel.
+ The number of inputs of a specific input type. For example, the number of CDI inputs you can attach to a channel.
+ Use of VOD assets.
+ Use of inputs in different Availability Zones.
+ Use of dynamic inputs in an input switching workflow.
For detailed information about these rules, see [MediaLive feature rules and limits](eml-limitations-and-rules.md).
## First switch must be static
The first switch in the channel must be for a static input. It can't be a dynamic input.
## No limits to the number of input switches
The schedule for the channel can contain any number of scheduled input switching actions.
You can switch to a specific input as many times as you want.
## Reusing a file input
If you switch away from a static file input and then switch back to it, the channel ingests the file from the start of the file or start of the file clip (if you clipped the file). This rule applies even if you switch away from the file input before the end of the file.
This rule also applies if you switch away from a dynamic file input and then switch back to it without changing the value of the variable portion of the URL. The channel always ingests from the start.
# 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
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
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
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
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
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
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
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
Make a note of the sources that are live sources. Each of these sources becomes a static live input.
## 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
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
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
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
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
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
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
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
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
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
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
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 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
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.
# Deleting actions from the schedule
You can delete input switch actions from the MediaLive schedule. There are different rules for deleting actions depending on the current state of the channel. The channel can be running, idle, or recovering. The channel is idle if you manually stopped it. The channel is recovering if it failed and MediaLive is automatically restarting it.
**Deleting actions while the channel is running**
When the channel is running, there are restrictions on the input switch actions that you can delete. MediaLive must preserve information about the currently active input. It must preserve that information so that if the channel fails, MediaLive can recover and start ingesting on the appropriate input. Therefore, this rule applies:
+ You can't delete the most recent fixed or immediate input switch. The term *most recent* means one of the following:
+ The input is the input currently being ingested. So the most recent input and the active input are the same.
+ The input is the fixed or immediate input switch that most recently ingested. The active input might be a follow input.
+ You can't delete any of the actions in a follow chain that follows this most recent fixed or immediate input switch. For example, in the following diagram, assume that input A is the most recent fixed or immediate input switch. You can't delete actions B, C, or D. You can delete E, which is not part of the follow chain.
```
Input A Fixed
Input B Follow
Input C Follow
Input D Follow
Input E Immediate
```
**Deleting actions while the channel is idle**
You can delete an input switch action when the channel is idle, so long as the action is still in the schedule.
To delete an action that is in a follow chain, you must delete the entire follow chain, then recreate the follow chain but omitting the unwanted action. See [Deleting actions from the schedule (console)](schedule-using-console-delete.md).
**Deleting actions while the channel is recovering**
You can delete input switch actions while the channel is recovering.
# Starting and restarting a channel that has multiple inputs
After you create the MediaLive channel and add actions to its schedule, you can start the channel.
Before you start the channel, make sure that the inputs attached to the channel are ready:
+ Push inputs must be already pushing before you start the channel. A push input must be already pushing even if it isn't the first input in the channel.
+ If the first input in the channel is a file input, it must be ready to be pulled.
+ A file input that isn't the first input doesn't have to be ready to be pulled until approximately 30 seconds before the switch to the input occurs.
**Topics**
+ [What happens at runtime](#ips-runtime-behavior)
+ [Restarting a channel](#ips-restart-channel-multi-inputs)
+ [What happens with an empty schedule](#ips-empty-channel-charges)
## What happens at runtime
When you start the channel, AWS Elemental MediaLive takes a short time to get the channel ready to run.
As soon as the channel is ready, MediaLive looks at the schedule to determine if there is an input switch with an immediate switch, with a start time that is now or with a start time that is overdue:
+ If it finds this action, it switches to that input and starts ingesting.
+ If it doesn't find this action, it starts ingesting the first input attachment listed in the channel.
If you set up the channel and schedule as recommended, then as soon as the channel is ready, it finds an immediate switch to the first input that you want MediaLive to ingest.
## Restarting a channel
If you restart a channel that has multiple inputs set up for scheduled input switching, AWS Elemental MediaLive looks at the schedule to determine which input should currently be running. MediaLive then behaves as follows:
+ If that input is a live input, then MediaLive starts ingesting that input at the current frame.
+ If that input is a file input set to start at a fixed time or immediately, then MediaLive starts ingesting that input at the start of the file or of the file clip (if you clipped the input). It doesn't adjust for the difference between the scheduled time and the current time. For example, assume that it is now 13:10:00 UTC. The schedule specifies to switch to input X at 13:00:00. MediaLive starts ingesting the file from the start, not from 10 minutes into the file.
+ If the current input is ambiguous because there is a chain of follow inputs, then MediaLive ignores the follow inputs. It finds the most recent fixed or immediate input that is in the past, relative to the UTC time at which you restart the channel. It starts ingesting the input at the start of the file.
For example, assume the schedule looks like this:
+ Live input X with fixed start time of 11:00
+ File input A with fixed start time of 11:06
+ File input B with follow start time
+ File input C with follow start time
+ Live input D with fixed start time of 12:15
Scenario 1: Assume the channel stopped at 11:04, when input X was active. You restart the channel at 12:09. The most recent fixed input switch relative to the current time is at 11:06. It is a switch to file input A. MediaLive goes to input A and starts ingesting that input from the beginning.
Scenario 2: Assume the channel stopped at 11:04, when input X was active. You restart the channel at 12:16. The most recent fixed input switch relative to the current time is at 12:15. It is a switch to live input D. MediaLive goes to input D and starts ingesting.
Scenario 3: Assume the channel stopped at 11:08, when input A was active. You restart the channel at 12:14. The most recent fixed input switch relative to the current time is at 11:06. It is a switch to file input A. MediaLive goes back to input A and starts ingesting. It ingests files A to C until 12:15, when it switches to the live input. It ingests at least part of file A. It might ingest files B and C. But at 12:15 it definitely switches to input D.
## What happens with an empty schedule
If the channel finishes the last input in the schedule (so that the schedule is now empty) and you have set up so that the input doesn't loop, then MediaLive stops ingesting, but the channel continues to run. Charges for the channel continue to accrue.