AWS Elemental MediaLive can play a supported file input repeatedly: choose a file source and set its end behaviour to LOOP. For a 1080p H.264 YouTube Live output, match the bitrate to the frame rate—14 Mbps at 30 fps or 17 Mbps at 60 fps—and verify the output protocol rather than assuming an RTMPS path.
The important distinction is that MediaLive’s documentation about RTMP Pull and RTMP Push inputs does not establish which protocol a particular channel can use for its output to YouTube. YouTube recommends RTMPS, so confirm the exact output configuration and ingest endpoint before building around a direct connection.
Choose a MediaLive file input
A file input suits a pre-produced programme that you want to broadcast repeatedly: for example, a devotional playlist assembled into one MP4, a recorded local bulletin, or an ambience video. AWS documents MP4 files from Amazon S3 or an HTTP(S) server as supported file sources. It also lists static TS or M2TS files from those locations. A growing TS file being written while MediaLive uses it is not supported, so do not treat a live-growing recording as equivalent to a finished file.
This approach is different from capturing a desktop or camera continuously. The input is a stored asset, and the service reads it as a file. That can be useful when the programme is stable and you want the same material to continue without leaving a workstation on. It does not decide whether your programme is editorially suitable for continuous repetition, nor does it create new material when the file ends; looping simply begins the file again.
Before creating a channel, write down the details that determine the output you need: source codec and bitrate, frame rate, resolution, audio track and codec, output group, and whether your intended output is 1080p30 or 1080p60 H.264. The research available here does not establish one tested AWS channel profile that fits every source or output protocol. Treat those items as configuration decisions to confirm in the current MediaLive documentation and console, not values to guess from the word “1080p”.
MediaLive’s API classifies HD as 720 through 1080 vertical lines. That classification is useful for understanding a resolution label, but it is not a full source-file specification. A file can be 1080 pixels tall and still have a frame rate, encoding profile, audio layout, or bitrate that needs checking before you rely on it for a long broadcast. If you are still preparing the source, this guide to choosing an OBS canvas and output resolution for a 24/7 YouTube loop covers the resolution side of that decision.
Store the source file in S3 or HTTP(S)
MediaLive needs access to a completed source file at a supported location. For MP4, the documented choices are S3 and HTTP(S). Choose the location according to how you manage the asset and how your organisation controls access; the documentation cited here does not establish one location as universally better. Check the current AWS requirements for the input type and access arrangement you intend to use.
An S3 source makes sense when your workflow already stores approved programme files there and you can identify the exact object to use. An HTTP(S) source may fit an existing publishing workflow where the file is served from a web location. In either case, verify that the URL or object refers to the final, complete file, not a temporary upload or a path that will change during the run. If a file is replaced, confirm that MediaLive is using the intended version rather than assuming a change to the stored object will alter an already configured input.
Static TS or M2TS may be an option if that is how your material is packaged, but it is not interchangeable with every file workflow. AWS specifically cautions that growing TS files written while in use are unsupported. If an encoder is still appending segments, use a different architecture or first produce a completed source in a supported form. Do not infer that a playlist of changing pieces is accepted merely because a static transport-stream file is supported.
Keep a record of the source location, file name, expected duration, frame rate, and audio properties alongside the channel configuration. This makes it easier to diagnose whether an unexpected result comes from the source or the output. It is also useful when you update a daily news loop or replace a festival programme: check the replacement as a new asset instead of assuming it has the same encoding characteristics as its predecessor.
Set the file-end behaviour to LOOP
The file-end setting is the part that makes a finite asset repeat. In MediaLive’s input settings, set sourceEndBehavior to LOOP for the file input. AWS’s API reference describes this as looping a file input so it can be streamed indefinitely. The setting means the input starts over when it reaches its end; it does not mean that the video contains infinite unique content or that a stream cannot stop for other reasons.
The practical check is to confirm the setting on the input actually attached to the channel. A correctly uploaded file with an end action that does not loop will still reach its end. Conversely, selecting LOOP cannot repair an invalid or inaccessible source file. Confirm both the location and the end behaviour before testing the channel, then observe the transition at the file boundary. Look for a clean return to the beginning, expected audio continuity, and any visible black frame or abrupt cut that needs editing in the source.
A single long file is operationally simple, but the exact repeat point matters. If the opening contains a slate, silence, or a spoken introduction, viewers will encounter it each time the asset restarts. For a bhajan channel, a pause before the first track can become a recurring gap; for a local news loop, an outdated opening graphic can repeat all night. Edit the file so the end and beginning make sense together, and make a test copy if you need to inspect the join without disturbing the intended programme.
This is one distinction from managing a sequence of separate clips in a desktop application. If your production depends on scheduled rotation rather than repeating one file, a playlist-oriented workflow may suit it better; see the guide to rotating a YouTube Live playlist every six hours with OBS. For a fixed file, LOOP is the documented MediaLive control, but it does not replace checking transitions and content freshness.
Check input protocol support against YouTube’s RTMPS recommendation
Do not conflate an input protocol with an output protocol. AWS’s supported-input documentation states that MediaLive RTMP Pull and RTMP Push inputs do not support RTMPS. Those statements describe MediaLive inputs. They do not, by themselves, prove that a MediaLive channel’s output to YouTube must use RTMP, nor that a particular output can use RTMPS.
YouTube recommends sending a live stream using RTMPS, a secure extension of RTMP. Read that recommendation alongside the documentation for the actual MediaLive output group you plan to configure. Confirm the output protocol supported by that channel configuration, the destination and authentication fields it requires, and whether the YouTube ingest endpoint accepts that protocol. Until those checks are made, a direct MediaLive-to-YouTube RTMPS path is an unresolved compatibility question, not a safe assumption.
The distinction is especially important if you encounter instructions about adding an RTMP input to MediaLive. That input is how MediaLive receives content from an upstream source; it is not the same as the output used to deliver a programme to YouTube. The research notes do not verify a complete deployed channel profile, so they cannot support a claim that one-hop delivery works for every account or channel configuration. Check current primary documentation and, where possible, validate the chosen configuration with a controlled stream before relying on it for an overnight broadcast.
YouTube also documents HLS ingest as an alternative. Its guidance includes transport-stream segments lasting 1–4 seconds, a rolling playlist with no more than five outstanding segments, and HTTPS POST/PUT requests. Those are requirements to compare against an AWS output, not proof that any MediaLive HLS output group satisfies them. Verify segment duration, playlist behaviour, request method, and endpoint compatibility for the particular configuration. If you cannot establish that match, do not call HLS a workaround.
The protocol check belongs early in the project, before you invest time tuning file looping and bitrate around an unverified delivery path. The official references are AWS’s MediaLive supported input formats and protocols, YouTube’s live encoder settings and ingest guidance, and YouTube’s HLS ingest requirements. Recheck those pages because supported options and platform guidance can change.
Choose the 1080p bitrate by frame rate
For H.264, YouTube’s recommended 1080p bitrate depends on the output frame rate. Use the matching row rather than treating all 1080p streams as the same:
| H.264 output | YouTube recommended video bitrate |
|---|---|
| 1080p at 30 fps | 14 Mbps |
| 1080p at 60 fps | 17 Mbps |
These are YouTube’s recommendations in its live encoder guidance, not an AWS-tested profile or a guarantee that the source will look good. Set the intended frame rate first, then use the corresponding target when configuring the output. Do not apply 14 Mbps to 60 fps by default: YouTube lists 17 Mbps for 1080p60. If the source is 30 fps, there is no reason in these recommendations to choose the 60 fps figure simply because the channel is capable of higher frame rates.
The source properties and encoded output are related but not identical. A low-motion still image, a detailed music performance, and a scrolling news ticker may behave differently at the same resolution and bitrate. The cited guidance gives a target recommendation; it does not mean every visual source will have the same quality at that setting. Likewise, increasing bitrate beyond the recommendation is not a substitute for choosing the right frame rate or checking whether the connection and ingest route can carry the output consistently.
For a devotional loop made at 25 or 30 fps, decide whether the output should remain at its source cadence or be converted to 30 fps, and confirm that the channel supports the selected encode settings. For a 60 fps source, choose 60 fps only if you need that motion cadence and can configure and deliver it correctly. The available research does not specify how MediaLive should handle each possible conversion, so do not assume an automatic frame-rate choice. Consult the current service controls for the channel you are building.
Audio has its own settings. YouTube recommends 128 Kbps stereo audio and a 44.1 kHz stereo sample rate in the cited guidance. Check that the file actually contains the intended audio track and that the output configuration preserves it. A silent source is not made audible by selecting an audio bitrate, and a mono source should not be assumed to become meaningful stereo simply because the output is configured for two channels.
If YouTube reports excessive bitrate or dropped frames, investigate the configured output and delivery path rather than changing several values at once. This explanation of YouTube Live bitrate that is too high and dropped frames is relevant when you need to separate an encoding choice from a transport problem. For this MediaLive setup, the key first check is whether the output frame rate and bitrate correspond to the same row above.
Set CBR and the keyframe interval
YouTube recommends constant bitrate (CBR) for live encoding and a two-second keyframe interval, with four seconds as the maximum. Those settings describe the encoded output, not the file-loop behaviour. A source file can be read repeatedly while the output encoder produces a continuous stream with its own rate control and keyframe cadence. Set and inspect both parts of the workflow independently.
In the channel’s video output settings, select CBR if the configuration offers that rate-control choice. Then set the keyframe interval to two seconds where possible and ensure it does not exceed YouTube’s stated four-second limit. A two-second interval is YouTube’s recommendation; the four-second figure is a ceiling in the guidance, not the preferred target. Confirm whether the configuration expresses interval in seconds or another unit before entering a value.
Keyframes matter because they provide reference points for decoding and seeking. A periodic keyframe interval helps the receiving platform process the live video predictably. It does not fix a mismatched frame rate, an inaccessible destination, or a source that itself contains a bad cut. That is why you should verify the setting in the actual output configuration and then inspect the result in YouTube’s stream health tools rather than assuming that a saved value proves the entire path is correct.
Do not invent an AWS profile by combining YouTube’s recommendations with unverified settings. Select a supported H.264 output for the channel, use the frame-rate-specific bitrate target, choose CBR, and use the recommended keyframe interval. Check the current AWS interface and documentation for the precise control names and accepted value formats, because the research used here does not establish a universal MediaLive preset.
Verify the output and monitor the stream
Before treating the channel as ready for an unattended run, make a controlled test with the actual source, output group, and YouTube destination you plan to use. Confirm that the input is available, the file reaches its end and restarts, the output is the intended 1080p frame rate, and audio is present. Then check YouTube’s preview and stream health information for warnings. The purpose is to discover a protocol or configuration mismatch while you can still correct it, not to infer long-term reliability from a short test.
Observe a file boundary at least once. A loop can expose a click, a black frame, a sudden level change, or an awkward editorial restart that is not apparent when playing only the first few minutes. For a news loop, check whether timestamps and headlines remain current. For a study or ambience channel, check whether the repeat point interrupts the intended listening experience. The technical setting repeats the file; it cannot assess whether repetition is acceptable to your audience.
During operation, monitor the broadcast for stopped output, missing sound, or YouTube warnings. If the stream drops, separate the diagnosis into source access, MediaLive input and channel state, output configuration, and ingest acceptance. Avoid changing bitrate and protocol simultaneously, because that can make it harder to tell which adjustment addressed the issue. Keep a copy of the known-good settings and note what changed when you test a correction.
An always-on channel also needs an operating plan for when a person is not watching. Decide who receives alerts, who can check the console, and what you will do if the programme file becomes unavailable or the ingest endpoint rejects the output. If the reason you are considering a cloud workflow is to avoid leaving a personal computer running, StreamNeo can remove that specific operating burden for a prepared video by letting you upload it once and leaving your own computer switched off while the broadcast is monitored and restarted if it drops. It is YouTube-only, and it does not remove the need to prepare suitable content or check platform requirements.
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 in AWS Elemental MediaLive?
Use a supported file input and set InputSettings.sourceEndBehavior to LOOP. AWS documents this as allowing a file input to be streamed indefinitely. Check that the input is attached to the intended channel and that the file itself has a clean transition from end to beginning.
Can MediaLive play an MP4 from S3 on repeat?
AWS documents MP4 file inputs from Amazon S3 and HTTP(S), and its API reference documents the LOOP end behaviour for a file input. Confirm the file is complete and accessible, then verify the loop on the configured input. Do not assume the setting fixes a damaged or incorrectly encoded source.
What bitrate should I use for 1080p YouTube Live?
For H.264, YouTube recommends 14 Mbps at 1080p30 and 17 Mbps at 1080p60. Choose according to the frame rate you will actually send, and pair it with YouTube’s CBR and keyframe guidance. Check current YouTube guidance before launch.
Can AWS MediaLive stream directly to YouTube using RTMPS?
The cited AWS statement that MediaLive RTMP Pull and RTMP Push inputs do not support RTMPS is about inputs; it does not settle output compatibility. YouTube recommends RTMPS, so verify the specific MediaLive output configuration and confirm that the intended YouTube ingest endpoint accepts it. Do not assume a direct path without that check.