A MediaLive stream that appears to disconnect can be interrupted at the source, at MediaLive’s output, or at YouTube ingest. Without the actual alert, YouTube health message, output configuration and matching timestamps, there is not enough evidence to name one cause.
Start by finding which boundary failed and what each system reported. Then change one setting at a time, if the evidence points to a setting, and check whether the same symptom returns.
Identify when and where the stream drops
First separate what you can see from what you know. A viewer saying “the stream went down” might mean a brief freeze, a black picture, an ended broadcast, or a stream that stopped appearing in YouTube. Those symptoms are not interchangeable. Record the time, what viewers saw, and whether playback resumed without restarting anything.
Check the MediaLive channel and output status alongside YouTube Live Control Room. Did MediaLive raise an alert? Did the output stop, or did it remain active while YouTube reported a stream-health problem? Is the broadcast still live in YouTube, even though playback has stalled? YouTube’s Live Control Room stream-health guidance explains where to find live status and messages. Read the message itself rather than translating every warning into “disconnect”.
Keep the possible boundaries distinct:
| What you observe | Evidence to collect next | What it does not prove by itself |
|---|---|---|
| MediaLive reports an input alert | Alert text and time; source status | That the YouTube output connection failed |
| MediaLive output reports a destination problem | Output event and retry history | That YouTube rejected the video profile |
| YouTube reports a stream-health error | Exact Live Control Room message and time | That MediaLive stopped sending data |
| Viewers report interruptions only | Their timestamps and playback symptoms | That either control plane recorded a disconnect |
Treat this as a branching check, not a ranking of likely causes. A repeated pattern at one boundary may be useful; a single “stream disconnected” report is not enough to identify the boundary. Keep a short incident note with the channel name, event time and exact wording from each screen. If you need to reproduce the workflow later, the pre-flight checks before leaving a stream running offer a useful operational checklist, but the evidence in this incident should lead the diagnosis.
Read MediaLive alerts and destination retries
Open the MediaLive channel’s alerts and identify whether each message refers to an input or an output. AWS lists RTMP input alerts including 5308, for an RTMP server disconnect, 5305, for a stream not found, 5307, for no audio or video, and 5309, for a connection failure. These are input alerts. They can help you locate an upstream problem, but they do not automatically establish that MediaLive lost its connection to YouTube. AWS’s MediaLive alert reference provides the relevant alert descriptions.
For an RTMP output, inspect the connection and retry fields in the channel configuration. AWS documents cache length, cache-full behaviour, restart delay, connection retry interval and retry count as controls for reconnection. Their precise effect depends on the configured values and what the destination is doing. If a cache fills, the selected behaviour can make MediaLive disconnect immediately or wait for the server; the wait behaviour can last up to five minutes. After a disconnect, MediaLive waits for the restart delay and then retries at the configured interval. If it exhausts the configured retries, that output stops. See the current AWS RTMP connection guidance before interpreting your channel’s fields.
Compare the configured values with the event timeline. If an output retry sequence starts at the same time YouTube reports a connection issue, that correlation deserves attention. If retries are not recorded and the MediaLive output remains active, do not assume that increasing the retry count addresses the observed viewer interruption. More retries can extend recovery attempts after a destination stall; they do not correct a bad stream key, an upstream source interruption, or an incompatible output profile.
There is also an important distinction between loss of input and loss of the RTMP output connection. MediaLive’s input-loss behaviour is configured separately. For an RTMP output group, pausing delivery after input loss does not close the underlying RTMP connection. The picture may freeze or disappear while the destination connection is still established. AWS describes this in its input-loss behaviour documentation. Check both states before calling a frozen picture a destination disconnect.
Inspect the upstream source and network
Trace the video from where it enters MediaLive. Identify whether the channel receives a live source, another contribution feed or a different input, then check whether that source was producing audio and video at the time of the incident. Look for a source-side alert, loss of signal, encoder restart or a gap in its own event history. The exact signal available will vary with your input and monitoring; record what the source actually reported rather than inferring a failure from the YouTube playback alone.
If there is an encoder upstream, check its output status and local CPU load around the same time. YouTube’s general live streaming troubleshooting guidance advises checking encoder output and CPU load, and checking outbound connectivity if encoder output looks healthy. Apply that guidance to the sender you operate, without assuming that every MediaLive input uses a local computer or encoder. If the source is not yours, ask its operator for timestamped logs rather than changing your own output settings in response to a suspected upstream issue.
Network evidence needs context. A connectivity check taken after the stream recovers does not establish what happened during the interruption. Compare any network event or monitoring alert with the source and MediaLive timestamps. If the stream uses a local Windows sender, the operational considerations in running OBS through Indian power cuts are relevant only when that is genuinely part of your source path. They are not evidence that a power interruption caused this particular incident.
Avoid swapping cables, routers or computers without evidence of a local hardware fault. The research available for this symptom does not point to a particular item to buy, and equipment changes can create a new variable without telling you which boundary failed. If you do test a network or source change, write down the original state and change just that one thing.
Review output configuration and delivery
Once you have checked the source and retry history, compare the configured MediaLive destination and output profile with the current YouTube ingest requirements. Confirm that the destination URL and stream key correspond to the intended YouTube broadcast, and verify them carefully in the channel configuration. YouTube’s encoder troubleshooting guidance specifically recommends checking the stream key when an encoder cannot start. Do not paste a key into an incident note, ticket or screenshot that others can access.
Then compare protocol, codec, resolution, frame rate, bitrate, rate control and keyframe interval with YouTube’s current guidance for the profile you are sending. YouTube recommends RTMPS, constant bit rate (CBR), and a two-second keyframe interval, with an interval no longer than four seconds. Its bitrate recommendations vary by codec, resolution and frame rate. Use the row for your actual profile in the current YouTube encoder settings, bitrates and resolutions guide; do not treat one bitrate as correct for every output.
These are distinct checks. MediaLive’s retry and cache fields describe what it does after a destination stall. The video profile describes what is being sent for YouTube to ingest. A retry adjustment cannot make an unsupported or misconfigured profile conform, and a profile change cannot repair a source that stopped supplying frames. You can use the 4K 60fps playlist configuration guide as background on the fact that resolution, frame rate and delivery choices belong together, but compare your own profile with YouTube’s official table.
Make a written copy of the current output configuration before testing changes. Include the destination protocol, codec, resolution, frame rate, bitrate, keyframe interval, cache-full choice and retry fields. If a setting is already aligned with YouTube’s guidance, leave it alone while you investigate another boundary. This keeps a test interpretable and makes it easier to restore the known configuration if the result is worse.
Check YouTube ingest status and messages
Open the correct event in Live Control Room while the stream is live, and note the health status and exact wording. A message about missing data, a key or stream configuration is more useful than a viewer’s general report, but still needs to be matched to what MediaLive was sending at that time. YouTube exposes stream health and specific messages during a live event; its stream-health help page describes that view. Capture the time as well as the text because messages can change as conditions change.
Check that the stream key and ingest destination configured for the MediaLive output match the intended YouTube event. If the key was rotated, an event was replaced, or someone edited channel settings, record when that happened. Treat credentials as sensitive: compare them through the approved console or secret-handling process rather than copying them into a public support request.
A warning in Live Control Room does not, by itself, tell you whether MediaLive stopped sending data or YouTube rejected it. Look at MediaLive output status and retry events for the same minute. Conversely, an active MediaLive channel is not proof that YouTube is receiving a healthy profile. The output can be running while the ingest service reports a problem with data or configuration. Check both views before choosing a change.
If you have a scheduled test window, use it to verify the full path before relying on a long-running broadcast. YouTube recommends testing in advance and monitoring stream health during the event. A test does not guarantee that a later event will behave identically, but it gives you a chance to confirm that the selected event, key, destination and output profile work together under the conditions you can observe.
Compare timestamps across both systems
Build a single timeline from the MediaLive alert or output event, the source or network event, YouTube’s health message, and the viewer report if available. Use a consistent time zone. If one console displays local time and another UTC, convert the times before drawing conclusions. Note when the issue began, when each system recorded it, when retries started, whether the output stopped, and when playback recovered.
The order can narrow the investigation without proving a cause. For example, an input alert that precedes a video freeze while the output connection remains up points you towards input-loss handling and the upstream source. A destination retry sequence that coincides with YouTube reporting an ingest interruption points you towards the output path and destination response. A YouTube profile warning while MediaLive continues delivering suggests a different test from an input loss. Each is a lead to verify against configuration and messages, not a diagnosis based on timing alone.
Do not treat a lone alert, a generic viewer report or the word “disconnect” as decisive. Clocks may differ, events may be delayed, and several symptoms can occur close together. If you cannot establish the sequence, say so in the incident note and collect more evidence during the next test rather than changing several settings at once.
Test one change at a time
Choose a change only after the evidence points to the relevant boundary. If the source disappears first, investigate the source and its delivery path. If MediaLive records output failures and retries, review the destination response and configured retry behaviour. If YouTube reports a profile issue while the output remains active, compare the exact profile with the current YouTube table. These are possible directions for investigation, not claims about what caused your stream.
Before each test, record the baseline configuration and the symptom you are testing. Change one value or one clearly defined element, run a controlled test, and compare the new timeline with the old one. If you change the key, profile, retry values and source at the same time, a successful test will not tell you which change mattered. A failed test will be equally hard to interpret.
Keep the test proportionate to the broadcast. A brief rehearsal can verify that the event starts and that health messages look normal at that moment; it cannot establish how a long overnight run will behave. For a channel built from prerecorded material, the operational choices in running a 24/7 stream from a Windows PC in India may help you think through the sender side, but only if that is your setup. MediaLive and a local PC are different delivery paths, so do not transplant settings or explanations without checking the actual configuration.
If the same interruption remains and the evidence is still ambiguous, preserve the timeline, alert text, health message and redacted output configuration for the team responsible for the source, AWS account or YouTube event. A qualified AWS Support contact or media workflow specialist may be appropriate when the channel remains blocked, but no support route can be assumed to have a particular outcome. The next useful step is the one that supplies missing evidence, not another speculative setting change.
When your test configuration and channel are ready, compare operating options and proceed only with a clear understanding of the delivery path.
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 a MediaLive RTMP input alert prove the YouTube output disconnected?
No. An RTMP input alert describes the input side, so it is not by itself evidence that the output to YouTube failed. Check output status and retry events alongside the source alert and YouTube health message.
Should I increase the retry count first?
Not without checking the output event and current retry settings. Retries can affect what happens after a destination connection problem, but they do not establish why it happened or fix an upstream input loss or an ingest-profile problem.
What YouTube settings should I verify?
Check the destination and stream key, protocol, codec, resolution, frame rate, bitrate, rate control and keyframe interval against YouTube’s current guidance for your profile. YouTube recommends RTMPS, CBR and a two-second keyframe interval, with a maximum interval of four seconds; consult its table for the applicable bitrate.
What information is needed to identify the cause?
Collect the exact MediaLive alert or output event, whether the output stopped or playback alone dropped, the configured destination and retry/cache values, YouTube’s health message, the output profile and a shared timeline. Until those details line up, the cause remains undetermined.