“FFmpeg dropped frames streaming to YouTube: what to check” is not answered by changing one network setting. A drop counter can describe frame synchronisation inside FFmpeg, encoding falling behind, or a delivery problem between your encoder and YouTube.
Start with the complete FFmpeg log and the command that produced it. Then compare the encoder’s local output with YouTube’s stream health, so you know whether the fault appears before upload, during upload, or at ingestion.
What “dropped frames” can mean
A live stream has several stages: the source provides frames, FFmpeg assigns and checks timestamps, the video is encoded, the encoded data is sent out, and YouTube receives and processes it. A frame-related warning or counter may belong to any one of these stages, but the stages do not have the same remedy.
FFmpeg can duplicate or drop frames when it is trying to produce a constant frame rate. Its frame-synchronisation mode, input timestamps, output frame-rate setting and the timing of the source all affect that behaviour. In that situation, the drop value is describing FFmpeg’s handling of frames before or around encoding. It is not a direct reading of your broadband connection.
A separate problem occurs when the encoder cannot process the requested work quickly enough. You may see a speed value below real time, a falling processing rate, high CPU use, encoder warnings or a local recording with damaged motion or sound. That is an encoding or machine-load problem even if the internet connection is stable.
A delivery problem appears later. The local encoded output may look and sound correct, while YouTube reports an unstable stream, missing data or a changing stream-health warning. In that case, examine upload capacity, competing traffic, the route to YouTube and the ingest configuration.
This distinction matters for a 24/7 devotional channel, a local news loop or a study stream. Replacing the router will not repair bad timestamps. Changing -r will not create upload capacity. Increasing the bitrate can make a marginal connection less reliable. Identify the stage before changing settings.
If you are starting from a file rather than a live camera or screen source, the guide to setting up FFmpeg with a YouTube stream key for a video loop gives useful background. For this problem, however, keep the existing command intact until you have captured evidence from it.
Read the full FFmpeg log first
Do not diagnose the stream from a single progress line copied from a terminal. Save the full log from a short, representative test and record the exact command, input file, FFmpeg version, output settings and time at which the warning appeared.
The progress line is still useful. Note these values at intervals rather than only at the end:
| Value | What it can tell you | What it cannot prove on its own |
|---|---|---|
fps |
How quickly FFmpeg is processing frames | That YouTube is receiving them correctly |
speed |
Whether processing is keeping up with source time | That upload capacity is sufficient |
dup |
Frames FFmpeg has duplicated | That the source file is damaged |
drop |
Frames FFmpeg has discarded in its current processing path | That the internet connection is bad |
bitrate |
The approximate output rate at that point | That the rate is stable over a long stream |
| warnings | Timestamp, input, encoder or output symptoms | Which component is responsible without context |
Look above and below the progress line for messages about non-monotonic timestamps, invalid or missing timestamps, input duration, pixel format, audio resampling, encoder failure, connection resets and output errors. A timestamp warning near a rising drop count points you towards the source or synchronisation path. A connection error after the local output remains healthy points elsewhere.
The FFmpeg documentation explains that output -r can duplicate or drop frames to reach a constant rate. It also documents -fps_mode, including modes that preserve timestamps, use variable frame rate, or duplicate and drop to maintain a constant frame rate. These are descriptions of FFmpeg’s behaviour, not a universal instruction to add or remove one option.
Check the installed version before relying on an example from an old command. Options can change in meaning, availability or preferred use. Copying a command from a forum without comparing its input, output and FFmpeg version can replace one unknown with several.
Also check whether the counter belongs to FFmpeg at all. YouTube’s Live Control Room may show its own health messages, while a streaming application may display a separate dropped-frame metric. Give each counter a label in your notes. “FFmpeg drop” and “YouTube stream-health warning” are evidence from different points in the pipeline.
Check frame synchronisation and output rate
Next, compare the source’s actual frame rate and timestamps with the output settings. A file described as 25 fps, a file with variable timing, and a live capture device do not present frames in exactly the same way. The command may be asking FFmpeg for 30 or 60 output frames per second even though the source does not naturally provide that cadence.
Read the command from left to right. Identify the input, any input-side -r, filters that alter timing, the video encoder, the output-side -r, and any -fps_mode setting. Do not assume that an option placed before the input has the same effect as one placed on the output. FFmpeg options are often scoped by where they appear in the command.
An output -r can make FFmpeg duplicate or discard frames to reach the requested constant rate. That may be the intended result for a platform delivery format, but it can also expose a mismatch between the source and the command. A variable-frame-rate mode may avoid some unnecessary duplication, while a constant-frame-rate mode may be needed for a particular delivery workflow. The correct choice depends on the source and the desired output, so inspect first rather than treating one mode as a cure.
Pay attention to input pacing. FFmpeg documents -re as reading input at its native frame rate, mainly for simulating a live source when reading from a file. That can be appropriate when a prerecorded file must be sent in real time. It is not a setting to add blindly to every command. FFmpeg warns that applying a low read rate to an actual capture device or other live input can cause packet loss.
For a file loop, test one complete pass or a sufficiently long section with the same pacing that you intend to use overnight. For a camera or capture device, test without imposing file-style pacing. If the drop count appears only with one input type, that comparison is more useful than changing several options at once.
Check audio timing at the same time. A stream can have apparently stable video while audio drifts, is repeatedly resampled or triggers timestamp corrections. If the problem is mainly sound arriving early or late, use the investigation in Audio Out of Sync on Long Streams: Causes and Permanent Fixes rather than assuming every timing message is a network fault.
Keep a small test matrix: the original command, one change to frame-rate handling, and one change to pacing if the input is a file. Record the resulting fps, speed, dup, drop and local recording quality. If the symptoms move when only synchronisation changes, you have strong evidence that the first problem was in the timing path.
Check encoding load and process health
Once input timing is understood, establish whether FFmpeg can encode the stream in real time. A process that slowly falls behind can produce a stream that starts well and deteriorates after hours. This is particularly easy to miss with a long video loop, because a short test may finish before the machine reaches its sustained thermal or CPU limit.
Watch speed over time. A value near real time is not a guarantee of a healthy broadcast, but a persistent value below real time is a clear reason to investigate processing capacity. Also watch CPU load, memory pressure, hardware-encoder messages, temperature if available, and whether the FFmpeg process is still running. If audio and video are both being decoded, filtered and re-encoded, identify which step consumes the work.
Make a local recording during the test. YouTube’s troubleshooting guidance tells creators to check encoder errors, CPU load, the local archive, and how the stream looks and sounds inside the encoder. If the local file has judder, frozen sections, broken sound or missing frames, focus on the source and encoding path before investigating the ISP.
Reduce one workload factor for a controlled comparison. For example, test a lower output resolution or frame rate, remove an unnecessary filter, or use a simpler source file. Do not change resolution, codec, bitrate and frame-rate mode together, because then you will not know which change mattered. If a lower workload restores real-time processing and improves the local recording, the machine or encoding configuration is involved.
Update FFmpeg and the relevant encoder software when the evidence points to an encoder fault. Keep a copy of the old command and note the version before updating. A new build can change defaults or hardware-encoder behaviour, so verify the same input and output after the update rather than assuming the result is equivalent.
A 24/7 stream also needs process supervision. Check whether the process exits, hangs, loses its input file at a loop boundary or continues running while producing no useful output. A restart policy may recover an interruption, but it cannot correct a command that consistently creates bad timestamps or exceeds available processing capacity.
If a personal computer is being left on overnight, compare the complete operating arrangement rather than only the CPU. The discussion of a cloud streaming service versus a VPS for a nonstop church stream is relevant when the practical problem is maintaining a long-running process, but the same diagnostic order still applies in either environment.
Compare encoder output with YouTube stream health
After the local encoder test is clean, look at YouTube. Use a test stream with similar motion, audio and duration to the real broadcast. A still image and a busy music video exercise different parts of the pipeline, so a test that is too easy can hide the fault you will see overnight.
Open the Live Control Room preview before starting the public event. Check the picture, sound and stream-health messages while FFmpeg is running. Keep timestamps in your notes: when FFmpeg’s counter changed, when YouTube reported a warning, and whether the local archive remained healthy.
YouTube recommends checking the encoder’s output first. If the video and audio look good in the encoder and the local archive is sound, an outbound internet issue becomes more plausible. If both the encoder output and YouTube preview are bad, return to source timing, filters or encoding load rather than treating the platform message as the first cause.
Verify the stream key and destination when the issue is failure to start or an unexpected destination. A correct key does not repair dropped frames, but a stale key or wrong event can make a healthy encoder appear to be failing at ingestion. Avoid changing the key during a live diagnosis unless you have recorded the current configuration and understand which event the command should reach.
YouTube’s encoder settings page recommends CBR and a keyframe interval of two seconds, with no more than four seconds between keyframes, and lists support for up to 60 fps in its RTMP and RTMPS settings. Treat these as configuration checks, not as a universal fix for a rising FFmpeg drop value.
For H.264, the same page currently lists recommended ingestion bitrates of 14 Mbps for 1080p30, 17 Mbps for 1080p60, 8 Mbps for 720p60 and 6 Mbps for 720p30. These are YouTube’s listed recommendations for those modes, not a promise that your connection will sustain them and not a reason to select the highest value automatically. Check the current official table before publishing or changing a production command.
A useful comparison is simple: if the local recording remains clean while YouTube’s health worsens, investigate delivery. If the local recording worsens at the same moment, investigate FFmpeg and the machine. If neither changes but viewers report buffering, examine YouTube’s health information and latency settings rather than relying on the FFmpeg counter alone.
Isolate network and ingestion issues
Measure stable upload performance during conditions that resemble the live broadcast. YouTube recommends running a speed test and choosing a quality that is reliable for the connection. A short, favourable test is not the same as sustaining a stream through the evening while other devices use the connection.
Compare the target video bitrate, audio bitrate and protocol overhead with the measured upload capacity. Leave practical headroom for variation and other traffic. That headroom is a troubleshooting judgement, not a universal numeric rule from YouTube. If the stream needs most of the available upload rate, a household backup, cloud sync or another video call can make delivery unstable.
Do not confuse a bitrate warning with FFmpeg’s frame-synchronisation counter. A connection may deliver the wrong amount of encoded data even when FFmpeg is processing frames at real time. Conversely, FFmpeg may discard frames before producing the data that is sent, while the connection remains capable of carrying the resulting bitrate.
Run one test with competing uploads paused and another under normal household conditions. If the clean test works but the normal test does not, the issue may be congestion on the local network or the access connection. If both fail while the local archive is healthy, record the time, bitrate and YouTube message before contacting the ISP or checking the route.
Review keyframe and rate-control settings against YouTube’s current documentation. CBR and a two-second keyframe interval are useful checks because they affect how the platform receives and processes the stream, but changing them will not create missing upload capacity. Make one change at a time and repeat the same test.
Latency is a separate trade-off. YouTube describes latency as the delay between capture and display. Lower latency reduces the player’s read-ahead buffer, which can make viewers more likely to encounter buffering when the network varies. Its lower-latency modes are intended for interaction and are not a general cure for FFmpeg drops; YouTube also notes that low-latency modes do not support 4K. Choose latency for the channel’s purpose, not as a repair for an unrelated counter.
If the broadcast is mainly a prerecorded loop, reducing unnecessary complexity can help the whole path. The guide to YouTube live-stream video encoding requirements for prerecorded content is useful when you are deciding whether the source file and output format are sensible before testing delivery.
A practical overnight diagnostic order
Use this order when the stream must survive a night rather than merely pass a five-minute trial.
- Save the exact FFmpeg command, version and complete log.
- Mark the time and source of every
drop, warning or YouTube health message. - Check the input frame rate, timestamps, output
-r,-fps_modeand whether-reis appropriate for this input. - Monitor
fps,speed,dup,drop, bitrate, CPU use and process state. - Make a local recording and inspect both busy and quiet parts of the content.
- Run a representative YouTube test with comparable motion and audio.
- Compare the local archive, encoder view, YouTube preview and stream-health messages.
- Measure upload capacity under normal conditions and pause competing traffic for comparison.
- Change one setting, repeat the test and keep the previous command available for rollback.
For a channel that must run while your computer is switched off, StreamNeo removes the need to keep a local FFmpeg process alive and watched through the night: upload the video once, provide the YouTube stream key, and the broadcast can be monitored and restarted automatically if it drops. You still need to check the source, YouTube settings and channel requirements, but the local machine and its overnight connection are no longer the part you have to maintain.
Do not use the absence of a visible warning as proof that the stream is perfect. Let the test run long enough to expose loop boundaries, thermal behaviour, changing household traffic and any source timestamp irregularities. Keep the log and local archive until you have confirmed that the symptoms are gone, not merely hidden by a restart.
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 FFmpeg’s drop counter prove that my internet is bad?
No. FFmpeg may drop or duplicate frames to meet an output frame rate, and the counter can be affected by timestamps and synchronisation settings. Check speed, CPU load, the full log, the local recording and YouTube’s stream health before blaming the connection.
Should I add -re to fix dropped frames?
Only when it fits the input. FFmpeg documents -re as mainly useful for reading a file at its native rate when simulating a live source, and warns that applying a low read rate to an actual capture or live input can cause packet loss. Identify the input type and current pacing first.
What should I check if the local recording looks fine but YouTube reports problems?
Compare the stream bitrate with stable upload performance, including other traffic on the connection. Check YouTube’s current encoder guidance, keyframe and rate-control settings, Live Control Room messages and the test stream preview. A clean local archive with poor YouTube health shifts attention towards outbound delivery or ingestion.
Should I lower the resolution immediately?
Not automatically. First establish whether the issue is frame synchronisation, encoding capacity or delivery. A controlled lower-resolution test can reveal an encoding bottleneck, but changing several settings at once will make the result difficult to interpret.