Broken pipe tells you that FFmpeg failed while writing output; it does not tell you why the write failed. To diagnose FFmpeg broken pipe YouTube reports, start with the complete failing command and log, then check whether the error lines up with a playlist transition before changing settings.
The same message can follow a closed connection, a rejected destination, an interruption in the outbound path, or another output failure. A useful fix depends on the exact command, FFmpeg version and build, output protocol, and the messages immediately before the failure. There is no single flag that resolves every case.
What “Broken pipe” establishes
FFmpeg maps the system error EPIPE to “Broken pipe”. That is a description of a failed write, not a diagnosis of what caused it. The remote end may have closed a connection, the network path may have stopped carrying data, or a local process may have exited; the label does not distinguish among them. See FFmpeg’s error mapping for the meaning of the label.
Find the first error in the log rather than treating the last printed line as the explanation. For example, av_interleaved_write_frame(): Broken pipe may be followed by a message about muxing or writing a trailer. Those later messages can be consequences of the original write failure. Note the output URL scheme, such as rtmp://, rtmps:// or an HLS destination, and the muxer named in the command.
The error alone cannot establish that a playlist is malformed, that stream copy is at fault, or that YouTube rejected the broadcast. Keep those as hypotheses until timing and log context support one. If you also need to review the wider symptoms viewers see, use the practical checks in how to improve live stream quality and prevent playback problems, but do not assume a playback issue and a broken output write have the same cause.
Capture the complete FFmpeg log
Save the full command, FFmpeg version/build information, and stderr from startup through the point of failure. Remove the stream key from any copy you share. YouTube describes the stream key as a password-like credential, so treat it accordingly: do not paste it into a public support post, screenshot, or log bundle.
Record when the error occurs. Does it happen immediately after starting, at the end of a file, when the next item begins, or only after the stream has run for a while? Also note whether YouTube Live Control Room reports that the stream ended, whether the encoder itself remains running, and whether viewers see a brief interruption. These details help distinguish a repeatable transition problem from an output that fails independently of playlist timing.
Preserve messages before the first Broken pipe line, including any connection, authentication, timestamp, codec, or muxer warnings. A cropped log containing only the final error removes the evidence needed to tell whether the pipe failure is the first event or a downstream consequence. Include the complete command structure but replace credentials and private paths with placeholders; preserve input and output options, their ordering, the output scheme, and the muxer.
Capture the version and build using the information FFmpeg prints when asked for its version and configuration. Builds may differ in enabled protocols and libraries, so “FFmpeg” by itself is not enough detail to reproduce behaviour. Do not post credentials while asking for help. With those records saved, you can repeat a test without losing the original evidence.
Check playlist and file-loop boundaries
Compare the error timestamp with the end of each file and the start of the next. If it consistently appears as a video loops or when a playlist advances, test one source file by itself with the same output configuration. Then test the transition again. Change one thing at a time so that a successful or failed test has diagnostic value.
A loop-boundary failure has appeared in an individual FFmpeg-user report involving a repeated MP4 and stream copy. The report is a useful example of why timing matters, not evidence that -stream_loop or -c copy is generally defective. You can read the reported FFmpeg-user log, including its av_interleaved_write_frame(): Broken pipe message, but do not treat that one setup as a diagnosis of yours.
If a single file runs but the transition fails, compare the inputs’ stream parameters and timestamps around the boundary. Check whether the video and audio streams remain compatible from item to item, and whether the command’s handling of timestamps is consistent. This points you towards the transition for further testing; it does not prove that a specific timestamp option is the fix.
If the stream fails during a single file as well, the playlist transition is less likely to explain the write failure. Move on to the destination, stream health, and outbound connection checks. For help separating playlist organisation from encoder behaviour, see how to keep an OBS playlist in sync after replacing videos in its folder; an OBS playlist issue is distinct from an FFmpeg output error, but the distinction can help you isolate which part of your setup is changing.
Verify YouTube’s current ingest settings
Open YouTube Live Control Room and copy the current Stream URL and stream key into the encoder configuration. Do not rely on a URL or key saved in an old script without checking it against the current event or channel settings. A stale key or incorrect destination can prevent the encoder from connecting or keep it from starting as expected. YouTube’s streaming troubleshooting guidance advises checking the current key when encoder startup is rejected.
Keep the URL and key separate in your notes: record the scheme and host, but redact the key. Confirm that the command uses the URL from Live Control Room rather than a guessed endpoint, and that the credential belongs to the intended stream. If you rotate a key, update the encoder that is actually running, not only a saved copy of the command.
A failure immediately at startup makes destination and credential checks especially worthwhile, but it is not proof of a key problem. Read the surrounding output for connection or rejection messages. If the encoder appears connected and runs before the failure, keep investigating rather than repeatedly replacing the key without evidence.
Inspect Live Control Room stream health
While reproducing the failure, watch YouTube’s Live Control Room for stream status and health information. Note whether the stream is received, whether health warnings appear, and whether the status changes at the same moment as FFmpeg’s first write error. YouTube recommends reviewing stream health and checking that the encoder is current and operating correctly in its live-stream troubleshooting advice.
Compare the local input and output conditions. If the source plays normally but Live Control Room reports a problem, the outbound path or the encoded stream’s settings may need attention. If the encoder itself reports input, decode, or local resource errors before the pipe message, investigate those first. Healthy playback on the computer does not establish that YouTube is receiving a healthy stream.
Keep a short record of the time, the Live Control Room status, and what the encoder printed. This makes it easier to see whether warnings precede the write failure or appear afterwards. Avoid interpreting a health label in isolation; follow the current YouTube guidance for the warning shown and compare it with your log.
Check outbound connectivity and settings
YouTube recommends testing the strength of the outbound internet connection. A connection that is adequate for browsing or watching video may still be unstable when continuously sending an encoded stream. Check whether upload activity is shared with other devices or transfers, and whether the stream fails at a particular time or under a repeatable load. These are checks, not proof that your router, cable, or internet provider is at fault.
Compare the configured bitrate with the available, sustainable upload capacity and the selected resolution, frame rate, and codec. YouTube’s encoder settings guidance gives configuration recommendations that vary by those choices. It recommends a two-second keyframe interval, not exceeding four seconds, and supports frame rates up to 60 fps. These are YouTube configuration specifications, not a universal remedy for Broken pipe.
A bitrate reduction may be a useful controlled test if the outgoing connection cannot sustain the configured rate, but first record the original settings. If reducing it changes the result, that narrows the investigation; it does not by itself identify the failing network component. For an always-on channel, also consider whether the sending computer and its connection remain stable overnight. A spare-PC setup for 24/7 YouTube streaming can help you think through the local operating conditions, but hardware changes are only warranted when evidence points to a local bottleneck.
Use command and build evidence to narrow causes
Read the output part of the exact command from left to right: identify the protocol in the destination URL, the selected muxer, the audio and video codecs, and whether the command copies or encodes each stream. Do not add a flag simply because it appears in an unrelated example. An option that helps one protocol or input arrangement can be irrelevant to another.
For RTMP or RTMPS, verify that the URL scheme, destination, and build support match the intended ingest method. YouTube recommends RTMPS for encrypted RTMP ingestion. Its RTMPS guidance says to check the URL and try port 443 for an SSL certificate error; for a connection timeout, check the URL and confirm the encoder build supports RTMPS. Those checks apply to the corresponding symptoms, not to every Broken pipe report.
YouTube’s RTMP/RTMPS settings guidance lists H.264, H.265, or AV1 video and AAC or MP3 audio, alongside CBR and its frame-rate and keyframe recommendations. Verify that the actual output streams match the selected protocol’s current requirements. If you are using stream copy, inspect the source streams rather than assuming the destination encoder settings have re-encoded them.
| Ingest method | What to verify | Playlist implications |
|---|---|---|
| RTMP or RTMPS | Destination URL and scheme, build support, codecs, bitrate and keyframe settings | A local file loop is separate from YouTube’s HLS segment-playlist rules |
| HLS | HTTPS destination, supported segment format and rolling playlist behaviour | YouTube documents TS segments, one-to-four-second segment durations, and no more than five outstanding segments |
HLS is segmented ingestion, with higher latency than continuous RTMP, and its playlist rules apply only when you have configured HLS. YouTube’s HLS ingestion guidance specifies HTTPS, TS segments, a rolling playlist, no more than five outstanding segments, and segment durations of one to four seconds. Do not apply those HLS constraints to an ordinary RTMP or RTMPS output just because your local source is a playlist.
After checking protocol and settings, test one source file and then the playlist transition under the same output configuration. If only the transition fails, inspect continuity and input compatibility. If both tests fail in the same way, prioritise destination, connection, stream health, and the encoder build. This sequence narrows possibilities; without your exact command, build, protocol, and full log, it cannot establish a root cause.
Keep a test record and choose the next step
For each test, write down the command changes, source file, start time, first error, and Live Control Room status. Change only one relevant variable between runs. If you switch protocol, for example, also record the new URL scheme and muxer so that you do not mistake a change in destination for a codec change.
Do not keep a long-running stream online while making unrecorded edits to its command. Stop it deliberately, preserve the old log, make the one controlled adjustment, and compare the new run. If the failure cannot be reproduced after a change, retain the original settings and repeat under comparable conditions before deciding the cause was found.
When the problem is that a local computer must keep a playlist running and recover after interruptions, StreamNeo removes that particular operational burden by turning an uploaded video into a YouTube live stream that can continue with your computer switched off. It does not change YouTube’s ingest requirements, and you should still confirm that your file and channel are ready before relying on any broadcast arrangement.
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 rejected my stream?
Not by itself. It means FFmpeg encountered a failed write; the complete log and Live Control Room status help show whether a connection, credential, stream-health, or other output issue came first.
Is -stream_loop -1 the fix for a playlist that breaks?
No single loop flag is a universal fix. Compare the error time with file boundaries, test one file using the same output settings, and then test the transition; a report involving a loop is evidence about that setup only.
Should I change from RTMP to HLS to stop the error?
Not without evidence that the current protocol or destination is the problem. RTMP/RTMPS and HLS use different ingest requirements, and HLS’s segment and rolling-playlist rules apply only when you have configured HLS.
What information should I include when asking for help?
Include the full command with the stream key removed, FFmpeg version and build, protocol, complete stderr through failure, and whether the error is immediate, occurs at a transition, or follows a long run. Add the corresponding Live Control Room status, but never publish the key itself.