A Broken pipe message means FFmpeg could not complete a write to the YouTube output. It does not, by itself, tell you whether the network failed, YouTube closed the connection, the stream key is stale, the event ended, or an earlier input problem caused the output to stop.
The reliable fix is therefore not one magic flag. Capture the lines before the error, compare their timestamp with YouTube Live Control Room, identify where the failure began, and only then change the endpoint, network, encoding or recovery behaviour.
What “Broken pipe” tells you
A streaming command has an input side and an output side. FFmpeg reads the video and audio, encodes or copies them, packages the result and writes it to the network connection. A broken pipe appears when that final write fails because the connection is no longer accepting data.
That is useful evidence, but it is not a complete diagnosis. The remote receiver may have closed the connection. A route between your computer and YouTube may have interrupted the session. You may be writing to an old server address or invalid key. YouTube may have rejected the stream configuration or ended the session. FFmpeg may also have encountered an earlier error that is more informative than the final Broken pipe line.
Look for the first meaningful failure, not the last line printed. If the log says that the input could not be decoded, the output write may only be where FFmpeg finally noticed the problem. If connection or SSL messages appear before the broken pipe, investigate the destination and transport. If the stream ran normally for hours and then stopped, network or receiver-side evidence becomes more relevant, but it still does not prove a single cause.
This is why changing -reconnect, increasing a buffer or adding a keepalive option before reading the log can waste time. A setting that helps a temporary network interruption cannot repair a wrong stream key or an intentionally closed YouTube event.
Capture the lines immediately before the error
First save the complete FFmpeg console output for a failed attempt. Do not copy only the final line. Keep the first connection messages, the input description, the selected video and audio streams, warnings during the run, and the final shutdown messages.
The most useful section normally begins several lines before the first Broken pipe. Record the clock time as well as the elapsed duration shown by FFmpeg. Note whether the frame count, timestamp or speed continues to advance immediately before the failure. Also note whether the message occurs while opening the output or after the stream has already been publishing.
A practical record for each attempt includes:
| Observation | What it helps distinguish |
|---|---|
| Connection fails before the first frame is sent | Endpoint, protocol, key, DNS, TLS or firewall issue |
| Stream runs, then the write fails suddenly | Network interruption, receiver closure or session change |
| Input timestamps stop before the write error | Source file, decoder or local processing problem |
| YouTube reports a health error at the same time | Configuration, bitrate, codec or ingest evidence |
| FFmpeg continues encoding while output writes fail | Possible temporary output failure or queue pressure |
Remove the stream key, credentials and private URLs before sharing a command or log. A redacted command can retain the codec, resolution, bitrate, output format and general URL scheme without exposing access to the channel.
If you are deciding whether FFmpeg or OBS is more suitable for a prerecorded loop, the comparison in FFmpeg vs OBS for a prerecorded YouTube live loop is useful context. It does not replace the log for this particular failure, but it can help you understand which part of the setup you are responsible for supervising.
Check YouTube Live Control Room timestamps
Open the affected event in YouTube Live Control Room and compare its stream health history with the FFmpeg clock. YouTube provides stream health information and timestamped messages, including critical errors and less severe quality problems. A message that begins at the same time as the FFmpeg failure is stronger evidence than a general warning displayed much earlier.
YouTube’s live stream troubleshooting guidance can help you interpret encoder and stream-health messages. Read the message as a clue about the failure layer. For example, a configuration warning points towards the encoded stream, while a sudden loss of connection points towards transport or the receiving session.
Check what happened to the event after FFmpeg stopped. Was it still waiting for data, still live, ended, or showing a separate error? If the event ended because it was stopped manually or because the session was no longer accepting output, restarting the same command may not restore that event. You may need to create or select the appropriate current event and copy its current ingest details.
Make a small timeline:
- The time FFmpeg connected or began writing.
- The time the first warning appeared.
- The time of the first broken pipe or related write error.
- The time YouTube reported a health or connection change.
- The time the event changed state.
This prevents a common mistake: treating a YouTube warning from the beginning of the broadcast as the cause of a failure that happened much later. It also shows whether the remote service noticed the problem before FFmpeg did.
Check the destination and stream state
Refresh the stream details in Live Control Room rather than relying on a URL copied from an older broadcast. Confirm that the server address and stream key belong to the event you are currently trying to publish to. Keep the key private, even when asking for help.
For RTMPS, YouTube directs you to reveal and copy the RTMPS URL from the stream settings. Do not turn an RTMP address into an RTMPS address by editing a few characters and assuming the result is valid. YouTube’s RTMPS troubleshooting instructions say to check that both the server and protocol use rtmps, verify that the encoder supports RTMPS, and consider port 443 if the URL appears correct but an SSL error remains. Those instructions address connection and SSL failures; they are not a universal cure for every broken pipe.
Check the output URL syntax used by your FFmpeg build and shell. A special character in a key can be interpreted by a shell if it is not quoted correctly. Copying the key again is safer than retyping it. Do not include the key in screenshots, public issue reports or example commands.
Also check the state of the YouTube event itself. A key can be current while the selected event is no longer the one you intend to use. A stream that was deliberately stopped, rejected or closed may not accept a blind reconnect. YouTube’s official live encoder guidance is the right place to confirm the current ingest requirements rather than relying on an old preset.
If you need to test whether a prerecorded file really continues through a live event, use a private test first. The guide on testing a YouTube loop privately before going public covers the operational reason for doing this: a short controlled run can reveal an endpoint or media problem without making the first overnight attempt your only test.
Investigate network and upstream failures
A broken pipe can be the final symptom of an upload connection that stopped carrying data. Test the connection at the location and time where the stream normally runs. A result from a different network or a quiet time of day may not represent an overnight channel sharing upload capacity with other devices.
YouTube recommends checking upload speed and choosing a stream quality that the connection can sustain. Compare sustainable upload capacity with the complete stream target, including video and audio overhead. Leave room for other traffic rather than treating the headline speed of a connection as the amount FFmpeg can use continuously.
If the connection cannot sustain the selected target, lower the resolution or bitrate and repeat the test using representative movement and audio. A still devotional image can hide a problem that appears when the source contains motion. Likewise, a silent test does not show whether the audio path and selected audio bitrate behave correctly.
Look for interruptions in the same time window:
- Did another device begin a large upload or backup?
- Did the computer change network interface or wake from a power-saving state?
- Did the router reconnect or change its public route?
- Did the input file or local process consume enough CPU or disk time to stop feeding FFmpeg?
- Did a VPN, firewall or managed network terminate a long-lived connection?
These questions are more useful than replacing hardware without evidence. The research and official guidance do not identify a particular router, cable or internet provider as the fix for a generic broken pipe.
FFmpeg’s protocol documentation also describes TCP keepalive options. Basic keepalive can help the operating system detect a dead peer on a connection that has been idle, but it does not repair a broken route, increase upload capacity or guarantee reconnection. It is most relevant when the connection can remain quiet for a period and you need dead-peer detection, not as a general solution to a stream that is actively failing.
If the stream repeatedly buffers or loses continuity rather than producing a clean broken pipe, compare this investigation with how to fix a YouTube live stream that keeps buffering. Buffering and a failed output write can overlap, but the evidence needed to separate them is different.
Change settings only when evidence points to them
Once the destination and network have been checked, compare the actual encoded stream with YouTube’s current requirements. YouTube lists RTMP and RTMPS streaming, supports H.264, H.265 and AV1 video codecs, allows up to 60 frames per second, recommends a two-second keyframe interval and says not to exceed four seconds. It recommends constant bitrate encoding.
For H.264, YouTube currently lists 5 Mbps as the minimum and 14 Mbps as the recommended bitrate for 1080p at 30 frames per second. For 720p at 30 frames per second, it lists 3 Mbps minimum and 8 Mbps recommended. These are published encoder settings, not a measurement of your upload connection and not a promise that either value will work on a variable link. See YouTube’s live encoder settings for the current resolution, frame-rate, codec and bitrate tables.
Check the actual output rather than the preset name. Confirm the resolution, frame rate, video codec, audio codec, number of audio and video streams, bitrate mode and keyframe interval. YouTube’s error guidance identifies issues such as unsupported codecs, unsupported audio, incorrect resolution or bitrate, missing or multiple streams, and frame-rate or keyframe problems.
Change one relevant setting at a time where possible. If Live Control Room identifies an unsupported codec, change the codec. If the selected resolution is paired with a bitrate your connection cannot sustain, reduce the target. If the keyframe interval is outside YouTube’s guidance, correct that. If there is no evidence of a mismatch, do not alter several settings simply because the final line says Broken pipe.
There are real trade-offs between common output choices:
| Choice | Advantage | Cost or risk |
|---|---|---|
| Higher resolution or bitrate | More detail for viewers with suitable connections | Greater sustained upload demand and less tolerance for variation |
| Lower resolution or bitrate | More headroom on a limited or shared connection | Less image detail and a possible quality reduction |
| RTMP | May work with an older encoder or existing configuration | Does not provide RTMPS transport encryption |
| RTMPS | YouTube recommends it for encrypted transport | Requires the correct endpoint and encoder support |
| Direct output | Fewer moving parts and a simpler command | Less separation between encoding and a temporary output failure |
| FIFO output | Can queue packets and attempt recovery | Adds behaviour to test, and queued or dropped packets affect continuity |
Do not interpret a successful short connection as proof that the settings are suitable for an overnight channel. Test with the same source, motion, audio and network load that the real broadcast will use.
Use recovery only for a failure it can address
FFmpeg’s FIFO pseudo-muxer places a queue between the encoder and the actual output muxer. Its recovery options can attempt to restart the output after a failure. This can be relevant when the input continues normally and the output connection experiences a temporary interruption.
A documented pattern adapted for a YouTube RTMP or RTMPS destination is:
ffmpeg -re -i INPUT \
-c:v libx264 -c:a aac \
-f fifo -fifo_format flv \
-drop_pkts_on_overflow 1 \
-attempt_recovery 1 \
-recovery_wait_time 1 \
-map 0:v -map 0:a \
'rtmp://YOUR_CURRENT_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Replace the illustrative input and destination with your real values. Keep the key private. The example changes the recovery wait to one second. FFmpeg documents a default recovery wait of five seconds, a default of no limit for recovery attempts, and a FIFO queue default of 60 packets. If you run a production service, consider whether unlimited attempts are appropriate and supervise the process deliberately.
drop_pkts_on_overflow 1 allows the encoder to continue instead of blocking when the FIFO queue fills. The trade-off is that packets are omitted, which can create a visible or audible gap. Without dropping, the process may block while the output is unavailable, preserving queued data at the cost of real-time progress. A larger queue can absorb a short interruption but also holds more media and cannot solve a prolonged outage.
FFmpeg also documents restart_with_keyframe, which can be useful when a recovered video output should wait for a clean keyframe. Test this behaviour in a controlled private stream. FIFO recovery is a resilience measure, not proof that YouTube is healthy, not a replacement for checking the event state, and not a guarantee that the same live session resumes seamlessly.
If the recurring problem is leaving a local computer running all night, StreamNeo removes that particular operational burden by letting you upload the video once, provide the YouTube stream key and have the channel run without your computer switched on. It does not remove the need to use media you are entitled to publish or to check the current YouTube stream state.
Verify the next attempt
After making an evidence-based change, run a controlled test and write down exactly what changed. Keep the same input and destination where possible so the result is comparable. If you changed the key or event, record that separately from an encoding change.
Watch FFmpeg from connection through sustained output. Confirm that input timestamps advance, the encoded frame rate is stable, audio is present and the process does not report a growing queue or repeated output failures. At the same time, watch Live Control Room for stream health, error timestamps and event state.
Let the test run long enough to cover the condition that previously caused the stop. A stream that survives a brief check has not necessarily survived a busy household network, a source transition or the period when the original failure appeared. Use a private or unlisted event while testing, then confirm the public event details before switching the channel over.
If it fails again, compare the new timeline with the old one instead of adding another flag immediately. Ask which layer changed: input, encoding, local resources, network, endpoint, YouTube event or output recovery. If the first error remains ambiguous, share a redacted command and the surrounding log with the matching Live Control Room message. That evidence is more valuable than the words Broken pipe alone.
For an always-on channel, also decide what should happen after an unrecoverable stop. A process supervisor may restart FFmpeg, but it cannot make an invalid key valid or reopen an event that YouTube has ended. A human check, an alert or a planned fallback is still needed when the failure is not transient.
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” always mean my internet connection failed?
No. It means FFmpeg could not write to the output connection. The receiver may have closed it, the stream event may have ended, the endpoint or key may be wrong, or an earlier FFmpeg problem may have led to the failed write.
Should I add a reconnect flag immediately?
Not before checking the log and YouTube’s timestamped stream-health information. Reconnection can help with a temporary output interruption, but it cannot correct an invalid destination, unsupported configuration or closed event.
Is FIFO recovery a permanent fix?
No. FIFO can separate encoding from output and attempt recovery after a transient failure. Queue overflow, dropped packets, a prolonged outage or a YouTube session that no longer accepts data can still cause gaps or a stopped stream.
What should I redact when asking for help?
Remove the stream key, credentials and private URLs. Keep the codec, resolution, bitrate, protocol type, timestamps and the lines immediately before and after the first failure, then include the matching YouTube Live Control Room message if available.