A MediaLive HLS input and a YouTube HLS destination are different things. The input pulls an upstream playlist into MediaLive; YouTube’s ingest URL belongs in the channel’s output configuration, using a protocol YouTube accepts.
When the stream is black, trace the picture from source to YouTube and note where it first disappears. That gives you a useful diagnosis before you change encoder settings or restart services.
HLS input and YouTube destination are separate stages
An HLS input tells MediaLive where to fetch a source feed: an upstream HLS playlist, typically published by another encoder or service. It is not the place to enter YouTube’s ingest URL. MediaLive then processes the incoming feed in a channel and sends the resulting encoded output to a destination.
The direction matters. The signal path is upstream source → MediaLive input and channel → output → YouTube. YouTube’s ingest address is at the far end of this chain. Putting it into the HLS input field does not configure a YouTube destination; it gives MediaLive the wrong kind of address for the source it is meant to pull.
YouTube’s live ingest guidance lists RTMP and RTMPS as supported protocols. That is separate from the protocol used between your upstream source and MediaLive. Confirm the protocol and connection details for each side independently rather than assuming that an HLS source means an HLS destination.
This distinction is useful whether the picture is black from the first frame or turns black later. First ask which stage can still show a valid picture. A locally visible source points away from the original programme file, but it does not prove MediaLive can fetch or decode the upstream stream. Likewise, an active YouTube event does not prove that its incoming video contains usable frames.
Gather the upstream playlist URL and credentials
Before creating the input, obtain the source details from the provider or person operating the upstream encoder. You need the playlist URL and any required authentication information, such as a username and password, token, or other access mechanism. Ask whether the URL is a master playlist or a media playlist, whether it changes, and whether the source is expected to be available continuously.
Do not substitute the YouTube ingest URL for this source URL. The upstream playlist is the address MediaLive reads; YouTube’s destination address is configured later as an output. If you have several URLs, label them by direction and purpose before entering anything into a console.
Check that the playlist can be reached from the service that will retrieve it, not only from your laptop or office network. A browser test may show that a URL exists while still failing to reproduce the credentials, network access, playlist updates, or media segments that a live pull requires. Ask the source operator to confirm that the playlist is currently publishing video and audio, and whether access is restricted by network rules.
Record what the upstream signal is meant to contain: video codec, audio codec, resolution, frame rate, and whether it is a single rendition or an adaptive set. Compare those facts with the input type you plan to select and the MediaLive supported-codecs guidance. Codec support varies by input type, so do not infer compatibility just from the fact that the URL ends in .m3u8.
Protect credentials as you collect them. Keep the URL and secrets out of public tickets, screenshots, and chat messages. If a test fails, share the time and the relevant status rather than pasting a usable credential into a support channel. Keep a private note of which playlist is the source and which address is the eventual destination.
Create the MediaLive HLS input
In MediaLive, create an input whose type matches the actual upstream source. For this path, that means an HLS input configured with the upstream playlist details and any required credentials, not an output aimed at YouTube. Follow the current AWS console fields and permissions for your account; console labels can change, so verify each value against the service documentation rather than relying on an old screenshot.
Use the source facts you gathered to check the configuration. If the source uses a codec that is not supported for the chosen input type, a successful-looking URL entry will not make its video usable. Check the supported codec list for the selected input and resolve a mismatch with the upstream operator or by selecting a compatible source and input arrangement.
Once the input is created, confirm that it is the intended source and that the source is actually present. MediaLive probes the input when a channel starts. AWS notes that a channel can fail to start if it cannot detect the input; possible causes include an absent source, settings that do not match, or a source that exceeds channel specifications. These are possibilities to investigate, not a diagnosis of your particular event.
A practical check is to keep a small record of the source URL label, input name, expected codecs, and the time you last confirmed the upstream feed. Do not copy sensitive credentials into that record. If the input is shared or one of several similar feeds, confirm the selected input by name and purpose before moving to the channel. An input pointed at a valid but unrelated playlist can be just as confusing as a missing source.
Configure the channel to use that input
Create or edit the MediaLive channel and select the HLS input you just configured. The channel connects the input to the encoding configuration and outputs; creating an input alone does not send anything to YouTube. Check that the channel references the intended input rather than a stale or similarly named source.
Match the encoding profile to what the source can supply. AWS’s live-streaming architecture example describes the upstream source, MediaLive input and channel, and downstream output as separate stages, and recommends an encoding profile that fits the source resolution. That is a sound troubleshooting principle: do not ask an encoder to produce a profile that the source cannot meaningfully provide, and do not treat a higher output resolution as a remedy for missing video.
Before starting, review the input and channel configuration together. Confirm the source type, codecs, video dimensions and frame rate are consistent with the channel’s expectations. If the channel reports an input-detection problem, return to the upstream URL, reachability, credentials, and codec checks instead of changing YouTube’s destination settings. The AWS MediaLive User Guide documents input probing and input-loss behaviour; check the current guide for the options exposed in your channel.
If a channel is already running but displays black, inspect its input-loss and failover settings. AWS documents a default replacement sequence in which MediaLive repeats the last valid frame for 1,000 milliseconds, encodes black frames for 1,000 milliseconds, and then uses a black slate indefinitely. A black output can therefore indicate loss of usable input rather than a black image created by YouTube. Those timings describe the documented default, not channels whose replacement settings have been customised.
Choose YouTube’s ingest protocol and obtain its URL
In YouTube Live Control Room, prepare the event and choose an ingest option that is compatible with the MediaLive output workflow. YouTube’s live encoder guidance lists RTMP and RTMPS. Use the current official instructions for the event to obtain the server address and stream key, and keep the key private. The YouTube live encoder settings explain current protocol and encoding guidance.
Treat the ingest address and key as destination credentials. They do not belong in the MediaLive HLS input. If you need a refresher on which YouTube fields are which, see this guide to finding the RTMP ingest URL and stream key. It covers the destination side; this article’s HLS input is still the separate upstream side.
Before using the destination in a production event, verify that the chosen YouTube event is the one you intend to receive the feed. A key copied from a different event can direct output somewhere unexpected. Do not put the key in a screenshot or log shared outside the people who need it, and replace it if you believe it has been exposed. Keep a note of which event and output it is associated with without recording the secret itself.
Configure and check the MediaLive output
Add an output that sends the encoded programme to YouTube using the destination details you obtained. Set the output’s protocol and destination according to the MediaLive and YouTube workflows in use. The critical separation remains: the input points upstream; the output points to YouTube. Check the destination and stream key carefully, but avoid displaying the key while troubleshooting.
Confirm that the output includes an active video encoder, not just audio, captions, or a slate. Check that the selected video source and output are connected as intended, and that resolution and frame rate are sensible for the incoming source. A channel may be producing audio while the video path is absent or invalid, so record whether audio continues rather than treating an audible stream as proof that the picture is good.
Compare the encoded output with YouTube’s current settings. YouTube lists H.264, H.265/HEVC and AV1 as supported video codecs, up to 60 fps, CBR encoding, and a recommended keyframe interval of two seconds, not exceeding four seconds. Its bitrate recommendations depend on codec, resolution and frame rate. For example, its current table gives H.264 at 1080p30 a recommended 14 Mbps and 1080p60 a recommended 17 Mbps. These are YouTube recommendations, not a universal explanation for black video; use the row for the actual output rather than copying a value from a different format.
A frame-rate mismatch is worth checking because it can complicate what you see downstream, but it is not a substitute diagnosis for a missing source. If the source is 30 fps and the configured output or monitoring assumption is 60 fps, follow the checks in the frame-rate mismatch guide. Verify actual values at each stage before changing them.
Start the stream and find the first black frame
Use a controlled test before the public event. Include representative movement and audio, then check the source locally or at the upstream encoder, MediaLive input and channel status, any available output monitoring, and the YouTube Live Control Room preview. YouTube recommends testing with audio and movement similar to the planned stream and watching stream health and messages during delivery. Its preflight guidance is a useful checklist, but it cannot identify a fault in your AWS configuration on its own.
Write down where the image first turns black and whether sound remains. Also note whether it is black at startup or changes after an interruption. Those three observations help separate a source problem, input detection or decoding problem, expected input-loss replacement, encoder path problem, and receiver-side symptom without guessing. Keep the time of each observation so that you can compare the source, MediaLive and YouTube messages from the same moment.
| First place showing black | What to inspect next | Useful distinction |
|---|---|---|
| Upstream source or encoder | Programme output, source selection, and whether video is being published | If the source is already black, downstream changes cannot restore its picture |
| MediaLive input or channel | Input presence, URL access, credentials, type, codecs, and input-loss behaviour | Startup detection failure differs from a channel that loses input after running |
| MediaLive output monitoring | Video encoder selection, source mapping, output profile, and destination configuration | Check that video is encoded before focusing on YouTube playback |
| YouTube Live Control Room preview | Ingest protocol, destination event and key, encoder settings, and stream-health messages | If MediaLive output looks valid but preview is black, inspect the hand-off to YouTube |
| Only one viewer’s playback | Device, app or browser, event time, and whether other viewers see the same result | Do not assume a viewer playback issue means the incoming live feed is black |
A black preview at YouTube does not by itself prove that YouTube created the black image. If the preview is wrong, stay on the source-to-ingest path and compare the earliest available monitoring points. If the preview looks right but one viewer sees black, capture the event URL, device or app, time, and stream-health state before changing the encoder. The available guidance does not establish a universal black-screen error code or guarantee that every playback symptom appears in stream health.
For long-running channels, include the checks in your runbook rather than relying on memory during an interruption. A 24/7 recorded YouTube workflow is a useful example of why source preparation, the live channel and monitoring need to be treated as separate jobs. If your programme is an MP4 loop, this guide to looping an MP4 with SRS and FFmpeg covers a different source workflow; it does not change where a MediaLive HLS input or YouTube output belongs.
When the source, input, channel, output and destination are each confirmed, save the working configuration and record which values were checked. Avoid changing several stages at once: a before-and-after result is useful only if you know what changed. If the issue persists, share timestamps, non-secret status messages, the observed first black point, and whether audio continued with the relevant support team.
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
Can I paste YouTube’s URL into a MediaLive HLS input?
No. The HLS input is for the upstream playlist MediaLive pulls from. YouTube’s ingest URL and stream key are destination details for the MediaLive output, configured separately.
Why can MediaLive show black after the source stops?
AWS documents a default input-loss replacement sequence that moves from the last valid frame to black frames and then a black slate. If your channel uses customised replacement settings, the behaviour may differ; check the channel configuration and current AWS documentation.
Should I change bitrate first when the YouTube preview is black?
Not without checking where the picture first becomes black. Verify the source, MediaLive input and output, and YouTube preview in order; then compare the actual output settings with YouTube’s current guidance. A bitrate recommendation is not evidence that bitrate caused a black image.
What if the YouTube preview is fine but one viewer sees black?
Treat that as a separate playback symptom until you have evidence that the incoming preview is also affected. Record the event URL, device or app, time and stream-health state, and check whether other viewers see the same thing before changing a working MediaLive configuration.