For a single prerecorded MP4, the direct AWS route is Amazon S3 to an AWS Elemental MediaLive file input, then a MediaLive channel that sends RTMP to YouTube Live. Set the input attachment’s Source end behavior to LOOP; MediaLive repeats the file while it waits for a scheduled next input.
MediaPackage is not the file playout engine and is not needed for that YouTube path. Add it only if you also need a packaged HLS playback endpoint for other viewers or services.
Choose the direct YouTube output architecture
The simplest design has four steps: store the MP4 in S3, have MediaLive ingest and encode it, set the file input to loop, and configure an RTMP output group for YouTube Live. The data path is:
MP4 in S3 → MediaLive file input (Source end behavior: LOOP) → MediaLive channel → RTMP output to YouTube Live
MediaLive is the service that accepts the source, processes it and delivers the configured outputs. AWS describes channels as being able to use output groups such as RTMP and HLS. The MediaLive channel documentation explains the channel and output-group model. YouTube is one destination for a dedicated RTMP output, but AWS’s general RTMP capability is not a YouTube-specific recipe. Check YouTube Studio for the current ingest URL, stream key and encoder requirements when you configure the destination.
This separation matters because a file loop and a playback origin solve different problems. The loop keeps MediaLive supplied with repeated source material. An HLS origin serves packaged playback to clients that request it. Inserting MediaPackage into the YouTube route adds a service without making the loop work; it can also add configuration and ongoing cost without serving your audience’s needs.
If you are deciding whether managed cloud processing is worth the operating overhead, compare it with a computer-based workflow before building. Our guide to cloud service pricing for prerecorded streams helps frame the ongoing-cost question, while FFmpeg for looping a folder of videos is a different route when you prefer to run and maintain the playout yourself.
Store the prerecorded MP4 in Amazon S3
Put the source file in an S3 location that MediaLive can access as a file input. AWS’s dynamic input documentation describes S3 as an eligible location for MP4 or TS file inputs. For a basic one-file loop, keep a clear record of the bucket and object path you intend MediaLive to use. Confirm permissions and the exact URI in the AWS console or configuration you use; a typo or access issue means the channel cannot ingest the intended source.
Use a finished, stable export rather than a file that is still being replaced during setup. Check that its picture, audio and duration are what you expect by playing it before upload. A devotional channel might use one continuous programme with a clean start and end; a study channel could use a recorded lesson sequence rendered as one file. The loop repeats the source as provided, so any black frames, silent sections or abrupt ending in the MP4 will recur as well.
S3 holds the source; it does not schedule the YouTube broadcast or repeat the video. Keep the distinction clear when diagnosing failures: if the object cannot be read, investigate the source location and access; if ingest succeeds but the programme ends, check the MediaLive input behavior and channel schedule.
For channels that later need several files rather than a single repeated programme, plan the source arrangement separately. AWS supports scheduled input switches and dynamic inputs, but a sequence requires scheduling decisions that a single LOOP setting does not make for you. You can also read our guide to a 24/7 devotional stream with recorded videos for broader source and channel planning.
Configure MediaLive to pull the file
Create or select a MediaLive input appropriate for the file source, then associate it with the channel that will encode and deliver the programme. In practical terms, the channel needs a working reference to the S3 MP4 and an output configuration that matches the delivery you intend. The exact console labels may change, so rely on the current AWS workflow rather than copying a screenshot from an older guide.
The channel’s encoding choices affect what YouTube receives: picture dimensions, frame rate, audio and bitrate should be chosen with the source and YouTube’s current guidance in mind. Do not assume that a higher bitrate always improves the viewer’s experience; it can increase the data sent and may exceed what the source or destination needs. Nor does choosing an output value by itself prove that YouTube will accept the stream. Review YouTube Studio’s current encoder settings and validate the signal there before relying on it.
A channel can be configured with multiple output groups, so YouTube RTMP and an optional HLS output can be distinct destinations from the same channel. Keep the basic YouTube path uncomplicated first. If you add another output for a separate playback endpoint, record which output group serves which destination. This makes a later fault easier to isolate: a working HLS endpoint does not by itself demonstrate that the RTMP destination is configured correctly, and the reverse is also true.
For operational visibility, note the input, channel and destination names you choose, and check their state after starting the channel. You will want to see whether MediaLive is ingesting the file and whether its outputs are active, rather than relying only on the YouTube player. Keep access credentials out of shared notes and screenshots. YouTube’s stream key grants access to the broadcast destination, so treat it as a credential and use the current key-management options in Studio.
Set Source end behavior to LOOP
The key setting is on the MediaLive channel input attachment: Source end behavior. Set it to LOOP for a single file that should repeat. AWS explains that when a file input reaches its end with this behavior configured, MediaLive starts ingesting the file again until a scheduled next input begins. See AWS’s documentation on input transition behaviour.
This is not a playlist editor. With one attached file and no scheduled change, LOOP means that same file starts again. If your source has a 40-minute programme, the expectation is that the programme repeats, not that MediaLive selects another object or shuffles a folder. If you have a schedule that switches to another input, the loop serves as the repeating source while waiting for that next scheduled input.
AWS also describes CONTINUE as playing the file once and then using input-loss behaviour until the next input begins. That makes it a different operational choice, not a less obvious way to loop. Review the MediaLive typical use cases alongside the input transition documentation if your channel will switch between file and live inputs.
After setting the behavior, save the channel configuration and verify the attachment is the one actually used by the channel. A correct setting on an unused input will not change the active playout. Keep the desired source, its attachment and the channel schedule aligned, especially if you later add a second file or a live source.
Send a dedicated RTMP output to YouTube Live
In the MediaLive channel, configure an RTMP output group for YouTube as a separate destination. Enter the current ingest URL and stream key from YouTube Studio rather than relying on values copied from an old tutorial. The RTMP output carries the encoded live programme from MediaLive to YouTube; the S3 object itself does not connect to YouTube.
The exact destination information can vary with YouTube’s current interface and stream configuration. Before starting a long-running channel, open Studio, create or select the intended live stream, and confirm the ingest details and encoder settings shown there. If YouTube offers a primary and backup ingest address, do not assume the MediaLive configuration is using both or that this alone establishes end-to-end redundancy. The research-supported architecture here is a dedicated RTMP output, not a tested dual-ingest recipe.
Treat the stream key as sensitive. If the channel does not appear in Studio, first check that the output destination, key and selected stream are consistent. Then check whether MediaLive reports an active output and whether YouTube reports a received signal. These observations narrow the fault domain: MediaLive input problems point back towards S3 access or file ingest, while a healthy input and inactive destination point towards output configuration or connectivity.
For a fuller explanation of key choices, see reusable versus one-time YouTube stream keys. A reusable key can reduce repeated setup work, but it should still be managed like a credential and associated with the intended broadcast. Check current YouTube guidance rather than assuming that a key saved long ago remains the right one for a changed workflow.
Add MediaPackage only for a separate HLS endpoint
Add a second output only when a real playback requirement calls for it. In that design, MediaLive sends HLS to MediaPackage, which packages the live HLS feed for downstream playback requests. The optional branch is:
MediaLive HLS output → MediaPackage endpoint → playback clients or CDN
AWS’s MediaPackage supported inputs documentation covers live input, and its documentation describes MediaPackage as receiving upstream live media for packaging and delivery. This is a separate role from reading the S3 MP4 and repeating it. MediaLive remains responsible for file ingest and loop behavior; MediaPackage receives the resulting live HLS output.
A separate endpoint may be useful if you need a playback URL for your own site or another distribution path. AWS’s Live Streaming on AWS architecture overview shows MediaPackage and CloudFront in a viewer-delivery pattern. That does not mean CloudFront or MediaPackage is necessary to feed YouTube. Add those services only when the other playback use case justifies the extra setup and cost.
If YouTube is your only destination, omit the HLS branch and start with the direct RTMP output. If you do need both outputs, test them independently and document which endpoint your viewers should use. Do not count a packaged HLS playback check as proof that YouTube is receiving RTMP, or vice versa.
Verify the repeating input workflow
Test the complete path before treating it as an unattended channel. Confirm that MediaLive can access and ingest the chosen S3 object, that the channel is active, and that the RTMP output is reaching the intended YouTube stream in Studio. Watch the transition from the end of the file back to its beginning. The material question is whether the programme resumes as expected, not merely whether the channel status initially changes to running.
Check the restart point for picture and sound. A file may loop technically while still having an unsuitable ending: a fade to black followed by a loud opening, a title card that repeats, or a long gap can make the cycle obvious. If that is not the experience you want, edit the source before upload. LOOP repeats the file; it does not trim, crossfade or repair it.
If you schedule a later input, verify that the scheduled transition takes place as intended. AWS describes looping as continuing until a scheduled next input begins, so the schedule is part of the operating design. If your plan is simply to repeat one file indefinitely, avoid adding an unnecessary schedule that can interrupt it.
Remote monitoring remains useful even in a managed cloud workflow. Check MediaLive’s input and output state as well as YouTube’s received signal and public playback. For a practical checklist of remote observations, see how to monitor an always-on YouTube VOD stream remotely. If you cannot check continuously, decide who will receive alerts and what action they are authorised to take; do not infer automatic recovery behaviour beyond what you have configured and verified.
Weigh the operational trade-offs before leaving it live
A managed AWS design avoids leaving a personal computer responsible for the encoding session, but it still requires someone to configure the channel, confirm YouTube ingest, manage credentials and review failures. You are exchanging local machine care for cloud configuration and ongoing service usage. AWS source material here does not provide a workload-specific price estimate, so calculate the likely cost using current AWS pricing and your actual channel settings rather than borrowing an estimate from a different encoding workload.
The useful comparison is not just the number of services. Consider whether YouTube is the only output, whether an HLS playback endpoint is needed, how many source files and transitions the schedule needs, what encoding outputs are required, and what recovery checks you will perform. Every additional output or distribution component should answer a concrete audience or operations need. A single MP4 loop sent directly to YouTube is easier to reason about than a multi-service design whose extra pieces have no defined role.
Redundancy needs particular care. AWS’s reference live-streaming architecture presents redundancy concepts, but it does not establish automatic end-to-end redundancy for this exact single-file loop to YouTube. Do not assume that two outputs or a MediaPackage endpoint guarantee a backup broadcast. Validate the class and constraints of the chosen MediaLive channel, the behaviour of your specific input and outputs, and your recovery procedure before describing the design as resilient.
If a cloud architecture feels disproportionate for one file and one destination, a desktop or VPS workflow may fit better if you are prepared to keep it running and maintain it. StreamNeo is relevant when the recurring burden is keeping a computer on for a single-file YouTube loop: you upload the file and provide the stream key, then the broadcast runs with your computer switched off, with monitoring and automatic restart if it drops. It is YouTube-only, so a requirement for a separate HLS playback endpoint remains a different architecture decision.
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
How do I loop a video on YouTube Live using AWS?
Put the MP4 in S3, configure a MediaLive file input and channel, and set the input attachment’s Source end behavior to LOOP. Send a dedicated RTMP output to the ingest destination and key shown in YouTube Studio, checking the current settings there before you start.
Can MediaPackage loop an MP4?
No. In this design, MediaLive ingests and loops the file. MediaPackage can receive a live HLS output from MediaLive and package it for playback clients, but it is not the component that repeats the MP4.
Do I need MediaPackage to stream a prerecorded video to YouTube?
No. The direct path is S3 to MediaLive to a YouTube RTMP output. Add MediaPackage only if you separately need its HLS playback endpoint for another audience or distribution route.
What if I want to play several files rather than repeat one?
A single LOOP setting repeats the same file; it does not make a playlist. AWS supports scheduled input switching and dynamic inputs for workflows involving multiple files, so plan and test the schedule and transitions separately.