If FFmpeg is still running when its output connection fails, the FIFO muxer can keep realtime processing going and retry the output. It does not restart an FFmpeg process that has exited, and it does not establish that YouTube will resume the same live session after a separate restart.
The practical task is to identify which failure you have, configure the documented FIFO pattern for the first kind, and test it without treating a retry as proof of uninterrupted playback. Keep process supervision and YouTube event behaviour as separate questions.
First check whether FFmpeg is still running
Before changing flags, find out what has actually failed. “The stream disconnected” can mean that the local FFmpeg process stopped, FFmpeg is alive but cannot write to its output, or the publisher is sending data while YouTube reports a problem with the event. Those cases look similar from a viewer’s perspective, but need different responses.
Check the machine or service that launched FFmpeg. If the process has exited, FIFO output recovery cannot help: there is no running process left to retry the output. You need to investigate why it exited and, if appropriate, arrange a separate way to launch it again. If the process is still present, inspect its recent log output for messages about the output, connection, retries or a fatal error. A running process is useful evidence, but it does not by itself prove that it is sending usable video to YouTube.
Next check YouTube Live Control Room and the stream health indicators. They can help distinguish a problem at the publisher from an ingest or event issue, but do not assume that a green local process indicator means viewers see continuous video. If the event itself has ended or changed state, a publisher-side retry may not restore it as the same event.
For a small team, record the distinction in a short runbook: process present or absent, last relevant FFmpeg log lines, YouTube event status, and what action was taken. This is more useful at 03:00 than a generic instruction to “restart the stream”. A guide to checking YouTube live-stream health metrics can help you interpret the platform-side symptoms alongside FFmpeg’s own logs.
What FIFO recovery is meant to handle
FFmpeg’s FIFO muxer documentation describes a particular situation: realtime processing continues while the output has a temporary failure, such as a network outage, and the muxer attempts to recover the stream. The documented example enables recovery attempts and sets a wait between them. Its stated pattern retries every second indefinitely. That is a description of the example, not a promise that every build, input, network failure or YouTube event will behave identically.
The distinction is important. With this mechanism, FFmpeg is still processing the input; FIFO concerns the path from that processing to the output. If the process crashes, is killed, or exits because of another error, FIFO has no opportunity to retry. A process supervisor is a separate operational layer, and the documentation cited here does not prescribe one.
There is another boundary after the output path. Even if FFmpeg manages to reconnect, you still need to know whether YouTube accepts the publisher again for the event you intended to run. A successful local retry and a resumed viewer experience are not interchangeable claims. You should test the behaviour with your own event and current YouTube controls rather than assume the example answers it.
Read the FFmpeg FIFO muxer documentation as the source for the recovery options and example. Use it to understand what the muxer is intended to do, not as evidence that the command has been tested against your specific encoder, network, stream key and live event.
Adapt the documented FLV FIFO example
The official example is a useful skeleton, but not a production-ready command for every source. In simplified form, it 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 RTMPS_DESTINATION
Treat INPUT and RTMPS_DESTINATION as placeholders. The -re flag appears in the documented example; retain or change input pacing according to your real source and workflow. The example uses H.264 video and AAC audio, but your source may have no audio, multiple audio tracks, or already-encoded streams. The maps -map 0:v -map 0:a are not a universal fit either: they select video and audio streams from the input, and can fail or select more than you intend if the input differs.
For a 4K 60fps output, your normal input and encoding configuration still has to produce the desired picture size and frame rate. FIFO does not upscale, create 60 frames per second, improve encoding quality, or make an underpowered machine encode faster. It changes how the output is handled when there is temporary trouble; preserve the encoder choices and output requirements you have already validated.
The documented output format is FLV inside the FIFO muxer. Keep the format relationship intact when adapting the pattern: -f fifo selects the FIFO muxer, and -fifo_format flv specifies the underlying output format. Do not copy only the recovery flags into an unrelated output configuration and assume they are equivalent. Consult the documentation for the exact FFmpeg build you run, especially if you use options not present in the example.
YouTube’s current encoder guidance should inform the stream you intend to publish, independently of FIFO. The consulted YouTube live encoder settings recommend H.264 at 35 Mbps for 4K/2160p at 60fps, constant bitrate encoding, a two-second keyframe interval (not exceeding four seconds), and RTMPS. Recommendations and accepted settings can change, so confirm the current page and Live Control Room before deployment. Do not interpret a recommended bitrate as a guarantee that your connection can sustain it.
Set recovery and overflow options with care
The key recovery switch in the example is -attempt_recovery 1. The accompanying -recovery_wait_time 1 sets the interval between attempts in that example. A short retry interval can reduce the time before another attempt, but it does not repair a broken route, restore a dead process, or guarantee that the receiving event is ready. For an overnight channel, repeated retries may be preferable to stopping at the first short outage, but the logs still need to be observable by someone or something that can act on a persistent failure.
The example also uses -drop_pkts_on_overflow 1. Packet dropping is a trade-off rather than a free recovery improvement. If the FIFO queue overflows, dropping packets can help prevent an accumulating backlog from turning into rising latency. The cost is that the output may have discontinuities or missing data. For a music visualiser, a brief imperfection may be preferable to the stream falling further behind; for a news loop where captions and audio must remain aligned, you should assess the consequences against your actual programme.
Do not tune the options by guessing at a queue size or retry count not established by the cited example. First establish whether the failure is temporary output trouble and whether FFmpeg remains alive. Then run a controlled test and look at the FFmpeg logs, the YouTube status, and what a viewer actually receives. If you change options, change one meaningful thing at a time so that a result can be attributed to it.
There is a difference between “the output recovered” and “the stream was gapless”. An outage can mean missing packets, a visible freeze, a reconnect indication, or a discontinuity even when later output resumes. Describe what you observe rather than calling a retry successful solely because the process continued running.
Map your input and YouTube destination
Substitute the actual media input and stream destination, then check stream selection before testing recovery. For a file-based channel, verify that FFmpeg can read and pace the file as intended and that the selected video and audio tracks exist. For a live or changing source, verify its own reconnect and timing behaviour separately; FIFO output recovery does not define how an input source reconnects.
Use the current RTMPS ingestion destination and stream key shown for your YouTube live setup. Google’s RTMPS ingestion guide documents delivery of live data to YouTube using RTMPS. Keep the key private: avoid pasting it into a public post, screenshot, shared log, or shell history that other users can read. If a key has been exposed, follow YouTube’s current controls for replacing it; the stream-key replacement checklist is relevant when updating an always-on publisher.
RTMPS is the choice to validate against YouTube’s current guidance, not a reason to assume an arbitrary RTMP endpoint will accept the same connection. Confirm that the destination and key correspond to the event you mean to run. If you switch keys or events during testing, note exactly which one is active; otherwise, a successful connection can be mistaken for recovery of the original session.
Keep the operational details separate from the command you share with others. A redacted command can show the option order and maps, but must not reveal a real stream key. If you are publishing a pre-recorded programme such as a podcast or devotional loop, make sure the file path and stream selection are equally clear; an FFmpeg workflow for sending podcast MP3 files to YouTube Live offers useful context for the media side, not proof of FIFO recovery.
Compare the failure layers
A useful operating plan says which layer it covers and what remains unverified. These options are complementary rather than substitutes for one another.
| Failure or action | What it addresses | What it does not establish |
|---|---|---|
| FIFO output recovery | Temporary trouble writing the output while FFmpeg continues processing | Restart of an exited FFmpeg process, gapless playback, or YouTube resuming the same event |
| Separate process supervision | Launching or managing an FFmpeg process that has exited, according to the supervisor you configure | Acceptance of a restarted publisher by the existing YouTube event |
| YouTube event checks | Whether the event and ingest status are in the state you expect | That FFmpeg will remain alive or reconnect on its own |
| Network and power resilience | Reducing exposure to some causes of interruption | Recovery behaviour for a failure that still occurs |
This table is deliberately cautious: the cited FFmpeg source supports the first row’s intended function, while the details of a supervisor and the platform’s response to a restarted publisher depend on your setup and must be tested. A local UPS, a more stable connection or a second route may reduce the chance of interruption, but none substitutes for knowing how your process and event behave when an interruption happens.
For a 24/7 channel, write down a recovery sequence with separate branches. If FFmpeg remains alive, check its output errors and allow the configured retry mechanism to operate while monitoring the event. If FFmpeg has exited, diagnose the exit and use your separately configured restart procedure if one exists. After any publisher restart, inspect the YouTube event rather than assuming it resumed. A concise runbook can also note who receives alerts, how to access logs, and how to avoid exposing credentials.
A managed workflow can remove one particular burden: keeping your own computer on as the publisher. StreamNeo turns an uploaded video into a YouTube live stream that runs with your computer off, so there is no local FFmpeg process for you to keep open; that is a different workflow from configuring FFmpeg FIFO recovery and does not change what YouTube event behaviour you should verify.
Test without assuming a restart or resumed session
Start with a controlled test, not the channel’s most important overnight slot. Confirm a normal baseline first: the input is correct, the stream reaches the intended YouTube event, picture and sound are present, and the 4K 60fps encoding configuration behaves as expected. Save a redacted copy of the command and note the FFmpeg version and relevant log messages so you can repeat the test.
Then test a temporary output interruption only in a way you can safely control. Observe whether FFmpeg remains running, whether the FIFO reports recovery attempts, whether output resumes, and what YouTube reports. Check playback from a viewer’s perspective as well. The result may include a visible interruption; record that rather than labelling it seamless. Do not deliberately interrupt a production stream if the consequence would be unacceptable to your audience.
Test process exit as a different scenario. A controlled stop or a test process that exits can show you what your supervisor does, if you have configured one. It cannot, on its own, answer whether YouTube will resume the same event after a newly started publisher. Check the event behaviour separately in an appropriate test setup and consult current official guidance. Do not let the FIFO example stand in for that test.
Finally, test a longer run under the conditions that matter: the actual source, encoder settings, network route and destination. A brief successful retry establishes only that the tested case worked at that time. It does not prove every overnight failure mode is covered. If the channel is unattended, ensure that persistent failures surface through logs or alerts and that a person knows the next step.
When to use another workflow
FFmpeg with FIFO output recovery makes sense when you want direct control of encoding and already have someone responsible for the machine, source, logs, credentials and separate process management. That control has a cost: you are responsible for the moving parts. A one-file loop on a dedicated computer, for example, still depends on that computer and its environment staying available.
If you do not need a custom live input or encoding pipeline, a simpler file-to-live workflow may be easier to operate. Conversely, if you need dynamic graphics, live mixing, several changing sources or detailed encoder control, a managed file broadcaster may not fit your needs. Choose based on the actual programme and on who will respond when something fails, not on the word “recovery” in a feature description.
Whichever workflow you use, retain the same distinctions: a publisher process can be alive or dead, its output can be failing or flowing, and the platform event can be accepting or not accepting the feed. Keep the stream key secure, verify current YouTube settings, and make your test plan cover each boundary you depend on.
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
How do I make FFmpeg reconnect to YouTube after a disconnect?
Enable FIFO output recovery for temporary output failures while FFmpeg remains running, following the FFmpeg muxer documentation and adapting its FLV example. Check logs and YouTube status to see what happened in your case; the example does not establish recovery after the process exits or resumption of the same YouTube event.
What bitrate should I use for YouTube 4K 60fps live?
The consulted YouTube guidance recommends 35 Mbps for H.264 at 4K/2160p and 60fps. It also recommends constant bitrate encoding and a two-second keyframe interval, not exceeding four seconds; recheck the current official guidance and your Live Control Room settings before publishing.
Will FIFO recovery restart FFmpeg if it crashes?
No. FIFO recovery addresses temporary output trouble while FFmpeg is still processing, not an exited process. A separate supervisor can manage process restarts, but you must configure and test it independently.
Should I use RTMP or RTMPS?
YouTube’s consulted guidance recommends RTMPS, and Google documents RTMPS ingestion for live data. Confirm the current endpoint and stream key in YouTube’s controls, and keep the key private.