AWS Elemental MediaLive does not rotate through a channel’s attached inputs by itself. To switch sources, attach each intended input to the channel, then create input-switch actions in its schedule and choose when each action should run.
The main decision is timing: use a fixed start for a known wall-clock transition, immediate for an ad-hoc change, or follow when one input should begin after a preceding file action ends. These are planned schedule actions, not automatic failover, and a scheduled transition is not a promise that every source change will be seamless.
How MediaLive input switching works
Think of the channel’s input attachments as a pool of sources it is allowed to use, not a playlist. A channel with several attachments stays on its current input until a schedule action tells it to switch. AWS makes this distinction explicit in its guide to multiple-input channels and the schedule.
An input-switch action identifies the target attachment and gives the action a name and start settings. The schedule belongs to the channel; it is not a separate schedule resource that you have to create. You can prepare actions before the channel starts, then add or adjust actions while it is running. For the available settings, see AWS’s documentation on input-switch actions.
For example, a small news channel might attach a live studio feed and a static file containing a holding slate. Attaching both makes them available, but does not make the slate take over when the studio feed fails, or bring the studio feed back when it recovers. A person or an automation process must schedule a switch, unless a separate failover feature has been configured for the relevant failure conditions.
This is different from a local playlist that advances as one clip ends. MediaLive needs an explicit action for each planned change of input. If your workflow is built around files and a repeating sequence, first decide whether those files are one input with clip handling or several channel inputs; the distinction affects how you schedule transitions. The guide to making a looping video for YouTube Live can help with preparing source material, but it does not replace the MediaLive channel schedule.
Attach the inputs to the channel
Before scheduling, create or identify the MediaLive inputs and attach every source that the channel will need. A schedule action targets an input attachment on that channel. It does not refer to an unattached input merely because that input exists elsewhere in the account. Give the attachments and actions names that make their purpose clear, such as studio_live, evening_bhajan_file, or backup_slate; use names that match your actual channel.
Check the source type as you plan. MediaLive distinguishes static inputs, such as a file source, from dynamic inputs, such as sources whose locations can be supplied or changed dynamically. Some start and follow workflows have restrictions connected with input type. In particular, AWS’s setup guidance says the first switch must target a static input. Confirm the current requirements for your channel and configuration in the schedule setup guidance and input-switch limits.
It is useful to write down the intended sequence before opening the schedule. For each transition, record the source you are leaving, the attachment you are entering, whether the source is live or a file, and what should determine the start. That small plan catches a common mistake: building actions around the names of source inputs while overlooking the attachment names the channel schedule expects.
If you are running a YouTube output, also check that the channel and its output path are already configured and tested independently of the switch. A channel that cannot start or reach YouTube will not become healthy because its schedule is correct. For a separate checklist on a regional publishing issue, see checking region and RTMPS when a MediaLive YouTube stream will not start.
Create a switch action in the schedule
For each intended transition, add an input-switch action to the channel schedule. Its basic pieces are an action name, start settings, and input-switch settings that identify the target attachment. In the console, work in the channel’s schedule and choose the relevant input-switch action; through the API or CLI, supply the equivalent fields. AWS’s CLI field reference and examples show the shape of these settings.
Do not treat an example payload as a production configuration. Replace its channel ID, action name, target attachment and time with the values for your channel, and make sure the requested timing mode matches the intended transition. An action can be accepted yet still be operationally wrong if it targets the wrong attachment or is scheduled for the wrong moment.
Where the schedule is known in advance, enter the planned fixed and follow actions before starting the channel where practical. AWS’s schedule setup guidance recommends planning these actions ahead and making the first switch immediate to a static input. If a schedule starts with an input that cannot be detected, startup can fail; test the initial source and the channel before relying on an event plan.
After the channel is running, you can add an ad-hoc action for an operator-directed change. Keep a simple action log or run sheet that records the intended time, target, and person making the change. For a 24/7 stream, that record matters during a handover: an operator arriving midway through a shift should be able to tell whether a scheduled change is still pending or has already happened.
If you are also planning how to keep a YouTube broadcast running outside a studio shift, consider the distinction between a source schedule and the machine or service that produces the stream. The article on running a 24/7 playlist from a low-cost VPS in Mumbai covers a different operating model; it does not make MediaLive’s input attachments switch automatically.
Choose the timing mode
Select a start mode based on what determines the transition. The schedule supports fixed, immediate, and follow starts. The right mode is the one that expresses your actual operating plan, not simply the one that is easiest to enter.
| Mode | Use it when | What it depends on |
|---|---|---|
| Fixed | The switch should happen at a known wall-clock time | A valid scheduled time and the target attachment |
| Immediate | An operator needs to switch now, or the exact time was not known in advance | A submitted action and a usable target input |
| Follow | The next source should start after a reference input-switch action ends | A reference action whose source end behaviour is set to Continue |
A fixed action is appropriate for a planned handover, such as switching from a live presenter to a recorded bulletin at a known UTC time. AWS’s action-behaviour documentation describes a fixed input-switch start as a UTC time and gives timing boundaries for the action. However, AWS documentation pages reviewed for this guidance differ on the minimum lead time for some configurations: one describes a 15-second minimum, while a fields page describes a 30-second minimum for a static live input. Do not apply one minimum universally. Follow validation for your exact console or API path and configuration, and check the current AWS guidance before a time-critical event.
Immediate is useful when the transition is decided on the day, such as switching from a studio source to a holding file after an operator instruction. For standard channels with two pipelines, AWS says MediaLive sets an internal start time 10 seconds ahead so both pipelines switch together. This is an internal coordination detail, not a guarantee that the viewer sees an uninterrupted or visually seamless change: source readiness, encoding and the nature of the content still matter.
Follow is useful for a sequence tied to the end of a prior file action. For example, you may want a short announcement file to run, then move to a live source once that file ends. The reference action must be configured with Source end behavior set to Continue. Confirm that the reference is the action you mean and that its source has the expected duration or end condition; otherwise the next switch may not occur when you expect.
For file inputs, switching away and later returning to a static file starts ingest again from the beginning of the file or the selected clip. That can be correct for a looped slate or devotional segment, but wrong if you expected playback to resume at its previous point. Decide explicitly whether a restart is acceptable before using the same file attachment repeatedly.
Check prerequisites and action timing
Before relying on a schedule, verify that the channel is in the state needed to accept the action, the target attachment is present, and the source is available. A carefully timed action does not repair a missing attachment, an unreadable file or an unhealthy live source. For a live source, check that it is publishing in the format and location expected by the configured input. For a file, inspect the chosen asset and any clip boundaries rather than assuming a switch will resume playback.
Review the action time against the current AWS rules for the exact action type. Fixed starts use UTC, so convert local operating times carefully. A schedule entered for an Indian local time, for instance, should be checked as a UTC time before the action is created. Since the AWS references give different minimum lead times for particular fixed-start cases, rely on the validation displayed for your configuration instead of copying a threshold from another setup.
For a planned immediate switch where reducing delay matters, consider a prepare-input action. AWS describes prepare-input actions as a way to prepare a source ahead of a planned switch; they do not change which input is on air by themselves. Treat preparation and switching as separate schedule work, then confirm that both actions refer to the intended source and timing.
Scheduled switching also does not define what happens when a source unexpectedly fails. Input-loss handling can provide replacement content after loss, while automatic input failover is a separate feature with its own configuration and trigger. These mechanisms address failure conditions, not the same intent as a planned operator switch. Read AWS’s input-loss handling documentation, decide what behaviour suits the channel, and test it separately from normal schedule transitions.
For overnight or unattended operation, write down who can add an action, how an unexpected source loss is escalated, and what content should appear if the source becomes unhealthy. A recurring 24/7 YouTube channel may also need a separate plan for viewer interaction while the operator is away; the practical guide to moderating Super Chats on an always-on stream addresses that adjacent duty, not MediaLive failover.
Verify the transition in the channel
Do a controlled test before relying on a live event. Use a non-critical interval or a test channel if available, and choose sources whose output is easy to distinguish. Confirm the current input, submit the action, then observe the channel’s input state and the actual output at the destination. Check both sound and picture: a source may be selected while its media is missing, unexpectedly silent, or different from what the operator intended.
For fixed timing, verify the displayed UTC start and observe near the planned change. For immediate timing, confirm that the action was accepted and that the switch reached the channel. For follow timing, test the reference action through its end condition and check that the next action starts as expected. Record what you observed, including any transition delay or content restart that matters for your audience. Do not assume a transition is seamless simply because the schedule action completed.
After the test, review the schedule for stale actions. An old fixed action can be easy to miss when reusing a channel for a new programme, and an old follow action can still be linked to a reference action that no longer reflects the plan. Remove or update actions that should not run, then check the schedule again before the next unattended period.
If an immediate transition needs to happen quickly, test the prepare-input approach under the same source and channel conditions rather than assuming it will eliminate all delay. If source failure is the concern, test the configured input-loss or failover behaviour separately. These tests answer different questions: one checks planned switching, the other checks the channel’s response to an unhealthy source.
The practical objective is not to make every change invisible. It is to know which source should be active, at what point, and what you will check if it is not. That is a more useful operating standard than treating a list of attached inputs as an automatic playlist.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does MediaLive automatically rotate through attached inputs?
No. Attaching multiple inputs makes them available to the channel, but does not create an automatic sequence. Create explicit input-switch actions in the channel schedule for the transitions you want.
Which timing mode should I use for a planned programme change?
Use fixed when the transition should happen at a known wall-clock UTC time, immediate when the decision is made on the spot, and follow when the next input should begin after a reference action ends. Check the source type and action requirements before choosing; a follow action depends on its reference action and its end behaviour.
Is a scheduled input switch the same as automatic failover?
No. A scheduled switch is an action you plan, whether for a fixed time, immediately, or after another action. Input-loss handling and automatic input failover address source-health events and must be configured and tested separately.
Will a file resume where it stopped after I switch back to it?
A static file input starts again at the beginning of the file or selected clip when you switch away and later return. If the workflow requires different playback behaviour, check the current MediaLive documentation and test the file sequence before using it on air.