A packet-write error means FFmpeg failed while writing output packets, but it does not by itself explain why. To diagnose a stalled YouTube live stream, match the timestamp and surrounding FFmpeg log against YouTube Live Control Room’s stream-health messages, then compare what the encoder and any local recording show.
Do not treat “Broken pipe” as a diagnosis or change several settings at once. The same kind of output failure can appear in different contexts, so the command, protocol, full log and YouTube evidence matter before you name a cause.
What the packet-write error establishes
FFmpeg processes media and writes the resulting packets to an output. A packet-write error establishes that an output write failed. It locates the failure at the point where FFmpeg was trying to hand data to its destination; it does not tell you what made that write fail.
The wording around the error is useful evidence. For example, av_interleaved_write_frame(): Broken pipe says that a write operation failed with a broken-pipe condition. A message while writing a trailer is different in timing from one that appears during ordinary packet output. Neither detail, alone, establishes whether the problem began in the source, encoder, connection, ingest configuration or remote end.
That distinction matters when a 24/7 stream appears to freeze. The visible stall may begin before FFmpeg reports an error, or the report may be the first indication that a write could not continue. Record what the viewer saw and when, but keep it separate from what the log proves. A useful report says, for example, “the player stopped changing at this time; FFmpeg logged this write error at this time”, rather than claiming the two are necessarily the same failure.
A packet-write message may also be a consequence rather than the first fault. Look earlier in the log for connection, timeout, handshake, input-read or timestamp messages. The first relevant warning can help narrow the sequence; the final write error tells you where the failure surfaced. FFmpeg-user mailing-list reports show similar text in more than one output context, including RTMP and pipe-related discussions. They are examples of the message, not universal explanations for your stream.
What the error does not establish
The error does not prove that YouTube has rejected the stream, that a stream key is wrong, that a particular protocol is misconfigured, or that your internet connection failed. It also does not prove that your computer ran out of capacity or that YouTube itself had an incident. Those are possibilities to test only when the rest of the evidence points towards them.
It cannot identify a root cause without context. The exact FFmpeg command, output URL with secrets removed, protocol, full stderr log, encoder preview and YouTube stream-health report all affect the interpretation. A single line copied from a long run cannot show whether there was an earlier disconnection or whether the error occurred only during shutdown.
Community reports are especially easy to overread. One person’s “Broken pipe” may follow a remote close; another report may involve a local pipe or a different output path. The reports demonstrate that the wording occurs in varied situations, not that every YouTube stall has the same cause. Do not apply an anecdote as a fix unless your own evidence supports the same condition.
Likewise, a healthy encoder preview is useful but not conclusive. It suggests that the source and local rendering may still be working, which shifts attention towards what happens after the preview. It does not prove that the outbound connection is faulty. YouTube’s live-stream troubleshooting guidance treats connection testing as a next step where appropriate, not as a conclusion drawn from one FFmpeg line.
Capture the timestamp and surrounding FFmpeg log
Start by preserving the evidence before restarting or editing the command. Save the complete FFmpeg stderr output, including the lines before and after the packet-write error. Note the system time and time zone, the time shown in the log, when the viewer noticed the stall and whether the error occurs during packet writing or while FFmpeg writes the trailer.
Record the FFmpeg version and build, the input type, output protocol and the relevant command options. You do not need to publish credentials or the full destination URL. If you share a log, remove the stream key and other tokens first; a URL can contain a credential even when it looks like ordinary configuration.
Keep the original log unchanged, then make a short working copy with the important lines and timestamps. If stderr is not already being saved, arrange logging for the next test run rather than relying on a terminal window that may close. Preserve enough surrounding output to see whether a connect, reconnect, timeout or input problem preceded the failure. Do not reduce the record to the final line alone.
A simple incident note can keep the facts distinct:
| Evidence to record | What it helps you compare |
|---|---|
| FFmpeg timestamp and full surrounding stderr | Whether another message came before the write failure |
| Exact output protocol and non-secret command options | Whether the behaviour is specific to an output path or configuration |
| YouTube Live Control Room message and timestamp | Whether YouTube reported an ingest or stream-health issue at the same time |
| Encoder preview and local archive | Whether the source and local output continued to look normal |
| Viewer-facing stall time | Whether the visible interruption aligns with the technical evidence |
A local archive can be useful even if it is not a perfect copy of the live output. If it contains the same frozen frame or missing audio as the encoder preview, inspect the source and local encoding path. If it remains normal while the remote stream stalls, that difference helps direct attention to the output path, but still does not isolate a network, endpoint or service cause by itself.
Check YouTube Live Control Room stream health
Open the stream’s Live Control Room and inspect the stream-health indicator and any detailed status message for the relevant period. YouTube’s live-stream error messages describe the checks and messages shown there. Use the dashboard’s wording as evidence from the ingest side, rather than inferring YouTube’s condition from FFmpeg’s output line.
Match the dashboard message to the FFmpeg timeline as closely as the available timestamps allow. If both show a problem at about the same time, record the text of each; do not assume they identify the same underlying fault. If YouTube reports a problem before FFmpeg’s write error, that order may matter. If the dashboard remains healthy while FFmpeg reports a failure, note that too. A mismatch is evidence to investigate, not proof that one view is wrong.
YouTube categorises some reported errors by severity. Its guide describes red errors as critical and yellow errors as moderate. Treat the colour and wording as YouTube’s assessment of the stream at that point, not as a full forensic explanation. A status message can identify an ingest concern or a setting to check, while leaving open why that condition occurred.
The live stream metrics page can add context to the incident timeline. Look for the metrics and stream-status evidence available for your broadcast, and note when a change appears. A dashboard view after the event may not preserve every detail you need, so capture the message and time during the next occurrence if possible.
If the dashboard asks you to address a specific stream parameter, compare that instruction with the actual output rather than changing settings by guesswork. If it reports an encoder issue, inspect local encoder messages and the preview. If it identifies an ingest or connection concern, follow the relevant check and then see whether the evidence changes on a controlled retest.
Correlate encoder, source and ingest evidence
Put the local and remote views side by side. Check whether the encoder preview stayed in motion, whether audio continued, and whether a local archive has the same interruption. Then compare these observations with the dashboard message and FFmpeg timestamp. You are looking for a pattern across evidence, not one clue that settles the question.
YouTube notes that encoder errors, CPU load, or problems in routed audio and video sources can explain poor output. If the preview is already frozen or the archive has the same defect, examine the source, playlist and local encoding path before focusing on YouTube’s ingest. A related case is an input or playback problem in a continuous playlist; see the practical checks in why OBS stops playing videos during a 24/7 YouTube stream.
If the preview and archive are normal but the remote stream is not, outbound delivery becomes a more relevant area to test. YouTube’s troubleshooting guidance recommends testing the outbound connection and contacting your ISP if those tests reveal a problem. A normal preview shifts attention; it does not prove that the internet connection is the cause. A wired-versus-Wi-Fi comparison can be useful if both options are already available to you, but it is a diagnostic comparison, not a guaranteed fix or a reason to buy equipment first.
Also compare the parameters actually sent with the ingest configuration shown for the stream. Check the video and audio streams, codec and container, resolution, bitrate and keyframe cadence. YouTube’s encoder settings guidance recommends constant bitrate (CBR) and a two-second keyframe interval, with an interval no longer than four seconds. Select settings your upload connection can sustain; a setting that looks valid on paper can still be a poor fit for the available connection.
The bitrate and resolution checklist for a 24/7 lofi stream can help you review those choices without confusing a stream-setting mismatch with a proven explanation for a packet write failure. Check what the command is actually producing, not only what you intended to configure. A command-line option may be overridden, omitted or applied to a different stream than expected.
Test likely causes without assuming one
Once you have a baseline, change one variable at a time. Keep the command and settings stable while checking a suspect connection, then preserve the new log and dashboard evidence. If you change bitrate, protocol and encoder together, a successful retest may tell you that something changed but not which adjustment mattered.
For a connection test, compare the outbound connection at the time of a repeatable failure, and check whether the same stream behaves differently on a stable wired connection if available. YouTube advises testing connectivity and contacting the ISP when a test indicates a problem. If the test is clean, do not keep labelling the issue a network fault without further evidence. A longer run may be necessary to see whether the symptom recurs; it does not turn a single successful session into proof of a permanent fix.
For a possible capacity or encoder problem, examine the encoder’s own errors and CPU load during the stall. If those checks point to a local limit, try a lower selected resolution or bitrate that remains appropriate for the content and connection, then compare the result. YouTube also advises using the latest encoder and trying another encoder where appropriate. That is a controlled comparison, not a claim that changing encoders will cure every write error.
For configuration, compare the stream parameters with the current Live Control Room ingest settings. If the evidence points to RTMPS or a connection setup issue, check the exact RTMPS URL copied from Live Control Room and confirm that the encoder supports it. YouTube’s RTMPS instructions describe using port 443 for an SSL error. Apply that check when the log or dashboard presents relevant SSL or connection evidence; a packet-write error alone does not show that the URL, TLS or port is wrong.
You can also compare the FFmpeg output protocol and destination with a known-good configuration you control, while keeping the media input and other options steady. Avoid exposing a live stream key during that comparison. If you use a file list or repeated media, check whether the input continues correctly at the same moment; the FFmpeg file-list guide is relevant to that separate part of a continuous stream setup.
For each test, write down the single change, start and end times, whether the preview and archive remained normal, and what Live Control Room reported. Revert a test that adds a new problem. A diagnosis becomes stronger when the same evidence pattern recurs and a controlled change alters that pattern; a fix that coincides with a restart may simply coincide with a transient condition ending.
When the available evidence is inconclusive
Sometimes the stream stalls but the log is incomplete, the dashboard message has disappeared, or the local preview was not recorded. In that situation, the honest result is that the root cause remains unconfirmed. Do not turn a missing log into certainty about a stream key, ISP, encoder or YouTube service event.
Prepare the next run so it captures the evidence you need: complete timestamped stderr, the non-secret command options, FFmpeg version and build, protocol, preview or local archive, and Live Control Room stream-health message. Note the viewer-facing symptom and time separately. If you contact YouTube or your ISP, provide the relevant timestamps and redacted records rather than a stream key or unsupported diagnosis.
If you operate an always-on channel, consider whether a process that depends on your own computer staying on is itself adding a separate failure point. For example, a local machine can lose power or connectivity independently of FFmpeg’s packet-write error. StreamNeo can remove the need to keep your own computer running for the broadcast, while leaving you responsible for the video, channel and YouTube-side checks; that changes the operating arrangement, not the meaning of an error already in a log.
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
What does av_interleaved_write_frame(): Broken pipe mean?
It means FFmpeg failed while writing an output packet, with a broken-pipe condition reported at the output boundary. The line does not establish why the write failed. Read the preceding log lines and compare the timestamp with YouTube’s stream-health evidence.
Does a packet-write error prove that my internet connection dropped?
No. A connection problem is one possibility, but the same error does not rule out source, encoder, ingest-configuration, endpoint or other output issues. Compare the encoder preview, local archive, full log and Live Control Room message before narrowing the cause.
Should I change the RTMPS URL or port after seeing the error?
Not on that line alone. Check the URL, encoder support or port when the log or YouTube status points to an SSL or connection setup issue; YouTube’s RTMPS guidance discusses port 443 for an SSL error. Preserve the original command and change one relevant variable at a time.
What should I send when asking for help?
Share the timestamped log around the failure, FFmpeg version and build, protocol and redacted command options, plus the matching YouTube stream-health message and local preview or archive observations. Remove the stream key and tokens first. If one of those records is missing, say so rather than filling the gap with a guess.