“Broken pipe” means FFmpeg tried to write to a pipe or output endpoint that was no longer accepting data. The message does not say why it stopped, or even establish that YouTube was the endpoint.
A “YouTube radio stream” might mean FFmpeg is reading a YouTube source, publishing a radio feed to YouTube Live, or passing data between programs while doing either. Start with the full command and log to establish direction, then test input, processing and output separately.
What “broken pipe” means
A pipe is a route by which one process writes data for another process to read. It can be a shell pipeline, such as producer | ffmpeg ..., or an output connection handled by FFmpeg. When the receiving end closes and the writer tries to send more data, the operating system reports a failed write. FFmpeg maps that condition to the text “Broken pipe” in its error source (FFmpeg’s error source).
That is a description of the failed operation, not a complete diagnosis. It tells you that a write could not complete; it does not name the process that closed the connection, why it closed, or whether the underlying cause was a network interruption, an ended session, a consumer that exited, or something else. The endpoint named near the error and the sequence of earlier messages matter more than the error phrase by itself.
Timing is useful evidence, but not proof. An error immediately after starting may point you to an endpoint that never accepted the data or to a consumer that exited early. A failure after a period of successful streaming may warrant checking for a disconnection or session ending. An error near end of input could simply coincide with a process finishing. Record when it happens and what was being written at the time; do not turn timing alone into a root-cause claim.
First establish which direction the stream travels
The wording of the query is ambiguous. “On a YouTube radio stream” might mean you are pulling a source from YouTube, sending a radio programme to YouTube Live, or using another programme to move media between steps. Those are different paths, and a setting for one direction will not necessarily affect another.
Read the command from left to right. An input option followed by a URL or file after -i identifies what FFmpeg is trying to read. The final output URL or path shows where the resulting media is sent. If the command contains |, there is also a shell pipe between processes; inspect which command is the writer and which is the consumer. A shell error from a downloader is not the same evidence as FFmpeg reporting an error on its named output.
Keep a copy of the exact command, including quotes and options, and capture standard error from FFmpeg and any other process in the pipeline. Note the exit status of each process if your shell makes it available. In a pipeline, one process can stop while another is still trying to write, so retaining only FFmpeg’s last line may hide the first failure.
This distinction also helps you choose relevant guidance. For example, advice on sending an AAC internet radio feed to YouTube Live concerns publishing. It does not diagnose a problem reading a YouTube source. First identify whether YouTube is the input or the output, and whether another process is involved.
Find the failing operation in the complete log
Save the complete FFmpeg log from startup through the failure. Read the lines immediately before “Broken pipe” as well as the line containing it. FFmpeg may identify an output, a protocol operation, or a stream just before the final error. Preserve enough context to see whether input opened successfully, whether media packets were read, and whether output writing had begun.
Look for the named endpoint. It may be standard output, a local file, an HTTP source, an RTMP destination or another URL. These names point to different sides of the workflow. A failure associated with an HTTP input deserves input-side investigation; one associated with an RTMP output deserves output-side investigation. If the log does not make the endpoint clear, the command line is needed to interpret it.
Record the FFmpeg version and build, operating system, approximate time of failure, and whether the stream stopped immediately, ran for a while, or ended with the source. These details do not diagnose the issue by themselves, but they make a follow-up report useful. “It says broken pipe” is not enough information for someone else to distinguish a closed shell consumer from a remote output session.
Do not remove options or shorten the command before saving a copy. Options that appear incidental can change which protocol is in use, how the input is read, or what FFmpeg writes. If you share the command publicly, redact stream keys, private URLs and credentials, but retain the structure and relevant protocol names.
Inspect the command and identify the pipe endpoint
Separate the command into three parts: input, processing and output. The input is generally specified with -i; processing includes any filters or codec choices; output is the destination following those choices. A pipe character in the shell adds another boundary outside FFmpeg itself. Identify each writer and receiver rather than treating the whole command as one connection.
For example, in source-program | ffmpeg -i pipe:0 ... output.mp4, the first program writes to the shell pipe and FFmpeg reads from it. In a different command, FFmpeg might write to pipe:1, with a second program consuming standard output. If that consumer exits, FFmpeg can encounter a failed write even though its media input is healthy. Conversely, a remote output can close while a shell input pipe continues to deliver data.
A useful incident note can be brief: “FFmpeg read from this input, wrote to this output, and failed after this earlier log event.” Include the relevant command with secrets removed and stderr from all processes. This makes it possible to ask a specific question: did reading fail, did local processing fail, or did a receiver stop accepting output?
If the workflow is an always-on broadcast, do not assume that keeping the source file accessible solves an output failure. The prerequisites for a continuous pre-recorded YouTube stream are a separate operational concern from locating which write returned the error. Establish the failing boundary first; then consider how the broadcast should recover from it.
Test the input separately
If FFmpeg is reading a YouTube stream or another remote source, first establish whether that input can be opened and read without the rest of the production path. Use a diagnostic command that reads the source and reports its streams or processes a short portion without sending anything to the intended remote destination. The goal is to learn whether the failure occurs before output is involved, not to prove that the source will remain available indefinitely.
For an input that is a local file, test that FFmpeg can open it and read beyond the beginning. For a network input, observe whether FFmpeg receives media and whether the source ends or disconnects before the reported write error. If another downloader or extractor supplies the input, capture that program’s stderr and exit status too. A BrokenPipeError from that program has a different origin from an FFmpeg error naming its own output.
FFmpeg documents HTTP protocol reconnect options for specific input-side conditions, including a disconnect before EOF, treating EOF as an error for live or endless streams, and selected network or HTTP errors (FFmpeg protocol documentation). These options are relevant only when the input uses HTTP and the observed failure matches the option’s purpose. Check the documentation and the options available in your installed FFmpeg build before changing the command.
Reconnect behaviour is not a general repair switch. It will not fix a shell consumer that has quit or an unrelated RTMP output that no longer accepts writes. It can also affect what happens when the source reaches its end, so distinguish a naturally finite input from a source intended to remain live. Change one input-side option at a time and compare the resulting log with the original.
Test processing and output separately
Once you know that the input can be read, test whether FFmpeg can process it and write a short output to a local file. This removes the remote destination and any downstream consumer from that test. If local output fails too, look at the input, selected streams, filters, codecs, disk path and permissions rather than assuming a server connection is responsible.
Next, test the destination using a known-good local file, with the same relevant output format and protocol as the original command. This isolates remote output from source reading and live processing. If the local-file test works but the full live command does not, compare differences in the input, timing, codecs, session handling and any shell pipeline. A successful short test is evidence about that test, not a guarantee about a long-running stream.
This isolation approach resembles a 2019 FFmpeg-user mailing-list discussion of a related pipe-to-RTMP problem, where local-file and destination tests were used to separate parts of the workflow (mailing-list example). Treat it as a practical diagnostic pattern, not a universal fix or proof about your command. The protocols and process arrangement may differ.
If the remote output is intermittent, distinguish recovery from diagnosis. FFmpeg’s FIFO muxer can separate encoding and muxing and attempt output recovery (FFmpeg formats documentation). Its queue and recovery behaviour depend on the configuration. Allowing packet dropping when a queue fills can let processing continue, but it means part of the stream is omitted. That trade-off may be unacceptable for a devotional programme, a news update or a business announcement where completeness matters.
Recovery settings do not establish that the underlying endpoint problem is solved. They may help a workflow tolerate a temporary interruption, but a persistent rejection, wrong destination or stopped consumer still needs investigation. Decide whether continuity or complete delivery matters more for the material, and confirm the appropriate muxer and options for the installed build rather than pasting a generic block of flags into a command.
For a small team that needs a prerecorded programme to keep running while its own computer is off, StreamNeo removes the specific burden of leaving that computer to handle the broadcast and restarting it after a drop. It does not identify every FFmpeg broken pipe, and it is YouTube-only; first decide whether the problem is actually in a local pipeline or a remote output you control.
Check YouTube settings only when YouTube is the output
If the command sends a live stream to YouTube, compare its output settings with YouTube’s official encoder guidance. YouTube lists RTMP or RTMPS, constant bitrate encoding, AAC or MP3 audio, and recommends a two-second keyframe interval that should not exceed four seconds. It recommends RTMPS (YouTube’s live encoder settings). These are compatibility checks for publishing, not explanations for every failed write.
Also review the current live control-room diagnostics and confirm that the destination and session are the ones intended. A stream can be described as a YouTube radio stream while YouTube is only its source, in which case publishing guidance is not the relevant first check. If you are reading from YouTube, focus on input behaviour and the exact endpoint in the log instead.
Even when YouTube is the output, do not infer that YouTube caused the error merely because it appears in the workflow. A shell-pipe receiver, an intermediate program or a network output session may be the point that stopped accepting data. The command and complete log determine which checks are relevant; encoder compatibility alone cannot identify the failed write.
What to send when the fault is still unclear
If isolation has not narrowed the problem, prepare a compact report rather than changing several things at once. Include the full command with stream keys and private credentials removed, the FFmpeg version and build, operating system, complete stderr from each process, and the exit status of each command. State whether FFmpeg reads from YouTube or publishes to it, which endpoint the log names, and whether the failure is immediate, delayed or at end of input.
Describe the tests you have already made: input-only read, short local-file output, and known-good local file to the intended destination. Give the result of each in plain terms. That evidence helps someone identify the boundary that failed without pretending the error message supplies a cause on its own.
If the tests point to a process arrangement rather than a YouTube setting, a guide such as running a 24/7 nature-sounds stream with Docker and FFmpeg may be useful for broader workflow context. It cannot substitute for your command and logs; keep the immediate diagnosis tied to the endpoint that failed.
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 disconnected FFmpeg?
No. It means a write failed because the receiving endpoint was no longer accepting data. That endpoint could be a shell-pipeline consumer, a remote output or a server session; the command and surrounding log are needed to tell which.
Should I add HTTP reconnect options?
Only if FFmpeg is reading an HTTP input and the observed failure matches the reconnect behaviour you need. Those input-side options do not repair an unrelated output write or a shell-pipe failure. Check the documentation for your installed build and preserve the original command for comparison.
Will FIFO recovery fix a broken pipe?
It can help decouple processing from muxing and attempt recovery in some output workflows, but it is not proof that the endpoint problem is resolved. Dropping packets when a queue fills trades completeness for continued processing, so consider whether that loss is acceptable before using it.
What information is needed for a definite diagnosis?
Provide the complete command with secrets removed, full logs from every process, FFmpeg version and build, operating system, exit statuses, and whether YouTube is the input or output. Include the named endpoint and when the error occurs. Without those details, the message alone cannot establish the root cause.