# 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).