To repeat a pre-recorded video in AWS Elemental MediaLive, set the file input attachment’s Source end behavior to LOOP. Add a separate RTMP output group for YouTube Live, and use the RTMPS destination where available, as YouTube recommends.
The important scheduling detail is that a looping input does not finish in a way that lets a following follow input take over. Decide first whether the channel should repeat one file or hand off to another source; those are different operating patterns.
Prepare the file input and YouTube event
Start with a file that MediaLive can use as a VOD input. AWS documents MP4 files with an .mp4 extension and transport-stream files with .ts or .m2ts extensions as supported file source types. Check the AWS guide to MediaLive source types and confirm that the file and the channel’s intended encoding configuration work together before you build a schedule around them.
A successful file ingest is not the same as a finished YouTube setup. Your MediaLive channel processes the source and sends an encoded output, while YouTube Live receives that output at an event destination. You need the input, channel, output group and YouTube event details to agree. Treat them as distinct parts to verify rather than assuming that selecting a file also establishes delivery.
In YouTube Live Control Room, create or open the event you intend to use and locate its stream URL and stream key. The event’s encoder settings page supplies these details; YouTube’s live streaming setup guidance explains where to find them. The stream key is password-like, so keep it out of public notes, screenshots and shared documents that do not need it.
Plan the file’s contents as a programme, not just as a technical test. Listen at the beginning and end, check that the picture is suitable for repeated viewing, and confirm that any spoken introduction or ending will not sound awkward every time it recurs. For a devotional channel, for example, a long quiet interval at the end may be more noticeable on every pass than during a one-off upload. A visually gentle ambience loop can also reveal a sharp cut or a colour shift when it restarts.
If you are preparing a playlist by stitching files together before upload, the practical editing steps are different from MediaLive’s repeat control. The Ubuntu FFmpeg playlist guide covers another route for assembling and running a playlist, but do not confuse that workflow with the attachment-level LOOP setting described here.
Attach the file input to the channel
In MediaLive, create or select the channel that will process the file, then add the file input under the channel’s Input attachments. The attachment is where the channel connects to an input and where you set input-specific behaviour. The input itself describes the source; the attachment tells this channel how it should use that source.
Open the attachment’s general settings and check the selected input before editing its end behaviour. It is easy to configure the wrong attachment when a channel has several inputs, especially if names such as “main file” and “backup file” have become stale. Use names that identify the content or its role, and verify the selected source in the channel before you start it.
Keep this stage separate from delivery configuration. Attaching the file does not create a YouTube destination. You will add that as an output group, which lets you manage ingest behaviour and delivery behaviour as separate decisions. This separation is useful when diagnosing a fault: a file that does not restart points towards input settings, while a destination or key problem belongs to output delivery.
Before starting, review the channel’s available video and audio encoding controls. MediaLive’s precise choices depend on the input and output configuration, and the codecs YouTube lists are not a promise that every codec is available in every MediaLive setup or region. Use the options shown for your channel and compare them with the current requirements for the YouTube event you selected.
Set Source end behavior to LOOP
On the file’s input attachment, set Source end behavior to LOOP. AWS documents this as the control for repeating a file at end-of-file: when MediaLive reaches the end, it starts ingesting that file again from its beginning. It is not an input-loss setting, and it is not a general guarantee that a broadcast will remain uninterrupted under every condition.
The distinction matters because several settings can sound as if they address “what happens next”. LOOP determines what MediaLive does when the attached file reaches its end. Input-loss behaviour addresses loss of an input and can use replacement frames or a slate; it does not intentionally replay a completed file. Choose the setting that matches the event you want rather than treating recovery controls as substitutes for looping.
Save the attachment change and review it before starting the channel. If the channel already has a schedule or another input, check which source is active and whether a scheduled switch could move away from the loop. A correct LOOP value only describes the end behaviour for that attachment; it does not cancel unrelated schedules or ensure that the output destination accepts the stream.
When the goal is a continuous repeated programme from one static file, LOOP is the relevant MediaLive control. If you instead want a file to play once and then hand over, CONTINUE is the relevant pattern. It lets the source complete and the channel follow its configured next-input or input-loss behaviour. The difference affects the schedule, so settle it before building a run sheet.
Configure a separate RTMP output group
Add an RTMP output group to the channel for delivery to YouTube. AWS’s RTMP output group instructions describe the group configuration, while its RTMP destination field reference explains destination values such as protocol, address, port, application name and stream name. Match the fields to the destination details supplied for your YouTube event.
Think of the output group as the delivery route, not as the loop mechanism. The input attachment handles replay; the RTMP output group sends the channel’s processed output to the service. Keeping that distinction clear also helps with troubleshooting. If the source reaches its end and does not repeat, revisit the attachment. If MediaLive is producing output but YouTube does not receive it, inspect the output destination, protocol and event credentials.
Choose output video and audio settings for the content and the event rather than copying values from an unrelated channel. YouTube’s encoder guidance lists RTMP and RTMPS ingest, and video codec options including H.264, H.265/HEVC and AV1, but MediaLive availability depends on the particular channel configuration. The guide also says to use constant bitrate and recommends a two-second keyframe interval, not exceeding four seconds. Check the current YouTube encoder settings alongside the controls actually available in MediaLive.
Bitrate depends on codec, resolution and frame rate. As examples only, YouTube’s H.264 table lists 5 Mbps minimum and 14 Mbps recommended for 1080p at 30 frames per second, and 6 Mbps minimum and 17 Mbps recommended for 1080p at 60 frames per second. These are YouTube’s published recommendations on its encoder guidance page checked in 2026, not universal MediaLive settings. Use the matching current row for the profile you choose; a lower-resolution devotional video and a fast-moving local news segment may have different needs.
If viewers on mobile connections are part of your audience, avoid assuming that the highest available resolution is automatically the best choice. The comparison of 720p and 1080p on a 10 Mbps connection is useful context for the trade-off between picture detail and the connection required to receive it. Your encoding choice should still be checked against the current event requirements and the channel’s real capabilities.
Enter YouTube destination details and prefer RTMPS
Copy the stream URL and key from the YouTube Live Control Room event and enter them in the MediaLive output destination fields as required by that group’s configuration. Do not assume that the default URL displayed in a setup screen is the secure destination. YouTube’s RTMPS instructions recommend RTMPS, which protects the connection to Google’s ingest service using TLS/SSL.
Select the RTMPS URL supplied by Live Control Room where it is available, then confirm that the protocol and certificate-related options in MediaLive match that destination. The field labels and required components can vary with the selected protocol, so do not paste an entire URL into a field that expects only a host or application name. Use the AWS destination field reference for the structure and the event’s current values for the actual endpoint.
Treat the stream key as a secret with access limited to people who operate the event. If it has been exposed in a public place, follow YouTube’s current account and event controls to replace or secure it. Do not put it in a blog post, a public issue tracker or a shared screenshot. The URL identifies where the stream goes; the key authorises the encoder to send to the event.
StreamNeo can remove the recurring task of leaving a computer running just to replay an uploaded file: it turns the uploaded video into a YouTube live stream that can continue with your computer switched off. That is a different operating path from configuring a MediaLive channel, so choose based on whether you need MediaLive’s channel controls or simply want one file to repeat without maintaining a local playback machine.
Start and verify the stream
Before starting the channel, check that the input attachment points to the intended file, Source end behavior is LOOP, the RTMP output group is present, and the YouTube URL and key belong to the event you plan to monitor. Confirm that the event is configured to receive the selected ingest method and that your output profile matches the current encoder guidance. A small mismatch is easier to correct before the audience is relying on the stream.
Start the channel and watch both sides of the hand-off. In MediaLive, check that the input is being ingested and that the output group is producing output. In YouTube Live Control Room, check the incoming signal and stream health indicators, then review the preview for picture and sound. YouTube’s encoder guidance advises testing with audio and motion representative of the planned content, which is more revealing than checking a static frame alone.
A useful test includes the transition at the end of the source. Verify that the content returns to the beginning and listen for a click, silence, or abrupt change in level. A file that plays correctly from start to finish once may still have a conspicuous seam at the loop point. If your video has a long end slate or closing music, it will recur too; adjust the source edit if that is not what viewers should hear.
Do not treat a healthy preview as proof that every later hour will be free of problems. Monitoring tells you what the service is receiving now; it does not replace checking the schedule, the channel state, or the destination if conditions change. For a channel operated by a small team, agree who checks Live Control Room and who can respond to a stopped or unhealthy output, including outside normal working hours.
Plan around looping and follow-input scheduling
The scheduling consequence is easy to miss: a file attachment set to LOOP restarts at its own end, so a following follow input will not take over after that file ends. AWS describes follow-input behaviour as dependent on the preceding input completing; a looping input does not complete in that way. Do not design a hand-off on the assumption that LOOP will first replay and later advance to the next input.
Use the operating pattern that matches the programme:
| Requirement | Input behaviour | Scheduling consequence |
|---|---|---|
| Repeat one file whenever it reaches its end | LOOP | The file starts again; a following follow input will not take over at end-of-file. |
| Play a file once and let another input follow | CONTINUE | The file completes, allowing the configured follow-input behaviour to take effect. |
| Replay a static file at a later scheduled time | Switch away, then switch back to the file | Re-selecting the static file starts it from the beginning of the file or clipped section. |
If you have a morning devotional block followed by a live announcement, for example, decide whether the file should repeat until an operator changes inputs or finish once so a scheduled follow input can take over. For the second case, set the preceding file to CONTINUE and verify the follow-input sequence. For the first, plan how and when someone or something will switch away from the loop; its end is not the transition point.
Switching away from and later back to a static file is a separate replay method. AWS documents that re-selecting the file starts ingestion from the beginning of the file or clipped section. That can suit a programme which should replay at particular scheduled times, but it is not the same as continuous end-of-file looping. Include the switch times and intended active input in your schedule, then test the sequence rather than inferring behaviour from the word “loop”.
The safest schedule is explicit about completion and ownership. Record which input is active, whether it is LOOP or CONTINUE, what should happen next, and who monitors an event if a transition does not occur as intended. If you are evaluating a simpler way to keep a YouTube file loop running without operating your own playback computer, the guide to choosing a flexible YouTube streaming setup can help frame the trade-offs. It does not change the MediaLive follow-input rule.
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 LOOP start the file again when it ends?
Yes. Source end behavior set to LOOP tells MediaLive to start ingesting the file again from its beginning when it reaches the end. It controls repeat behaviour for that input attachment; it does not guarantee uninterrupted delivery if another part of the channel or destination has a problem.
Can a follow input take over after a looping file?
No. A looping file restarts rather than completing in a way that allows the following follow input to take over. If the next input should start when the file finishes, use CONTINUE for the preceding file and verify the follow-input arrangement.
Should I use RTMP or RTMPS for YouTube?
YouTube recommends RTMPS, its encrypted ingest option. Select the RTMPS URL in Live Control Room where available and check that the MediaLive destination protocol and related settings match it.
Is LOOP the same as input-loss recovery?
No. LOOP is the intended end-of-file behaviour for repeating a file. Input-loss handling is for a lost input and may use replacement frames or a slate; it is not the documented control for replaying a completed file.