A nonzero AWS Elemental MediaLive DroppedFrames metric means the encoder is dropping input frames because it cannot process them fast enough to keep up with real time. It does not, by itself, identify why that is happening or tell you what YouTube is receiving.
Check the metric for the affected pipeline and incident window, then compare the configured output with YouTube Live Control Room’s stream-health observations. The signals describe different parts of the path; use them together with the actual settings before diagnosing a cause.
What MediaLive’s DroppedFrames indicates
AWS defines DroppedFrames as the number of input frames dropped during the metric period. A nonzero value is evidence of an encoder-processing problem in that period, in the specific sense that MediaLive is not keeping up with incoming video in real time. It is not a general counter for frames lost anywhere between the source and YouTube.
That distinction matters when a viewer reports stuttering, a delayed picture, or a frozen live page. A viewer’s experience is an end-to-end result; DroppedFrames is one metric from the MediaLive output side. A nonzero value makes encoder processing worth investigating, but the metric alone cannot establish whether it explains the viewer’s symptom, what triggered it, or whether YouTube has separately observed an ingest issue.
AWS recommends using the Sum statistic for this metric. Review the Pipeline dimension and Region in CloudWatch as well as the metric name: a chart without the right dimension may show a different pipeline from the one carrying the affected output. For a wider view of the path, AWS also exposes output metrics such as NetworkOut; that is useful context, not an interchangeable version of DroppedFrames.
Do not read an empty chart as proof that output is healthy. AWS notes that a missing datapoint can mean the channel is stopped, initializing, waiting for initial input, paused, or not producing output. First establish that the channel should have been producing video at the time in question.
The guide to handling upload drops on an Indian broadband connection covers a different streaming path, but the same diagnostic discipline applies: identify which measurement belongs to which part of the path before drawing a conclusion.
Confirm the pipeline and incident window
Start with the time, not with a settings change. Write down when the symptom began and ended, allowing for the fact that a report may arrive after the viewer first noticed it. In CloudWatch, graph DroppedFrames as Sum over that window, for the active channel and its Pipeline dimension. Check Region too, particularly if you manage more than one channel or regional configuration.
Compare the graph with the channel’s state. If the channel was starting, waiting for input, paused, or stopped, an absent metric point means something different from a zero value during a steady output period. Check adjacent periods before and after the report so you can see whether a rise coincides with the symptom, rather than relying on a single summary number.
If the channel has multiple pipelines, inspect each one rather than assuming that one pipeline’s graph represents the other. A difference between pipelines can narrow the investigation, but it still does not prove the underlying cause. Note which pipeline is associated with the output under review and preserve the time range while you inspect YouTube’s health view.
This is also a useful moment to record what changed: a new input, a modified output, a scheduled restart, or a change to the stream destination. A change close to the incident is a lead to test, not proof. Avoid changing several settings at once, since doing so makes it harder to tell which observation changed.
Check codec, resolution, and frame rate
Read the output configuration that was active during the incident, not only the intended configuration. Confirm the codec, resolution, and frame rate of the MediaLive output that is sent to YouTube. YouTube’s encoder settings guidance lists H.264, H.265/HEVC, and AV1 for RTMP/RTMPS encoder settings and organises bitrate guidance by format. Use the row that matches the actual output, rather than a remembered setting from another stream.
Frame rate and resolution belong together in this check. YouTube’s general RTMP/RTMPS guidance supports up to 60 fps, but that does not mean every channel should use the highest available rate. Compare the configured output against the stream you intend to send and the corresponding guidance row. If you are sending 1080p30, for example, use the 1080p30 entry, not the 1080p60 entry.
Also check whether the input and output formats differ. An output can be intentionally resized or re-encoded, but an unexpected profile or format change can make the configuration review misleading. Record the actual output values alongside YouTube’s health messages. Neither a format warning nor a nonzero MediaLive metric, on its own, tells you that format conversion caused the dropped frames.
For a channel that loops a prepared programme, keep a copy of the known-good output settings with the file and schedule notes. The Tamil children’s video playlist cloud-streaming example is relevant to that kind of continuous prerecorded channel, though its specific format needs may differ from yours.
Review bitrate and CBR rate control
YouTube recommends constant bitrate, or CBR, for encoder output. In MediaLive, CBR aims to match the specified bitrate. Variable bitrate (VBR) targets an average and permits short increases up to a maximum; quality-defined variable bitrate (QVBR) varies the rate to target quality within a maximum. Those modes behave differently, so check what is selected rather than assuming that the configured target describes every moment of the output.
The right bitrate depends on codec, resolution, and frame rate. YouTube’s currently available Help table, accessed on 3 October 2026, lists H.264 at 1080p30 with a recommended bitrate of 14 Mbps and minimum of 5 Mbps; for 1080p60 H.264 it lists 17 Mbps recommended and 6 Mbps minimum. These are YouTube guidance values, not universal prescriptions. Check the current row for your exact format and verify the date of the guidance when you use it.
If YouTube reports a bitrate issue, compare the intended rate, selected rate-control mode, and applicable table row before making a change. Then observe the stream health again. A mismatch is worth correcting, but it does not prove that the mismatch caused MediaLive to drop input frames. Conversely, a nonzero DroppedFrames value is not a reason by itself to raise or lower the bitrate.
For a continuous channel, keep changes controlled: alter one relevant setting, note the time, and compare the same evidence afterwards. If you change the codec, output size, frame rate, and rate control together, a later improvement or deterioration will be difficult to attribute. Retain the previous values so you can restore them if the new configuration creates a different problem.
Check keyframe interval and transport protocol
YouTube recommends a keyframe frequency of two seconds and says not to exceed four seconds. In MediaLive, inspect the GOP size and its units. A numeric frame count does not express a fixed duration unless you interpret it against the configured frame rate: a GOP specified in frames represents a different span of time at different frame rates. Check the resulting duration, not just the number shown in a field.
AWS’s MediaLive guidance also recommends closed GOP cadence 1 for streaming and warns that a cadence of 0 breaks output segmenting. Review the relevant MediaLive channel configuration documentation for the setting names and permitted configuration. Treat the recommendation as a configuration check, not as a diagnosis of a particular incident.
Confirm the ingest protocol at both ends. YouTube recommends RTMPS; its developer guide to RTMPS ingestion describes it as RTMP tunneled through SSL. Verify that the configured destination expects the protocol you have selected. A protocol mismatch can prevent a connection from working as intended, but the protocol setting alone does not establish why a DroppedFrames value appeared.
If you are reviewing an existing stream key or moving a destination, follow a deliberate process rather than pasting credentials into an unverified place. The stream-key transfer checklist is useful for that separate operational step. Keep the key private while you confirm the destination and protocol.
Compare with YouTube stream health
Open YouTube Live Control Room and inspect stream health over the same incident interval as the CloudWatch graph. Note the exact message and when it appeared. YouTube’s Live Streaming API health-status documentation describes configuration issues involving bitrate, frame rate, codecs, keyframe frequency, and consistency between primary and backup streams. Its “Video output low” issue means YouTube is not receiving enough video to maintain smooth streaming.
That wording is an observation from the ingest side. It is not a definition of AWS’s DroppedFrames metric, and it does not reveal whether MediaLive dropped input frames. Likewise, a nonzero MediaLive value does not tell you what YouTube’s health panel will show. Keep the two records separate in your notes: one for encoder processing, one for YouTube’s reception and configuration checks.
A practical comparison might look like this:
| Evidence | What it describes | What to check next |
|---|---|---|
MediaLive DroppedFrames rises in the active pipeline’s Sum graph |
Input frames dropped because the encoder could not keep up in that metric period | Confirm the channel state, pipeline, and incident timing; inspect output settings and related metrics |
| YouTube reports “Video output low” | YouTube is not receiving enough video to maintain smooth streaming | Check the message timing and review output format, bitrate, and the outgoing path |
| YouTube flags bitrate, frame rate, codec, or keyframe configuration | YouTube has identified a relevant ingest/configuration issue | Compare the message with the actual configured output and current YouTube guidance |
DroppedFrames has no datapoint |
No metric value is available for that period | Confirm whether the channel was producing output; do not treat absence as zero |
A table entry is a prompt for the next check, not a verdict. If YouTube reports a configuration issue while the MediaLive metric remains zero, investigate both observations without forcing them into one explanation. If the metric rises while YouTube reports no health issue, the encoder-side signal still merits review, but the absence of a YouTube warning does not settle the cause.
Use both signals before diagnosing cause
Build a short incident record with the same time range for each source: channel state, pipeline, DroppedFrames as Sum, relevant output metrics such as NetworkOut, active encode settings, and YouTube health messages. AWS’s output metrics reference defines the MediaLive measures; use it to avoid treating an output or network metric as though it meant the same thing as input frames dropped by the encoder.
Then compare the observations rather than choosing one as the answer. A rise in DroppedFrames indicates encoder processing evidence. A YouTube health message indicates what YouTube has observed about incoming video or configuration. A network metric can add context about the outgoing path. The sources do not establish a specific channel’s root cause without its timestamps, configuration, and actual metric history.
If you need to test a change, make one measured change at a time and retain the prior configuration. Observe whether the metric and YouTube health change over comparable periods, and record the result. If the signals remain unclear, escalate with the incident window, pipeline, settings, and screenshots or exports rather than stating a cause that the available evidence cannot support.
If the operational problem is not the encoder configuration but keeping a prerecorded channel running when your own computer is off, StreamNeo can remove that particular manual-running burden by turning an uploaded file into a YouTube live stream that is monitored and restarted if it drops; it does not replace checking the MediaLive and YouTube evidence for this issue.
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 nonzero DroppedFrames prove that YouTube is dropping frames?
No. AWS defines it as input frames dropped when MediaLive cannot process them fast enough to keep up with real time. YouTube stream health is a separate ingest-side observation, so compare both over the same time window before drawing a conclusion.
Does a missing CloudWatch datapoint mean the stream was healthy?
No. AWS says a missing point can mean the channel is stopped, initializing, waiting for initial input, paused, or not producing output. Confirm channel state and whether output was expected before interpreting the graph.
What keyframe interval should I check?
YouTube recommends a two-second keyframe frequency and says not to exceed four seconds. In MediaLive, inspect GOP size and units, then calculate the duration at the configured frame rate rather than relying on the frame count alone.
Should I change bitrate when YouTube flags stream health?
First compare the actual codec, resolution, and frame rate with YouTube’s current bitrate table and review the selected rate-control mode. A warning can guide the check, but neither it nor DroppedFrames alone proves that bitrate is the cause.