A Raspberry Pi FFmpeg stream disconnect is not fixed by adding one universal reconnect flag. First identify whether FFmpeg is pulling, publishing or relaying, then determine whether the input or output connection failed and whether FFmpeg exited or remained stuck.
The correct recovery depends on the protocol. HTTP input has its own reconnect controls, RTSP needs transport and session diagnosis, and network output may benefit from the FIFO muxer or an external process supervisor. Logs should decide which path you take.
Start by mapping the stream
Before changing the command, draw the path that FFmpeg is handling. A Raspberry Pi may be doing one of three different jobs:
- Pulling: FFmpeg reads a remote HTTP, RTSP or other feed and processes it locally.
- Publishing: FFmpeg reads a local file or camera and sends the encoded stream to YouTube or another destination.
- Relaying: FFmpeg reads one network endpoint and writes another network stream.
This distinction matters because “the stream disconnected” can describe two separate failures. If FFmpeg is relaying an RTSP camera to YouTube, the camera connection is the input and YouTube is the output. A reconnect setting intended for HTTP input will not repair an RTSP camera session, and a setting for a network output will not restart a process that has already terminated.
Write down every endpoint in order. For example:
camera RTSP input → FFmpeg decode/encode → YouTube RTMP output
Then mark which side failed. If the camera becomes unavailable but FFmpeg continues waiting for packets, investigate the input. If FFmpeg reports a broken pipe while writing to YouTube, investigate the output. If both ends are remote, collect evidence for each side rather than assuming the local Wi-Fi connection is the only cause.
Also record the exact command with stream keys and passwords removed, the output of ffmpeg -version, the Raspberry Pi model, the operating system, and the time of each interruption. Packaged FFmpeg builds can differ from the current project documentation, so the installed version is part of the diagnosis.
If your immediate problem is that the command disappears when you close an SSH session, that is a different failure from a network drop. The guide on keeping an FFmpeg YouTube stream running after SSH disconnects covers process lifetime and terminal sessions rather than protocol recovery.
Identify the protocol and failing connection
Look at the URL and the input and output sections of the command. Common examples include:
| Connection | What it usually means | First question |
|---|---|---|
http:// or https:// input |
FFmpeg is reading a web-delivered feed or file | Does the HTTP server close or reset the connection? |
rtsp:// input |
FFmpeg is reading a camera or RTSP server | Is the loss on UDP, TCP, the camera or the route? |
| Network output such as RTMP | FFmpeg is publishing a live stream | Does the destination reject the write or does the route disappear? |
| Local file or camera input with network output | Only the output is remote | Does the input continue while the output fails? |
The protocol is not just descriptive. It determines which options exist and where they apply. FFmpeg’s HTTP implementation documents HTTP-specific controls including reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error and reconnect_streamed. Those options belong to HTTP handling. They are not a general RTSP reconnect switch.
RTSP has a different model. FFmpeg’s protocol documentation describes UDP and TCP transport choices. With UDP, packets can be lost or arrive out of order. With TCP, RTSP media can be interleaved through the RTSP control connection. Trying TCP can therefore help identify a UDP-path problem, but it does not promise that every interrupted session will be re-established.
For an FFmpeg output, first determine whether the destination closed the connection, whether the network route vanished, or whether the output muxer stopped accepting data. A message such as Broken pipe, Connection reset by peer, or an I/O error points to the write side, but the surrounding lines are important. Do not copy an HTTP option into the output simply because the word “reconnect” appears in an example.
When the source is a Raspberry Pi camera, keep camera and network causes separate. A camera process can stop producing frames because of a camera-stack, power, workload or encoding problem while the network remains healthy. The Picamera2 manual describes the supported Raspberry Pi camera software environment and workload considerations. Check its current version and your Raspberry Pi OS release rather than assuming that every camera failure is a cable or Wi-Fi failure.
Establish whether FFmpeg exited or stalled
The next split is operational: did the FFmpeg process terminate, or is it still running but no longer making progress?
Run a process check from another session while the problem is happening. On a system using a typical Linux process list, look for the FFmpeg command and note its process state and start time. Check whether the terminal, service or container that launched it is still present. If you have logging configured, note whether new lines continue to appear.
An exited process normally leaves a final error and returns control to its parent shell or supervisor. No reconnect option inside FFmpeg can execute after the process has ended. Recovery then belongs outside FFmpeg: a service manager, watchdog or carefully written wrapper can start the command again. This is process supervision, not in-process protocol recovery, and it should be configured only after you understand why the process exited.
A stalled process is different. It may remain listed while receiving no frames, writing no packets or waiting for a network operation. In that case, restarting it immediately can hide the failure point. Check the last input and output timestamps, the frame or packet counters in the log, and whether CPU use has changed. A frozen counter with a live process suggests a blocked or stalled connection; a steadily increasing counter suggests that FFmpeg may still be working and the problem could be downstream.
Use a simple observation record for each incident:
| Observation | Likely direction | What to confirm |
|---|---|---|
| Process has vanished | Process-level failure | Exit code and final log lines |
| Process remains, input frame count stops | Input or decoder stall | Source availability and input timeout behaviour |
| Input continues, output errors appear | Output connection failure | Destination response and write errors |
| Both counters stop with no final error | Blocked operation or system issue | Process state, kernel messages and network tests |
| Process restarts repeatedly | Supervision loop or persistent endpoint fault | Restart timestamps and the first failure each time |
A restart loop is not a healthy recovery strategy. If the source is unavailable for hours, repeatedly launching FFmpeg can fill logs, consume resources and make it harder to see the original error. Use a bounded retry policy while diagnosing, and record each attempt.
Read the logs at the failure point
FFmpeg’s final line is not always the root cause. Save the complete output from several minutes before the interruption through the process exit or recovery. Include the command version and remove secrets before sharing it.
Use a log level that shows enough detail to identify the protocol event without making the file impossible to read. The useful evidence is usually near the first warning or error, not the repeated messages that follow. Look for phrases indicating a timeout, end of file, connection reset, broken pipe, HTTP response code, input format failure, decoder error or muxer failure.
Separate four moments in the log:
- Last successful activity. Note the last frame, packet, read or write that completed normally.
- First abnormal event. Find the earliest timeout, reset, short read, HTTP error or queue warning.
- Recovery attempt. Check whether FFmpeg says it is reconnecting, waiting, reopening or retrying.
- Final state. Determine whether it resumed, stopped producing data, or exited with a non-zero status.
This sequence prevents a common mistake: treating a later “failed to write” line as proof that the input failed. In a relay, an output outage can cause back-pressure that eventually affects input processing. The first event still gives you the better starting point.
Keep a separate network record. Note whether the Raspberry Pi lost its interface, received a new address, still resolved the hostname, and could reach the endpoint after the incident. If the endpoint is YouTube, also check the live control room and stream health. YouTube’s official live streaming troubleshooting guidance should be your reference for destination-side warnings and current requirements.
Do not treat a log message as proof of a network cause when the same command also uses a camera, hardware encoder or complex filter graph. A camera timeout and a TCP reset can look similar at a glance. Compare the first failing component with what was still active immediately beforehand.
Match recovery to the protocol
HTTP input
If FFmpeg reads an HTTP source, inspect the HTTP reconnect controls supported by your installed build. The source documentation lists options for reconnecting after network errors, reconnecting at end of file, responding to selected HTTP errors, and handling streamed content. They are disabled or configured according to the build’s defaults, so do not assume that an option is active because it exists in current source documentation.
Set a retry and delay policy deliberately. A short delay can recover quickly from a brief interruption but may create repeated requests against an unavailable source. A long delay reduces request churn but leaves the output without fresh input for longer. A maximum retry count can make persistent failure visible; unlimited retries can be appropriate for an unattended feed only when a separate monitor alerts you and the behaviour is documented.
Check the installed command’s help and protocol documentation before using an option. The current FFmpeg HTTP source lists implementation defaults such as a maximum reconnect delay, retry count and total delay, but these are version-sensitive details. Treat them as evidence for that source revision, not as universal values for every Raspberry Pi package.
RTSP input
For RTSP, begin with transport rather than a generic reconnect flag. Test the camera or server using the transport it supports, then compare UDP with TCP when the network path may be losing or reordering UDP packets. A command using -rtsp_transport tcp can be useful as a diagnostic, but it is not a guarantee that a dropped session will reconnect.
TCP may make the path easier to inspect and can avoid some UDP loss, but it can also change latency, firewall requirements and behaviour under congestion. UDP may be preferable where low latency matters and the network is controlled. The right result is the one that remains stable for your camera, route and workload, not the one that appears in a generic example.
If TCP testing changes the symptom from missing packets to a clean disconnect, read the session and timeout messages closely. If FFmpeg exits, add external supervision. If it remains alive but stops receiving, investigate input timeout behaviour, camera availability and whether the RTSP server permits a new session. Do not claim that changing transport alone repairs every interruption.
Network output
When FFmpeg writes a live stream, consider whether an output FIFO can separate the encoder’s timing from temporary output failure. FFmpeg’s FIFO muxer documentation describes attempt_recovery, recovery_wait_time, max_recovery_attempts, recover_any_error and queue overflow behaviour.
The documented FIFO defaults include recovery disabled, a five-second recovery wait, unlimited successive attempts when the maximum is zero, and overflow dropping disabled. These are documentation defaults, not a reason to paste the same settings into every command. Confirm the options in the FFmpeg version installed on the Pi.
A network-outage example in the documentation uses a FIFO format, a media format suitable for its destination, packet dropping on overflow, recovery attempts and a one-second recovery wait. Adapt the muxer and format to your actual output. An FLV or RTMP-oriented example is not automatically suitable for another destination or protocol.
The central trade-off is continuity versus completeness. If queued packets are retained while the network is unavailable, the queue can fill and the encoder may block or fall behind. If packets are dropped when the queue overflows, FFmpeg can continue closer to real time, but viewers may miss part of the stream. For a devotional audio channel, a short gap may be preferable to a delayed broadcast; for a camera feed where every moment matters, preserving packets may be more important. Decide this before an outage and document it.
Test the network and endpoint again
After identifying the failing side, reproduce the problem in a controlled way. Do not begin by unplugging equipment during a valuable live broadcast. Test with a short file, a non-public destination or a separate camera account where possible.
Start with the Raspberry Pi itself. Check whether the interface remains up during the incident, whether the default route is present, and whether the endpoint hostname still resolves. A successful name lookup does not prove that the media protocol works, and a successful web request does not prove that RTSP or the publishing destination is healthy. Test the same protocol and port used by FFmpeg, within the limits of what the endpoint supports.
For an RTSP source, compare the existing transport with TCP and record whether the failure changes. For HTTP, test whether the source responds consistently after a forced disconnect and whether it sends a response that your FFmpeg build treats as retryable. For output, confirm that the destination accepts a fresh connection and inspect its own status page or control room.
Also test the physical and local conditions without jumping to a hardware purchase. If Wi-Fi is unreliable, a wired connection may remove one variable, but it will not fix an unavailable camera, a rejected stream key or a failing destination. Check power, temperature, storage, CPU load and memory when the stream includes camera capture or encoding. A network drop and a resource exhaustion event can occur at the same time.
Keep a small incident table with the timestamp, protocol, input state, output state, process state, first log error and recovery result. After several tests, patterns become easier to see: only UDP sessions fail, only the output fails, or only the process launched from SSH disappears. That evidence is more useful than adding options at random.
Add supervision and watch YouTube health
Once the FFmpeg command behaves correctly during normal operation, add supervision for process-level failure. Use a service manager or another reliable launcher that can restart the command after an unexpected exit, preserve logs, apply a delay between attempts and expose the current state. The exact supervisor depends on your Raspberry Pi operating system and how you deploy the stream.
Keep supervision separate from FFmpeg’s own recovery. FFmpeg may retry an HTTP read or recover a FIFO output while remaining alive. A supervisor handles an exited process. Configure both without creating competing loops: an in-process retry that waits for a long time can make a supervisor appear inactive, while an aggressive supervisor can terminate a process that is still recovering.
Set a restart delay and record the reason for each restart. If the command fails immediately, pause the automatic cycle long enough to inspect the logs. A service that restarts forever without alerting you can make a channel look unattended while viewers see a repeated gap or an offline page.
Monitor the destination separately from the Pi. A running FFmpeg process does not prove that YouTube is receiving a usable stream. Check YouTube Live Control Room for stream health, warnings, dropped frames and the current connection state. Read the current YouTube Help guidance for live streams before changing encoder settings, key configuration or broadcast workflow.
If you run several channels, centralise the incident notes and stream status rather than relying on memory. The advice in running two or three 24/7 channels without losing track is relevant when one Pi or operator is responsible for more than one broadcast. For a channel that needs to continue while local equipment is unattended, compare the operational model described in cloud services for scheduling multiple 24/7 YouTube channels, but keep the same protocol and log diagnosis when an input is still remote.
A cloud-based workflow can remove the Raspberry Pi from the publishing path, but it cannot repair an arbitrary camera, HTTP feed or RTSP source. If your real requirement is to upload a prepared video and publish it continuously to YouTube without leaving a local computer running, StreamNeo removes the need to keep the Pi online for that particular workflow; it does not diagnose or repair unrelated FFmpeg input or output failures.
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 make FFmpeg reconnect after a network drop?
First identify the protocol and whether the failed connection is input or output. HTTP input has documented reconnect controls, while RTSP needs transport and session diagnosis and network output may use FIFO recovery. If FFmpeg has exited, use a supervisor because an in-process option cannot restart a terminated process.
Does -rtsp_transport tcp fix an RTSP disconnect?
It can help test whether UDP loss or reordering is involved, because RTSP can use TCP interleaving instead of UDP media transport. It does not guarantee recovery after every interruption, and the camera, server, firewall and network path must support the chosen transport.
Why does FFmpeg stay running but YouTube shows no useful stream?
The process may be stalled while waiting for input or blocked on output, so a running process is not proof of a healthy broadcast. Compare frame and packet progress with the logs, then check YouTube Live Control Room for connection and stream-health information.
Should I use FIFO recovery or restart FFmpeg?
Use FIFO recovery when the output connection is temporarily unavailable and keeping the encoder near real time is useful. Use an external supervisor when FFmpeg exits. Decide whether queued packets should be retained or dropped, because preserving them can delay the stream while dropping them can create a gap.