FFmpeg logs can help you investigate a YouTube RTMP stream that stalls or drops frames, but they do not provide a packet-loss count. To diagnose the cause, line up FFmpeg’s messages with YouTube’s stream-health status, your encoder and local recording, and network measurements taken during the same event.
A timeout, an SSL error, a low output rate or a viewer’s buffering report may be useful evidence of a problem, but none identifies packet loss on its own. Start by deciding what each observation can establish, then collect evidence at the point where the problem occurs.
What packet-loss evidence would mean
Packet loss means that packets sent over a network path did not arrive at the receiving end as expected. To support that diagnosis, you need a measurement that actually observes loss, such as relevant host network counters or a packet capture, and you need to know where and when that measurement was made. Even then, evidence from one point does not automatically identify the precise segment responsible.
FFmpeg operates at the application level when publishing a stream. Its logs can show what FFmpeg was doing and when it reported a warning or failed operation. Its progress output, including the familiar frame, fps, bitrate, total_size, out_time and speed fields, describes processing progress. It is not an IP packet counter and does not say how many packets disappeared between your encoder and YouTube.
The distinction matters because similar symptoms have different causes. An encoder that cannot keep up may produce a slow or irregular output. A source file may already contain a bad section. A connection may stall, be refused, or fail during setup. YouTube may report an ingestion problem. A viewer’s buffering can also occur after YouTube has accepted the stream. These observations narrow the investigation, but they do not locate packet loss by themselves.
Treat “RTMP packet loss” as a question to test, not a conclusion to copy from a log search or an error message. If all you have is a low rate in FFmpeg progress, describe it as low output or slow processing until another measurement supports a more specific diagnosis.
Enable useful FFmpeg diagnostic output
FFmpeg writes its normal log output to standard error. During a controlled reproduction, preserve that output in a file and temporarily raise the log level. The FFmpeg logging documentation describes -loglevel verbose and -loglevel debug, as well as prefixes that can include a level and time. Use verbose first; if it does not show enough context, a short debug capture may help.
For example, this pattern saves time-prefixed output to a local file:
ffmpeg -loglevel repeat+level+time+verbose -i INPUT \
-c:v libx264 -c:a aac -f flv 'rtmps://SERVER/APP/STREAM_KEY' 2>ffmpeg-live.log
Replace the input and output placeholders with your actual values locally. The encoding options are illustrative, not a universal recommendation for every source. Keep global options in the intended position before the input or output they affect; FFmpeg options can be sensitive to placement and scope.
FFmpeg also documents -report, which writes the command line and log output to a timestamped report and implies debug verbosity. It can be convenient when you need to preserve a reproduction without manually redirecting stderr. But a report may contain command-line details, including credentials. Never publish or send a live YouTube stream key in a log, screenshot or support bundle. Redact it before sharing, and consider whether a report is appropriate for a long event with substantial log volume.
The -stats progress line is enabled by default and reports encoding progress at info level. Leave it in place if the progression is useful, but do not interpret it as a packet-loss measurement. For a practical comparison of the roles of FFmpeg and OBS in scheduled streams, see OBS and FFmpeg for YouTube playlists; here, the important point is that whichever encoder you use, progress output is only one view of the publishing pipeline.
Record timestamps for relevant events
A log is more useful when it can be compared with other observations. Record the time of the first visible change in YouTube Live Control Room, the first relevant FFmpeg warning or error, any apparent stall, changes in encoder load, and any defect in a local recording. Keep the clocks and time zone consistent where possible. If you cannot synchronise the tools, note the offset rather than assuming that nearby entries happened at exactly the same moment.
Do not build the timeline from isolated search results alone. Include several minutes before and after the symptom if your log volume and privacy controls permit it. The lead-up can show whether the encoder was already falling behind; the recovery can show whether output resumed, the process exited, or a retry occurred. A single message copied out of context is easy to misread.
Compare the stream’s ordinary output pattern with the period in question. A slow speed value can mean FFmpeg is processing more slowly than real time, but it does not reveal why. A rising delay or interrupted writes may be consistent with a connection problem, but the precise log text varies with FFmpeg build, protocol implementation and failure mode. Check whether encoding load, source quality or other local work changed at the same time.
Use a small incident record that another person can follow:
| Time or window | Observation | Source | What it supports |
|---|---|---|---|
| Before the symptom | Normal or unusual progress, load or source behaviour | FFmpeg, encoder, local preview | Whether a local issue may have started first |
| First change | Health message, warning, stall or visible defect | YouTube, FFmpeg, archive | When the problem became observable at each point |
| During the symptom | Repeated errors, output behaviour, network counters | Logs and system tools | Evidence to compare across observation points |
| After recovery | Normal output, continued errors or process restart | Same sources | Whether the condition cleared or persisted |
This is a working record, not a diagnosis by itself. For a stream built around a repeatable file, keep the source and the local output available for comparison; the practical advice on keeping narration and cartoon audio consistent in a loop is a reminder that defects heard or seen in the local output may originate before the network is involved.
Compare logs with YouTube stream health
Open Live Control Room and note its stream-health status and any specific error or instruction. YouTube’s stream-health guidance treats the dashboard as a place to inspect incoming stream status. It is a separate observation from the FFmpeg process: it can tell you what YouTube reports about the stream it receives, but it does not identify a particular local network segment as the cause.
Compare the health timeline with the FFmpeg timeline. If YouTube reports a problem at the same time FFmpeg shows a stalled write, that strengthens the case that publishing or ingestion was affected during that window. It still does not prove packet loss. If the dashboard reports trouble while FFmpeg continues to encode at its usual pace, the distinction between local encoding progress and successful delivery is especially important.
Check the encoder’s direct preview and, if available, a local archive. YouTube’s troubleshooting guidance for live streams recommends checking the encoder output, encoder errors, CPU load, source quality and local recording, then testing the outbound connection if those local checks look healthy. Use that order to separate a source or encoding fault from a delivery problem.
For example, if a local archive has the same frozen picture and audio gap as the live stream, investigate the source, capture or encoding path before blaming the route to YouTube. If the archive is clean while the Live Control Room reports a problem, the outbound connection or delivery path deserves closer attention. That prioritisation is a next step, not proof that the ISP or any other specific party lost packets.
A useful companion if the symptom is a stream that keeps stopping rather than a measured loss event is how to keep a YouTube playlist running after an OBS crash. Recovery and diagnosis are related, but restarting a process does not explain what caused the interruption.
Check local and network evidence separately
First check that the computer can produce the intended stream consistently. Inspect encoder errors and CPU load during the event, view the direct encoder output, and compare the local recording with the live version. Check whether another local task started at the same time, or whether the source itself has a repeated defect. If a local problem coincides with the stream symptom, correct that before using network evidence to explain it.
Next check whether the available upload capacity has room for the stream. YouTube’s streaming tips say the total streaming bitrate should not exceed available upload bandwidth and recommend allowing 20% headroom. Count primary and backup outputs in the total, and remember that upload capacity can be lower than download capacity. This is YouTube’s operational guidance, not a guarantee that a connection will avoid congestion or loss.
Test outbound speed under conditions representative of the event, and compare the result with the aggregate bitrate you are sending. A brief speed test is a snapshot, not a record of every moment of a long broadcast. If you can safely make a controlled comparison, try wired Ethernet in place of Wi-Fi while keeping the stream settings and other conditions as similar as possible. If the symptom changes, that is evidence worth investigating about the local path; it does not by itself prove that Wi-Fi was losing packets.
If direct network evidence is needed, collect operating-system interface and TCP counters or arrange a packet capture during a reproduction. Record the host, interface, measurement window and tool used. These measurements have boundaries: host counters describe what that host or interface observed, and a capture only reflects traffic visible at its capture point. Neither automatically identifies what happened elsewhere along the route.
RTMP is carried over TCP/IP in FFmpeg’s protocol description, so an application log is not the same thing as observing individual IP packets. Avoid conclusions such as “the ISP dropped packets” unless evidence actually distinguishes that segment from the local network, the route beyond it, and the receiving side. If diagnosing a channel is already enough work, practical planning guides such as running a low-cost YouTube loop on a VPS in India can help you think about where a publishing workload runs, but moving it does not replace measuring the path that is failing.
Interpret timeouts, SSL errors and low rates cautiously
A message such as “connection timed out” tells you that an operation did not complete within the expected time. It does not count lost packets. The cause could involve an unreachable or incorrect destination, a blocked port, a temporary connection problem, or another condition that prevented setup or communication from completing. Check the destination URL and protocol, and compare the event with YouTube’s own status and local network evidence.
An invalid SSL certificate message is also not a packet-loss reading. YouTube’s encoder settings and RTMPS guidance advises checking that the URL is actually RTMPS and that the encoder supports it. Verify the URL and the encoder’s configuration against the current official instructions. Do not treat changing encryption settings as a general packet-loss fix, and do not expose a stream key while sharing the error context.
A low bitrate in progress output deserves similar care. It may reflect how quickly FFmpeg is producing output, a source with a lower instantaneous rate, encoder performance, or a wait in the output path. Look at the surrounding messages and compare against CPU load, the local preview or archive, YouTube health, and the configured output. A number that falls below your target is a reason to investigate, not a diagnosis of loss.
Keep separate notes for symptom, evidence and hypothesis. “Dashboard reported a connection problem at 02:15; FFmpeg logged a write error at about the same time; local archive is intact” is an evidence-based summary. “The ISP lost packets” is a stronger claim that needs measurements capable of supporting it. This distinction makes a support request more useful and reduces the risk of changing a healthy part of the setup.
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 -stats show RTMP packet loss?
No. It reports FFmpeg processing progress, not a count of IP packets lost or the network location of a loss. Use it as timing context, then compare it with YouTube health and measurements from the relevant host or path.
Does a connection timeout prove that packets were lost?
No. It shows that an operation did not complete in time, but it does not establish why. Check the destination and protocol, local output, YouTube status and network evidence from the same window before drawing a conclusion.
What should I do if YouTube reports a problem but my local recording is clean?
Note the exact health message and time, then compare it with FFmpeg’s log and encoder load. A clean archive makes a source or local encoding defect less likely, so test outbound capacity and collect host-level evidence during a reproduction. It does not by itself establish that your ISP is responsible.
Should I use verbose or debug logs for an overnight stream?
Start with a short, controlled capture at verbose level and raise it to debug only if more context is needed. Debug output can be large, and reports preserve command-line details, so protect credentials and redact the stream key before sharing any file.