For a conventional SDR channel, start with RTMPS, H.264 video, CBR, a two-second keyframe interval and AAC audio. Choose the bitrate from the actual output resolution and frame rate rather than copying one number into every MediaLive channel.
Treat these settings as a starting recipe, not a guarantee that a broadcast will run without interruption. Test representative movement and sound before going live, then watch YouTube's stream health while the channel is running.
Start with YouTube's current ingest guidance
YouTube's current encoder guidance recommends RTMPS for live delivery, with H.264 as a conventional choice for SDR video. It also lists CBR, a two-second keyframe frequency, AAC or MP3 audio, square pixels and progressive scan among the recommended settings. You can check the current guidance on YouTube's official live encoder settings page before you create or revise a channel.
The important point is that YouTube's recommendations describe the destination, while MediaLive describes the service producing the output. The two need to agree. A MediaLive channel can offer several codec, rate-control and quality choices, but the YouTube-facing output should be built around the format YouTube expects for your particular stream.
For a devotional video loop, a local news still-image bulletin, a study channel or an ambience station, conventional SDR is usually the simpler place to begin. HDR has different requirements and deserves a separate test path. YouTube recommends H.265 over RTMP(S) for HDR, and HLS may be considered when the encoder does not provide the required RTMP capabilities. That does not make HLS the default for every 24/7 channel.
YouTube transcodes a live stream into several viewer formats. Your task is therefore to deliver a stable, correctly formed source stream, not to create a separate output for every phone, television or broadband connection. The source still needs enough bitrate for its own resolution, frame rate and content.
Choose RTMPS and H.264 for the ordinary SDR path
For a normal SDR workflow, select an RTMPS output when the MediaLive destination configuration supports it. RTMPS is the encrypted extension of RTMP and is YouTube's recommended baseline for live delivery. Use the stream key and server details supplied by YouTube Studio rather than relying on an old value saved in a previous channel.
Select H.264 for the video encoder when you want the straightforward SDR path described in YouTube's encoder guidance. The frame size and frame rate must match the output you intend to send. If your source is a 25 fps Indian television-style programme, there is little benefit in converting it to 60 fps merely because MediaLive permits it. A 30 fps or 25 fps source should normally be planned around its real production requirement, with any conversion treated as a deliberate workflow choice.
YouTube also lists H.265 and AV1 support in its encoder guidance. Those options may be useful in a workflow designed around them, but they are not interchangeable with the H.264 bitrate table. Check that the selected codec, MediaLive output path and YouTube ingest method all support the same design before building a channel around it.
HLS belongs in a more specific discussion. AWS's example for 4K HDR delivery to YouTube uses an HLS output group, HEVC and a two-second GOP. That AWS article was published in 2021, so treat it as a concrete HDR example rather than a current universal template. You can review the vendor's 4K HDR YouTube Live example for MediaLive when your use case genuinely calls for HDR or an HLS-based path.
Use CBR and a two-second keyframe interval
Set the YouTube-facing video output to constant bitrate, or CBR, as the baseline. CBR keeps the intended delivery rate more predictable, which is useful when the destination publishes a bitrate recommendation and the channel must run continuously. It does not mean every frame contains the same amount of visual information. It means the encoder aims to maintain the configured delivery rate over time.
MediaLive also exposes VBR and QVBR. VBR changes bitrate with scene complexity, while QVBR targets a quality level subject to a maximum bitrate. These can be sensible choices in other distribution workflows, particularly when quality per bit matters more than maintaining a specific average rate. They should not quietly replace YouTube's CBR guidance without testing the complete workflow.
Set the keyframe interval to two seconds. YouTube says not to exceed four seconds, but matching the recommended two-second interval gives the destination a regular structure for processing and playback. A keyframe, or I-frame, is a reference frame from which following frames can be decoded. Long gaps can make recovery and joining less predictable, especially when viewers arrive part-way through a continuous broadcast.
Do not confuse the keyframe interval with the video frame rate. At 30 fps, a two-second interval represents 60 frames. At 60 fps, it represents 120 frames. In MediaLive you can express GOP size in frames or seconds, so using seconds is often less error-prone when you change frame rate. Confirm the resulting GOP in the channel output rather than assuming the field was interpreted as intended.
Match MediaLive GOP size to two seconds
In the MediaLive video output, set GOP size to two seconds and select the appropriate GOP-size unit. If you work in frames, calculate from the actual output frame rate. For a 30 fps output, the starting value is 60 frames. For a 60 fps output, it is 120 frames. If the source uses a fractional rate, use the actual MediaLive frame-rate numerator and denominator rather than rounding casually.
The aim is alignment between three things: the frame rate, the encoder's GOP structure and YouTube's keyframe expectation. A mismatch can arise when the source is converted, when a fractional frame rate is selected, or when a preset silently changes the output rate. Inspect the final output settings after saving the channel configuration.
A two-second GOP is not a promise that every viewer will see an uninterrupted picture. It only makes one important part of the stream predictable. Input loss, authentication errors, a failed channel, an unsuitable source, network problems between MediaLive and YouTube, or a YouTube-side event can still interrupt a broadcast.
For a 24/7 channel, keep the GOP choice consistent across the normal output and any deliberately configured alternate output. If you create a special HDR or high-resolution path, test that path independently. Do not assume that a setting which works for a 1080p SDR loop also describes an HEVC HDR workflow.
Pick bitrate from resolution and frame rate
There is no universal YouTube bitrate for MediaLive. YouTube publishes different recommended H.264 ingest rates for different output sizes and frame rates. The following figures are the recommended values in YouTube's current encoder guidance, not independent measurements of MediaLive quality.
| H.264 output | YouTube recommended bitrate | Published minimum recommendation |
|---|---|---|
| 720p30 or 720p60 | 8 Mbps | 3 Mbps |
| 1080p30 | 14 Mbps | 5 Mbps |
| 1080p60 | 17 Mbps | 6 Mbps |
| 1440p30 | 21 Mbps | 7 Mbps |
| 1440p60 | 34 Mbps | 8 Mbps |
| 2160p30 | 42 Mbps | 11 Mbps |
| 2160p60 | 50 Mbps | 14 Mbps |
Choose the row matching the actual H.264 output. Do not use the 1080p30 figure for a 1080p60 stream simply because both outputs have the same pixel dimensions. The higher frame rate carries more pictures each second and has a different published recommendation.
The minimum column is a floor recommendation, not the preferred starting value. For a new channel, the recommended row is the clearer baseline unless your source, distribution design or testing gives you a documented reason to choose differently. If you select a lower rate, test moving scenes rather than judging the result only from a static devotional poster or a mostly blank news slate.
Resolution is also a production decision, not only a quality setting. A small local news loop with text may need enough detail for names and headlines to remain readable. A still-image prayer stream may not gain much from a high frame rate. A channel showing falling rain, a temple procession or camera movement may expose compression problems sooner than a static background.
Do not mix these H.264 figures with YouTube's separate AV1 or H.265 columns. The codec, output resolution and frame rate must be treated as one combination. If you change codec or move into HDR, return to the current official guidance and test the new workflow rather than carrying the H.264 number across.
Configure AAC audio and test real programme content
Use AAC audio for the ordinary YouTube-facing setup. YouTube also lists MP3, but AAC is the direct starting choice for a conventional MediaLive SDR output. Set the sample rate, channel layout and audio source to match the actual programme. A stereo music stream, a mono spoken bulletin and a source with multiple audio tracks should not be treated as the same input simply because all three can be placed inside a live output.
Check that the audio is present at the source and remains present after MediaLive processing. For a bhajan channel, listen for the start and end of tracks, not only the loudest passage. For a local news loop, check speech against music beds and transitions. For an ambience or study channel, listen during quiet sections where a missing or intermittently muted input is easier to notice.
Test representative content before committing to a long broadcast. Include the fastest movement in the file, small text, fades, dark scenes, bright scenes and the loudest expected audio. A clean test using only a static poster can conceal problems that appear when a music video, scrolling ticker or animated visual begins.
A practical preflight is to run the intended MediaLive output into the YouTube channel workflow for long enough to observe startup, steady playback and at least one transition in the source. Watch the preview and YouTube's stream health, and inspect the final viewer picture on more than one type of connection if that is available to you. Record the selected resolution, frame rate, bitrate, GOP, codec and audio settings so that a later change can be traced.
If you are comparing cloud and local approaches, the choice affects more than encoding. A spare-PC setup may suit someone who already has a reliable machine and can maintain it; the trade-offs are described in how to set up an always-on YouTube channel with a spare PC. A file-based cloud workflow removes the need to leave that computer running. StreamNeo is useful when the specific problem is turning an uploaded video into a continuously monitored YouTube broadcast without installing software or keeping your own computer switched on.
Match MediaLive inputs to the real source
MediaLive input specifications affect resource allocation and billing, so choose them from the feed you actually receive. AWS advises selecting values that meet or exceed the most demanding inputs. If the allocated resources are insufficient, the output can degrade. That is why a generic input recipe is risky: a local camera feed, a mezzanine file, a cloud contribution feed and a simple loop may have very different requirements.
Before creating the channel, write down the source resolution, frame rate, codec, bitrate, scan type, audio tracks and whether the source changes during the day. If a live news feed can switch from one contribution format to another, design around the most demanding format that the channel will accept. If the channel is a fixed prerecorded loop, avoid selecting a more demanding input profile without a reason.
The output should still be checked independently. A high-specification input does not automatically make a high-quality YouTube stream, and reducing the output does not repair a poor source. MediaLive must decode the input, apply any required processing and encode the destination output. Each stage can become the limiting factor.
For a 24/7 channel, availability planning belongs beside settings selection. Decide what should happen when the source file ends, the contribution feed disappears or the MediaLive channel stops. A playlist or looping source may have different operational needs from a live local-news input. The available references do not establish one universal failover design, so document the behaviour you want and test it rather than assuming the service will choose it for you.
Monitor stream health and plan for availability
After the stream starts, monitor YouTube's stream health rather than relying only on the MediaLive channel state. A channel can be running while the destination reports a problem with the incoming stream, and a healthy ingest does not tell you whether the programme audio is correct. Check the preview, warnings, dropped frames or other health indicators shown in YouTube Studio, along with the MediaLive logs and alarms available in your own setup.
Create a simple operating routine. Confirm the stream key and destination before a planned change. Check the first minutes after startup. Review the stream after a source transition. Keep an eye on audio presence and output bitrate. When a problem occurs, note the time, the source content on screen and the relevant MediaLive and YouTube messages before changing several settings at once.
A 24/7 channel also needs a response plan for an overnight fault. Decide who receives an alert, who can stop or restart a channel, what viewers should see if the source is unavailable and how you will verify recovery. If the channel is run by one person in India or another time zone, an alert that arrives only on a workstation left at home is not a complete operating plan.
Watch bandwidth and data usage as well. A higher-resolution output consumes more data than a lower-resolution output, and the exact impact depends on the output rate and the time the channel remains live. The practical relationship is explained in how much data a 24/7 Indian music YouTube stream uses. That calculation is useful when checking network capacity and reviewing the broader operating cost, but it does not replace YouTube's bitrate guidance.
If you are streaming a prerecorded file, validate the file and its rights before scheduling a long run. An always-on technical setup does not make the programme suitable for YouTube or remove the need to review current platform policies. If your source is a file stored elsewhere, compare the operational steps with how to stream a prerecorded video to YouTube Live from Google Drive, while remembering that the MediaLive settings in this article still need to match the final output.
The settings worth keeping are the ones you can explain and observe: RTMPS for the ordinary destination path, H.264 for conventional SDR, CBR, a two-second GOP, the bitrate row matching resolution and frame rate, AAC audio and a documented test result. Everything else should be adjusted because your source, content or availability requirement calls for it, not because a preset claims to fit every channel.
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
What are the best AWS Elemental MediaLive settings for YouTube?
For a conventional SDR stream, begin with RTMPS, H.264, CBR, a two-second keyframe interval, a two-second MediaLive GOP and AAC audio. Select the bitrate from YouTube's current table for the exact resolution and frame rate, then test representative content and monitor YouTube's stream health.
What bitrate should I use for 1080p YouTube Live?
YouTube's current H.264 guidance lists 14 Mbps for 1080p30 and 17 Mbps for 1080p60. These are different starting points, so first confirm the actual output frame rate rather than choosing a single 1080p value.
Should I use RTMP or HLS with MediaLive?
Use RTMPS as the baseline for an ordinary SDR YouTube stream when the workflow supports it. HLS is more relevant to specific HDR or encoder-capability cases, and AWS's 4K HDR example should not be treated as a universal setting for every channel.
What GOP size should I use for YouTube Live?
Start with a two-second GOP and ensure the keyframe interval does not exceed four seconds. If you configure the GOP in frames, calculate it from the actual output frame rate and verify the saved MediaLive output settings.