A FFmpeg “Broken pipe” error means FFmpeg could not write to its output connection. It does not, by itself, tell you why the write failed, so it is not proof that YouTube, your internet connection or an encoding setting caused the stop.
Start by preserving the evidence around the first failure. Then compare the local log with YouTube Live Control Room, check the output endpoint and the loop process, and only then test a recovery change. That order helps you avoid changing several things without learning which, if any, mattered.
What the error tells you, and what it does not
FFmpeg writes the encoded stream to an output connection. A broken-pipe report says that a write to that connection failed. It describes the failed operation, not the event that led to it. The remote end may no longer be accepting data, the connection may have been interrupted, or another part of the output path may be involved; the message alone cannot distinguish among those possibilities.
The same distinction matters when a loop stops. The input file may still be readable while FFmpeg’s output write has failed, or FFmpeg may have exited for a separate reason. A message near the broken-pipe line can give more context, but do not treat one line as a complete diagnosis. The FFmpeg muxer documentation describes output recovery controls; it does not establish a universal cause for every FFmpeg and YouTube setup that reports this error.
Think of the error as a symptom to investigate rather than an instruction to change bitrate or restart your router. If you immediately alter encoding options, you may mask a separate connection or process problem. If you immediately restart, you may lose the time and surrounding messages needed to work out what stopped first.
For longer-running broadcasts, distinguish a temporary interruption from the end of the event itself. A stream can stop locally while the YouTube event remains open, or the event state can change while your process is still running. The practical question is not only “Did the loop stop?” but also “What did FFmpeg report, and what did YouTube report at the same time?”
Preserve the full FFmpeg error context
Before restarting FFmpeg, save the complete log from shortly before the first error through process exit or recovery. Record the timestamp, how long the stream had been running, whether there was a visible interruption, and whether FFmpeg exited or continued printing messages. If you only retain the final “Broken pipe” line, you may discard the warning or state change that preceded it.
Keep a copy of the exact command used, but remove the stream key and other secrets before storing it somewhere shared or asking for help. A stream key is effectively a credential for broadcasting to your channel. Do not paste it into a public forum, screenshot, log bundle or support request. If it has been exposed, follow YouTube’s current guidance for replacing or resetting it.
Also note the FFmpeg version and build information. Options vary between releases and builds, and a command copied from another machine may not be available in yours. A minimal record might include:
| Evidence to save | What it helps you establish |
|---|---|
| Full log around the first failure | Which warnings, reconnect messages or process errors came first |
| Sanitised FFmpeg command | Which input, output protocol and options were actually used |
| FFmpeg version and build | Whether a suggested option is present in your installed build |
| Failure timestamp and runtime | Which moment to compare with YouTube’s report |
| Control Room health messages | Whether YouTube reported an ingest or configuration issue |
| Process state after the line | Whether FFmpeg exited, kept running or began recovery |
Avoid “cleaning up” the log before keeping an original copy. Filtering out repeated lines may help you read it, but the unfiltered version can matter if timing or order is in question. If you are streaming from a Windows PC, VPS or another host, record which machine and network path were in use, without assuming that either one is responsible.
If the same loop has stopped repeatedly, compare the records rather than relying on memory. A failure at a different point in the file, a change in the surrounding log or a different YouTube message may be more useful than the fact that the final line looks identical. For broader planning around long broadcasts, see how long a YouTube live stream can run before it stops; that does not diagnose this error, but it helps separate event-duration questions from a failed output write.
Match the time with YouTube’s stream health
Open YouTube Live Control Room and look for the health messages that correspond to the failure timestamp. YouTube’s live streaming error messages page describes timestamped errors and distinguishes critical from moderate issues. Use the matching message as evidence about what YouTube observed; do not assume that a local FFmpeg message and a platform warning have the same cause merely because they occurred during one broadcast.
YouTube may report a particular problem with format, bitrate, audio or video settings, keyframe frequency, resolution, or consistency between primary and backup streams. Treat the actual message as a clue to check that item. For example, if the Control Room identifies an unexpected resolution, compare the configured output with the expected resolution for that stream. Do not change unrelated audio or keyframe flags in the same test.
The YouTube encoder settings guidance covers supported protocols and encoder settings, and recommends testing settings and monitoring stream health. It recommends RTMPS, but that general recommendation does not mean a broken pipe proves that your protocol is wrong. Exact requirements depend on the selected ingestion configuration and quality. Use the current guidance and the specific Control Room message rather than treating a generic setting as a universal fix.
If Control Room shows a configuration warning before the local write failure, address that warning on its own terms and run a test. If it shows no corresponding warning, that does not prove the internet path or FFmpeg is at fault; it only means the evidence you have does not identify a matching YouTube health message. Keep the distinction explicit when recording the result.
A practical comparison is to note the first local error time and the nearest platform message time, then check whether the sequence repeats in a later test. You are looking for correlation, not certainty from one timestamp. If your loop includes changing scenes or content, note what was playing at the time too, but do not infer that a particular file caused the write error without supporting evidence.
Inspect the output connection and endpoint
Check the output URL, protocol, host and port against the current instructions for the encoder and the ingestion configuration you selected. Small differences matter: an old endpoint copied from a previous setup or an incorrect port can make a connection attempt fail, although the broken-pipe line alone cannot tell you that this happened. Google’s RTMPS ingestion documentation explains YouTube’s RTMPS connection details and notes that an SSL error can result from connecting to the wrong port.
Confirm that the stream key is current and assigned to the intended event, but never include it in diagnostic output. Check for a mismatch between the event’s primary or backup stream and the output your command is sending to. A connection can be pointed at a valid service and still not match the event configuration you meant to use.
When the failure happens, look for other contemporaneous signs: did the machine lose its network connection, did the process log a connection reset or timeout, or did only the output write report an error? These observations narrow down what to test next; they do not establish a cause on their own. If others share the connection, ask whether there was a known interruption at that time, but avoid replacing the whole network setup based only on this one symptom.
YouTube recommends RTMPS as a protocol choice in its encoder settings guidance. If you are moving from RTMP to RTMPS, verify the endpoint and port from the current documentation rather than just changing a protocol label in a command. You should also test the change before depending on it for an overnight loop. A secure protocol recommendation and a diagnosis of a particular failed write are different things.
Do not publish an unredacted command when asking someone to inspect an endpoint. A useful command excerpt shows the protocol and non-secret options while masking credentials and keys. If you are unsure whether a field contains a secret, redact it first and preserve the private original only where you control access.
Review the loop and process behaviour
Check whether the input loop actually restarted or continued after the output failure. In the process output, distinguish messages about reading or looping the source from messages about writing to the destination. A loop option controls how input is repeated; it does not guarantee that the output connection remains available. If FFmpeg exits, note the exit status and the last messages before exit rather than assuming the loop flag failed.
For a file-based stream, verify that the source file is still present and readable and that the command’s loop behaviour is what you intended. This is especially useful if you have changed the file, directory or command since the last stable test. A local input error can coexist with an output problem, but do not conflate them simply because the broadcast stopped at the same time.
If FFmpeg remains active after the error, check whether it is producing more output, retrying, waiting, or stuck. Do not launch a second copy against the same event and key as a reflex; two processes can make the resulting state harder to interpret. First note the state of the original process and the event in Control Room, then decide whether a controlled restart is appropriate.
The scope of the job matters. A single prerecorded lesson or devotional video repeated continuously has different operational needs from a playlist that changes content. For a basic file loop, how to loop pre-recorded study videos on YouTube Live offers related setup context, while this page focuses on what to inspect when the output write fails. If a playlist is involved, record which item was active and whether the transition coincided with a process or output message.
Keep the test simple enough to explain. If you replace the input file, alter the encoder settings, change the endpoint and add recovery flags all at once, a later successful run will not tell you which change helped. Preserve one known baseline and change one relevant factor at a time.
Test recovery without assuming the cause
FFmpeg’s muxer documentation includes output recovery controls such as attempt_recovery, recovery_wait_time and recover_any_error. These are options to evaluate after you have captured a baseline, not a diagnosis of the original failure. Check the documentation for the FFmpeg release installed on your machine and confirm that the relevant output muxer supports the option and syntax you intend to use.
Recovery behaviour can affect the stream. Depending on the configuration and interruption, output may be delayed or media may be dropped; the documentation is not a promise of seamless recovery, frame-accurate continuation or that YouTube will keep the same live event open. The example in FFmpeg’s documentation illustrates a recovery configuration, but an example is not a universal command to paste into every loop. Validate it against your output protocol and event setup.
Compare options by what they change and what evidence they address:
| Test choice | Evidence it addresses | Main trade-off to consider |
|---|---|---|
| Correct a specific Control Room warning | A reported ingest or settings mismatch | Changes stream configuration; may affect compatibility or quality |
| Verify endpoint and port | A questionable URL, protocol or connection detail | Changes connection configuration, not the encoded media |
| Test an FFmpeg recovery control | Repeated output failures where recovery behaviour is relevant | May delay or drop media; support and syntax depend on build and muxer |
| Leave encoding unchanged and gather another log | No clear evidence implicating encoding | Takes another test to learn more, but preserves a useful baseline |
Choose the smallest test that addresses the evidence you have. If YouTube reports a specific format or bitrate issue, correct that item and test. If the endpoint appears inconsistent with the selected event, verify it against current instructions. If neither log nor Control Room identifies a setting mismatch, avoid speculative changes to resolution, bitrate or keyframe frequency simply because those settings are available.
YouTube’s settings page advises testing with representative audio and motion and monitoring stream health. Use a short controlled test before relying on a long-running broadcast. Keep the content, event configuration and machine conditions as close as practical to the real loop; a static image may not reveal an issue that occurs with motion or audio. Record the result, including whether the same error returns and what Control Room reports.
Some operators cannot afford even a brief interruption; others can accept a restart if it produces a clearer diagnosis. Decide that before enabling recovery behaviour. If you need the broadcast to continue while your own computer is switched off, a hosted loop can remove the need to keep that machine running; StreamNeo takes an uploaded video and runs it as a YouTube live stream, which addresses that specific operating burden rather than diagnosing a broken-pipe event.
Make a repeatable test plan for the next run
Write down the baseline before changing anything: command with secrets removed, source file or playlist, FFmpeg build, endpoint type, event configuration, and the time and duration of the failure. Then state the single question for the next test. Examples include whether a Control Room warning changes after correcting a reported setting, whether a verified port removes an SSL connection error, or whether an installed build accepts a documented recovery option.
Keep the test conditions representative. If the normal channel runs a long bhajan video or ambience loop with continuous audio, use a sample with comparable audio and motion. If the normal schedule alternates lessons, use a test that includes a transition. This is not a guarantee that a short test predicts every overnight condition; it is a way to avoid testing a materially different workload and drawing a broad conclusion from it.
After the test, compare the first relevant local log line with the health report and note whether FFmpeg exited, recovered, or continued. If the result is different, retain both records. If it is the same, you have ruled out one change as a sufficient fix under those conditions, not necessarily every possible explanation. This phrasing keeps your notes useful rather than turning one test into an overconfident rule.
For channels with multiple languages or recurring schedules, document which file and event each command is meant to serve. A setup guide for rotating playlists across multiple language channels covers a related organisational problem. Here the same discipline helps you avoid inspecting the wrong process or event when a loop stops.
Before you depend on a revised setup, run it long enough to exercise the relevant transitions and monitor the Control Room. YouTube’s advice is to test and monitor, not to assume that a particular option guarantees an uninterrupted stream. Keep a way to restart deliberately, and make sure whoever is on duty knows where the logs and event health information are kept.
If your immediate need is simply to get back online, a restart may be a reasonable operational choice, but save the evidence first. Note the time of the restart and the event state so you can distinguish recovery from diagnosis. Returning to air and finding the cause are separate tasks, and you may need to do the latter after the channel is stable.
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 “Broken pipe” mean YouTube stopped my stream?
No. It reports that FFmpeg’s write to its output connection failed; the line does not identify why the connection stopped accepting data. Compare its timestamp with YouTube Live Control Room and the surrounding FFmpeg log before drawing a conclusion.
Should I lower my bitrate when I see this error?
Not unless the evidence points to a bitrate problem. If Control Room reports an expected bitrate or another specific setting, check the current YouTube guidance for that stream configuration and change the reported item rather than unrelated flags.
Can FFmpeg automatically resume a YouTube loop after a failure?
FFmpeg documents output recovery controls, but their availability and behaviour depend on the installed build and muxer. Recovery may delay or drop media, and it does not guarantee a seamless resume or that the same YouTube event remains open.
What should I include when asking for help?
Share the full log around the first failure, the FFmpeg version and a command with the stream key and other secrets removed. Include the failure time, process state and matching Control Room messages so someone can compare local and platform evidence.