A MediaLive input problem can happen before the channel starts or after it has already acquired a healthy source. Check which case you have first: a startup probe failure needs the input or channel configuration corrected, while ongoing input loss needs source, network, MediaLive and YouTube checks in sequence.
Do not assume that YouTube caused the incident because the broadcast is visible there, and do not assume that a configured slate will repair a failed startup probe. The fault may be upstream of MediaLive, inside its input path, in the channel output, or at YouTube ingest.
Establish when the failure began
Write down the time of the first error and what the channel was doing at that moment. There are two materially different paths to investigate.
If the channel failed while starting, MediaLive was probably unable to probe and identify its first input. AWS documents that a failed startup probe can fail the input and the channel immediately. Typical causes include an absent RTMP source, a source that does not fit the channel's specifications, or incorrect input settings. In that case, the normal input-loss replacement sequence is not a recovery mechanism. Correct the source or configuration, then restart the channel.
If the channel had been encoding valid content and then lost the source, you are dealing with ongoing input loss. MediaLive can continue encoding replacement content while the source video is missing. That changes what you should look for: the channel may remain running even though the useful programme has disappeared.
A simple timeline helps separate the cases:
| Observation | Most useful first check | Likely handling |
|---|---|---|
| Channel never starts | Input probe, source presence and input settings | Correct the input and restart |
| Source was healthy, then disappeared | Upstream encoder and network path | Restore the source or allow failover |
| MediaLive output continues with black or slate | Replacement-content settings and input metrics | Confirm whether loss is upstream |
| MediaLive looks healthy but YouTube reports an error | Output destination and YouTube Live Control Room | Diagnose ingest separately |
Keep the timestamps in UTC or record the time zone clearly. Compare the source logs, MediaLive metrics and YouTube messages against the same clock rather than relying on memory.
Check the input probe and source health
Start at the source that is meant to feed MediaLive. Confirm that the encoder process is running, the intended input is selected, and the encoder is actually publishing rather than merely showing a connected interface. A camera, file player or local capture card can appear healthy on the operator's screen while the outbound contribution has stopped.
For RTMP, check whether the publishing process is present at all. A missing RTMP input is one of the documented reasons for a startup probe failure. For RTP or other supported inputs, confirm the expected address, port and transport settings, then check that packets are leaving the source network.
Compare the source's own indicators with MediaLive's input metrics. AWS describes InputVideoFrameRate as an input-health indicator. A stable value that matches the source is reassuring; a value that moves unpredictably, falls to zero or repeatedly recovers points towards the source or the path between the source and MediaLive.
For supported RTP or MediaConnect inputs, inspect InputLossSeconds. A consistently zero value indicates that the input is arriving normally. Values that rise and return to zero suggest a loss and recovery pattern, while repeated maximum values indicate a persistently unhealthy input. Look across several time windows instead of reacting to one isolated datapoint. If automatic input failover is configured, use the active-input dimension so that the metric describes the input currently feeding the channel.
The source format also matters. Check resolution, frame rate, audio presence and any channel-specific input requirements against the MediaLive configuration. A source can be publishing packets and still fail the probe or be rejected because it does not match what the channel expects.
Do not change several settings at once. First record the configured input type and source details. Then verify one boundary at a time: source process, published stream or packet flow, MediaLive input status, and channel state. This leaves you with evidence about the fault instead of a collection of untested changes.
If your source is a virtual machine or cloud PC, resource pressure can interrupt the contribution even when the process remains open. CPU saturation, a full disk, a stalled media file or an unstable network interface can each produce input loss. For background, the practical checks in How Much RAM Does a 24/7 Nature Stream Need on a VPS? are useful when the source runs continuously on a small machine.
Trace the upstream network path
Once you know whether the source is publishing, follow the path to MediaLive. The useful question is not simply whether the internet is working. It is whether the particular stream can reach the configured MediaLive input continuously and with the expected transport behaviour.
Check firewalls, security groups, network access lists and any NAT or port-forwarding rules involved in the contribution path. For RTP, verify that the required protocol and port are permitted in both directions where the design requires it. For RTMP, confirm that the publishing destination and credentials have not changed. A recent router, ISP or cloud-network change can affect one destination without affecting ordinary web browsing.
Look for a pattern in the timing. Loss beginning at the same time every day may indicate a scheduled source task, an encoder restart or a network policy. Short repeated gaps suggest packet loss, congestion or a process that is repeatedly reconnecting. A complete and sustained stop points more strongly towards a stopped source, a blocked route or an invalid destination.
Where you control the upstream encoder, collect its reconnect and send-rate logs. Where you control the network, review interface errors, route changes and relevant firewall events. Do not treat a successful ping as proof that an RTMP or RTP contribution is healthy. The media protocol, port and sustained packet flow are what matter.
Automatic input failover is only independent if its alternate source and path are independent. Two publishing processes on one encoder, or two addresses reached through the same broken router, can fail together. AWS's guidance for RTMP and RTP failover specifically requires the first input to have a different network path to MediaLive from the second input.
A useful incident test is to observe the source and MediaLive at the same time. If the source stops sending and MediaLive's input metric rises, the boundary is before or at the input path. If the source continues sending normally but MediaLive sees loss, investigate routing, transport and the configured input. If MediaLive sees the source but YouTube does not, move to the output side rather than changing the source.
Read MediaLive input and channel metrics
The MediaLive console shows state, but metrics provide the timeline needed for intermittent faults. Review input frame rate, input loss and the active input over the period before, during and after the incident. Note whether the channel changed state, switched inputs or continued encoding replacement content.
Input loss is not necessarily the same as a stopped channel. AWS describes a running channel as needing to continue encoding content, so MediaLive can produce replacement output when the source video vanishes. That output may be a repeated frame, black video or a configured slate. Seeing a healthy channel state therefore does not prove that the programme source is healthy.
The default replacement sequence described by AWS is to repeat the last valid frame for 1,000 milliseconds, encode black frames for 1,000 milliseconds, and then send a black slate indefinitely. These intervals can be customised, and you can choose a slate image or colour. AWS documents 32-bit BMP, PNG and TGA as slate image formats.
Do not confuse the speed of input-loss handling with the time required for automatic failover. AWS gives an example in which a missed expected frame can trigger input-loss handling. At 60 frames per second, one frame is about 17 milliseconds. AWS also describes 1,000 milliseconds as a typical configurable failover trigger. The first concerns replacement content; the second concerns when a configured alternate input should be selected.
Compare the metric timeline with the programme output. If input loss rises while the channel remains active and the output changes to black, the source-to-MediaLive leg is the leading suspect. If input metrics remain healthy but the output or YouTube health indicator fails, inspect the channel output and destination. If the active input changes, examine both the failing input and the replacement input rather than assuming that the switch itself fixed the underlying problem.
Set alerts for a condition that gives you time to act, not for every brief fluctuation. A sustained input-loss condition, a persistent drop in frame rate or an unexpected active-input change is more useful than a notification for a single transient datapoint. Tune the alert against your content and normal network behaviour, then test that it reaches the person responsible for the channel overnight.
Review replacement-content handling
Replacement content answers a narrow question: what should MediaLive encode when its current source video is missing. It does not restore the upstream source, validate a YouTube key or prove that viewers are receiving the intended programme.
Review the configured repeat-frame interval, black-frame interval and slate. A short repeat may be appropriate for a news or information loop, while a clear branded slate may be less confusing for a devotional, study or ambience channel. The choice is operational rather than cosmetic: viewers should be able to distinguish a temporary source fault from a normal part of the programme.
For HLS, Microsoft Smooth, RTMP and UDP/TS output groups, AWS allows you to configure whether replacement content is delivered or discarded. MediaPackage pauses delivery during input loss, while other output group types always deliver replacement content. Check the output group in use before assuming that the console setting will affect every downstream destination in the same way.
If you see a repeated still image on YouTube, that may be MediaLive doing exactly what it was configured to do. If you see a black screen, it may have moved through the repeat and black-frame intervals into the slate stage. Record the time at which each change appears and compare it with the input-loss metric.
A slate is also not a substitute for a backup source. It can keep an output structurally active, but it cannot preserve the intended live content. For a channel that must continue showing a programme, plan a valid alternate input. For a channel where a transparent outage notice is preferable to stale content, design and test the slate instead.
Check MediaLive output and YouTube ingest
Only move to YouTube after confirming whether MediaLive is receiving the source and what it is encoding. In YouTube Live Control Room, inspect the health indicator and the timestamped error messages. YouTube distinguishes critical red errors from moderate yellow errors, and its guidance covers stream format, audio and video codec, video stream count, interlacing, frame rate and keyframe frequency.
Check the MediaLive output destination carefully. Confirm the YouTube stream URL and the current stream key, including accidental spaces, an old key or a key belonging to a different event. YouTube describes the stream key as the encoder's stream credentials and address information. If you reset a compromised or obsolete key, update the MediaLive destination before testing again. Use YouTube's stream key guidance and its live streaming setup guidance rather than copying a key from an old channel configuration.
YouTube's encoder guidance recommends RTMP or RTMPS, H.264, H.265 or AV1 video, AAC or MP3 audio, constant bitrate and keyframes every two seconds, with a maximum interval of four seconds. Match the setting to the error shown in Live Control Room rather than changing every output parameter at once.
For one concrete reference point, YouTube lists 5 Mbps as the minimum and 14 Mbps as the recommended bitrate for H.264 at 1080p and 30 frames per second. That figure applies to the stated codec, resolution and frame rate, not to every MediaLive output. YouTube's encoder settings documentation should be checked for the combination you actually send.
If YouTube reports a format or keyframe problem while MediaLive input metrics are healthy, the fault boundary is probably between MediaLive's output and YouTube ingest. If YouTube reports no current ingest but MediaLive is showing input loss, fix the earlier boundary first. A YouTube error appearing at the same time as source loss may be a consequence of replacement output or a separate output fault, so compare the timestamps.
Test with representative movement and audio before a long broadcast. A static test picture can hide frame-rate, audio and keyframe problems that appear once the real playlist or camera feed is running. During the event, keep the Live Control Room health messages visible and record the first error rather than only the final state.
If the ongoing source is a self-hosted process, also review the reconnect path described in How to Reconnect a 24/7 YouTube Livestream Automatically on a VPS in India. The principle is the same here: recovery logic must be checked against the actual failure boundary, not just the fact that a process is still running.
Plan input failover where it is justified
Automatic input failover protects against loss of an eligible input and its path. It is not the same as input-loss replacement, and it is not pipeline redundancy. Decide which failure you are trying to cover before adding a second input.
For RTMP and RTP automatic failover, AWS requires the alternate sources to carry identical content, including video, audio, captions and metadata, and to arrive over different network paths. A second input from the same encoder and route is duplication without independence. If the encoder, router or upstream connection fails, both copies can disappear together.
AWS's setup guidance also describes different source requirements for channel configurations. A single-input channel needs two sources for the pair, while a standard channel needs four, with two sources per input. Confirm the current AWS configuration documentation for your exact channel type before building the design.
The documented startup guidance says the active input switches after it has been unhealthy for 3 seconds, and a recovered input is marked healthy after it has remained healthy for more than 30 seconds. These are behaviour details for the described configuration, not a promise that every channel design will switch or fail back identically.
Failback preference matters. With equal preference, the channel may remain on the secondary after recovery. With primary preference, it may switch back when the primary is healthy. Decide whether automatic return is desirable. For a long unattended channel, avoiding repeated switching may be more important than returning immediately to the preferred source.
Compare the controls this way:
| Mechanism | Covers | Does not cover | Check before relying on it |
|---|---|---|---|
| Input-loss handling | Missing video from the current input | A stopped source or restored programme | Repeat, black and slate behaviour |
| Automatic input failover | Failure of an eligible input or path | A shared encoder or shared route | Matching content and independent paths |
| Pipeline redundancy | Failure of a MediaLive pipeline | A bad source feeding both pipelines | Downstream ability to accept and switch between two outputs |
Pipeline redundancy is a separate channel-level design. AWS notes that downstream handling must be able to accept and switch between two outputs for this resilience approach. Do not buy or configure a second protection layer without checking what the destination can actually consume.
Run a controlled test before depending on failover overnight. Stop the primary source, observe the input metric and active-input change, verify the alternate programme, then restore the primary and observe the configured recovery preference. Record what viewers see on YouTube. If maintaining a cloud-hosted source is itself the problem, StreamNeo removes the need to keep a local streaming computer running for a file-based YouTube channel, but it does not replace MediaLive's input design for a live contribution.
Turn the diagnosis into an operating checklist
After the incident, write a short runbook that follows the same boundary order every time:
- Record the first failure time and decide whether it was startup or post-acquisition loss.
- Check the source process, source format and publishing or packet flow.
- Compare source evidence with MediaLive input frame-rate and loss metrics.
- Inspect routes, firewall rules and whether any alternate path is truly independent.
- Check active input, channel state and replacement-content behaviour.
- Confirm MediaLive output destination, stream URL and current YouTube key.
- Read YouTube's timestamped health message and correct only the relevant output setting.
- Save screenshots or metric exports, then test recovery rather than declaring success when the console turns green.
For recurring channels, add an alert for sustained input loss and an unexpected active-input change. Assign ownership for overnight alerts, keep the source and YouTube credentials documented securely, and test a planned failure during a quiet period. A runbook that says “restart everything” is less useful than one that identifies the first boundary that stopped behaving normally.
Keep content and platform checks separate as well. A channel can have a technically healthy MediaLive path and still face YouTube restrictions or copyright questions. Before changing infrastructure, review the relevant guidance on YouTube live streaming restrictions for channels with strikes and make sure the material you broadcast is appropriate for the 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
Why did MediaLive fail at startup instead of showing my slate?
A startup probe failure occurs before MediaLive has acquired a usable first input. AWS says the input and channel can fail immediately when the source is absent, incompatible with the channel specifications or incorrectly configured. Correct the source or input settings and restart the channel rather than expecting ongoing input-loss handling to recover it.
Does a running MediaLive channel prove that the source is healthy?
No. MediaLive can continue encoding replacement content when source video is missing. Check input frame rate, input loss and the active-input dimension, then compare those metrics with the source encoder and the picture reaching YouTube.
Can a second input prevent every interruption?
No. Automatic failover needs a valid alternate source carrying the same content and a genuinely independent network path. Two sources that share an encoder, router or connection can fail together, and failover does not protect against every channel or downstream output problem.
When should I investigate YouTube instead of MediaLive?
Investigate YouTube output after confirming that MediaLive is receiving the source and producing the expected output. Read the timestamped Live Control Room error, then check the stream URL, current key, codec, bitrate, frame rate and keyframe interval. This prevents a YouTube ingest error from being confused with an earlier source-to-MediaLive failure.