FFmpeg’s live status and progress output can show whether the local process is advancing at the expected rate and whether it reports duplicate or dropped frames. That evidence describes FFmpeg’s work; it does not, on its own, prove what YouTube received or what viewers saw.
Before changing encoder settings, save the command, the relevant FFmpeg output and the YouTube-side stream status for the same period. Comparing those separate observations is more useful than treating one counter as a diagnosis.
What “dropped frames” can mean
The phrase can describe different things. FFmpeg may report that it dropped frames while converting a video to a requested output rate. The local process may also fall behind its intended pace, or timestamps may progress irregularly. Separately, YouTube may report an issue with the stream it is receiving. Those observations concern different stages and are not interchangeable.
Start by asking where the evidence comes from. A drop counter in FFmpeg’s status line is evidence about the local process or output path, depending on the FFmpeg version and command. A warning in its log is another local observation. YouTube’s stream-health information is evidence from the receiving side. Viewer playback is a further observation, and can differ by device, connection and playback conditions.
This distinction matters when a local counter changes but the broadcast appears normal, or when FFmpeg’s status looks steady while YouTube reports a problem. Neither situation identifies a cause by itself. Record what each system says, including the time, before drawing conclusions.
Also check what “expected rate” means in your case. A source file, a capture device and an output stream can have different frame-rate assumptions. A file may use variable timing; a command can convert it to a constant output rate. If the output is being stream-copied rather than encoded, some options have different effects. The command and its option placement are part of the evidence.
If you are reviewing a long-running channel rather than a single event, keep a copy of the working command and note the source file and intended output. The same principle applies to a 24/7 birdsong stream setup: knowing what is meant to be sent makes later comparisons possible.
Read FFmpeg’s live progress and frame-rate output
FFmpeg’s -stats output is enabled by default in documented builds. It periodically prints a human-readable status line. Fields commonly include the number of frames processed, output time, speed and reported frame rate; some versions or configurations may show dup and drop counters. The documented default status interval is 0.5 seconds, but you can check the documentation for the version you have installed because FFmpeg’s behaviour and output can vary.
Do not assume every field is present or means exactly the same thing in every setup. Record a few status lines rather than relying on a single snapshot. A growing frame count indicates that FFmpeg is processing output; the reported fps and speed are clues about local processing pace. Compare the output time and frame count over an interval with the stream’s intended rate, while remembering that brief changes can occur and that the display is not a measurement of YouTube delivery.
The dup and drop labels, when present, are particularly easy to overread. They may relate to frame-rate conversion performed by FFmpeg, not a report of frames lost in transit to YouTube. Inspect the command before deciding what the counters suggest. The FFmpeg project documents its statistics and progress options in the FFmpeg command-line documentation.
For machine-readable updates, FFmpeg offers the global option -progress, which writes periodic key-value records to a chosen URL. A simple pattern to adapt to an existing command is:
ffmpeg -stats_period 1 -progress pipe:1 -i INPUT [existing options] OUTPUT
This is an illustration, not a complete streaming command. Keep your current input, encoding or copy choices, muxer and output options intact. -stats_period controls the update interval for progress information. With pipe:1, records go to standard output; each update ends with progress=continue, and the final one with progress=end. Check the FFmpeg documentation for -progress and -stats_period if the installed version behaves differently.
If a script reads standard output, keep other messages from being mixed into that data. Capture standard error separately so human-readable warnings remain available. A progress parser should preserve the timestamps and complete update blocks, not just extract a frame value and discard the surrounding context. A changing count without the associated output time, speed and log messages is hard to interpret later.
Check timestamps and warnings for irregularities
If progress counters and playback observations disagree, inspect timing rather than changing settings immediately. Look for output time that stops advancing, repeated or unexpected timestamp values, large jumps, warnings and errors. Note whether an irregularity appears once or continues across several updates. A warning is a clue to investigate, not an automatic explanation of what a viewer experienced.
FFmpeg has a -debug_ts option for timestamp and latency debugging. Its documentation warns that the output may change, so it should not be treated as a stable interface for portable scripts. Use it as a temporary diagnostic aid, save the command and output, and avoid building a long-term parser around its exact wording.
The showinfo filter can log basic frame information for debugging and development. It may help you inspect frame timing when you have a way to include the filter in the relevant processing path. Be careful to preserve the original command and compare like with like: adding a filter can change the processing path you are trying to observe. Consult the FFmpeg filter and bitstream-filter documentation and the documentation for your installed version before relying on a particular field.
Timestamp inspection can establish that values appear irregular in a local log. It cannot, without further evidence, tell you whether the cause was a source file, a conversion choice, a processing delay or a receiving-side issue. Keep your notes descriptive: “output time paused while frame count advanced” is more useful than “YouTube dropped frames” if the receiving evidence has not been checked.
Save evidence from the running process
Collect evidence while the stream is running, before you restart or alter the command. Save the exact FFmpeg command with sensitive values removed, the FFmpeg version, the progress or status output, and relevant standard-error warnings. Never include a live stream key in a shared log or screenshot. If you need to redact a command, mark where a value was removed so the remaining option order is still clear.
Record the time and timezone for each capture, and note what the stream was doing: for example, whether it was looping a local file, changing sources or running a filter. If an issue is intermittent, preserve a window before, during and after it rather than one isolated status line. Keep output time, frame count, speed and any dup or drop fields together. For timestamp debugging, keep the original unfiltered log as well as any extra debug output.
The version is important because status fields and debug output can differ. Run ffmpeg -version in the same environment as the live process, not on another computer where a different build may be installed. If you use a script or a service wrapper, capture the command it actually launches; the command you remember typing may not be the one currently running.
A compact incident note might include: the start and end time of the observation; the source and intended output rate; the relevant command options; the FFmpeg version; the status fields and warnings; and what YouTube reported at the same time. Add a description of viewer playback only if you observed it directly, and identify the device or player if that context matters. Avoid converting a viewer report into a technical finding without corroboration.
If you operate a broader 24/7 workflow, keep operational notes alongside the stream configuration. A guide to avoiding common streaming mistakes is useful context, but for this specific fault keep the evidence tied to the same incident and timespan.
Compare with YouTube Live stream health
Check YouTube’s own live-stream status separately while the event is active, and note the exact message or indicators shown in the current interface. YouTube’s interface and terminology can change; do not assume a remembered label is still present. The official YouTube encoder settings help page and help for creating a live stream are suitable starting points for current platform guidance.
Make the comparison time-aligned. If FFmpeg’s rate changes around a time that YouTube also reports a receiving-side issue, that is useful evidence to investigate further, but it does not establish that one event caused the other. If the local process continues steadily while YouTube shows an issue, retain both observations and investigate the path between the local output and the receiving service. If YouTube’s status appears normal but a viewer reports a playback problem, treat that as a separate observation rather than proof that the local output was perfect.
Do not infer from a clean FFmpeg status that YouTube received every frame. FFmpeg reports what its process is doing; only the receiving-side evidence can describe YouTube’s own view of the incoming stream, and even that does not establish what every viewer’s player rendered. Nor does a YouTube-side warning by itself reveal which upstream stage caused it.
The guide to adding a YouTube radio stream key to OBS discusses a different encoder workflow, but its key-handling lesson applies when collecting FFmpeg evidence too: keep credentials out of logs you plan to share. A stream key is not diagnostic evidence and should be redacted.
Separate local encoding issues from ingest issues
Use the evidence to distinguish stages, not to name a cause prematurely. Local processing evidence includes FFmpeg’s progress records, counters, timestamps and warnings. Receiving-side evidence comes from YouTube’s current stream status. Network or transfer problems may sit between those observations; the two endpoints alone may not show exactly where a disruption occurred. Viewer playback is downstream again and can be affected by conditions not visible in either log.
First establish whether FFmpeg is encoding or copying the video stream. FFmpeg documents that an output -r used during video encoding can duplicate or drop frames to reach a requested constant rate. An input -r instead tells FFmpeg to ignore stored timestamps and assume a constant input rate; it is not the same as -framerate, which is used for certain inputs such as image sequences and capture devices. During stream copy, output -r changes the rate declared to the muxer and does not drop or duplicate the data. See the FFmpeg project’s documentation on frame-rate options, then check the positions of the options in your own command.
This is why a drop counter needs context. If output -r is present during encoding, some frame conversion may be expected as part of producing the selected rate. If the video is being copied, interpreting the same option as an encoder’s frame dropping would be wrong. If the command has neither, the counter still deserves inspection, but it does not identify an end-to-end failure. Read the command, output and timestamps together.
A local computer that is short of processing capacity is one possibility when local progress falls behind, but the output alone may not establish that as the cause. Similarly, if local progress looks steady and YouTube reports an issue, investigate the sending and receiving path rather than assuming the encoder is blameless or at fault. The evidence narrows the next question; it does not replace it.
Choose the next diagnostic test
Choose a test that separates the remaining possibilities while changing as little as possible. If you have only a screenshot, capture a longer run of status output and the exact command. If you already have local progress, timestamp and warning records but not a YouTube-side observation, check the live stream status during the next occurrence. If the receiving status is available, align the times and see whether the local evidence changes at the same point.
If rate conversion is a plausible factor, inspect the input and output rate options and determine whether the command encodes or stream-copies. Do not remove an option or alter the target rate merely to see whether a counter disappears: that can change the output and obscure what the original run was doing. First save the current command and evidence. Then make one deliberate change, record it, and compare the same kinds of observations.
If timestamps look irregular, use a targeted debug capture or a suitable logging filter and retain the unmodified baseline. Because -debug_ts output is not promised to be stable across versions, record the installed FFmpeg version with it. If the symptoms do not recur, do not treat a clean later run as proof that the earlier incident was resolved; note that the condition was not reproduced.
A useful comparison is:
| Observation | What it can help you check | What it cannot establish alone |
|---|---|---|
| FFmpeg frame count, rate, speed and output time | Whether the local process is advancing as expected over the captured interval | What YouTube received or what viewers saw |
dup or drop fields |
Whether FFmpeg reports local frame duplication or dropping in this command and version | Whether a receiving-side or viewer playback problem occurred |
Timestamp debug output or showinfo |
Whether local timing values appear irregular in the inspected path | The cause of an irregularity or its effect at YouTube |
| YouTube’s current stream status | What the receiving service reports for the live stream at that time | Which upstream stage caused a reported issue, or every viewer’s playback |
| A viewer’s playback report | Whether a particular viewer observed a problem | Whether the encoder or ingest path was at fault for all viewers |
For a channel that cannot depend on one local computer staying available, you may also need to decide whether local operation remains appropriate. StreamNeo can remove the need to leave that computer running for a file-based continuous YouTube broadcast; it does not make FFmpeg’s local logs evidence of what YouTube received, so keep the receiving-side checks in your process. If you are comparing operating approaches, a discussion of cloud and self-managed 24/7 streaming can help frame that separate decision.
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
How do I see dropped frames in FFmpeg?
Watch the live -stats status output for drop and dup fields, if your build and command show them. For a record that is easier to parse, use -progress pipe:1 and preserve the standard-error log separately. Interpret any counter in the context of your version and command, especially its frame-rate options.
Does FFmpeg drop frames when streaming?
It can report or perform frame duplication and dropping in particular processing circumstances, including output frame-rate conversion during encoding. Whether that is what your counter means depends on the command, option placement and whether you are encoding or stream-copying. A counter does not by itself show that YouTube lost frames.
How can I tell if YouTube is receiving all frames?
FFmpeg’s output cannot answer that on its own. Check YouTube’s live-stream status separately and compare its contemporaneous evidence with your local progress and logs. Neither a clean local counter nor a viewer’s report alone proves what every viewer received.
Should I change encoder settings when I see a drop counter?
Not before saving the command and relevant logs. Check whether the counter is associated with intended rate conversion, inspect timestamps and compare the same time period with YouTube’s status. Change one setting only after the evidence points to a specific test, then capture the result for comparison.