If your 4K 60fps YouTube Live stream stops, first find out whether FFmpeg is still running but unable to send output, or whether the FFmpeg process has exited or stopped making progress. FFmpeg’s FIFO recovery can retry some temporary output failures; restarting a dead or wedged process requires a separate supervisor.
That distinction matters because the wrong remedy leaves the stream down. Use FFmpeg’s output recovery for a live process facing a transient connection problem, and use an operating-system or deployment-level supervisor for process failure. Then verify the recovered feed in YouTube Live Control Room before relying on the setup overnight.
Classify the failure before changing anything
Start by checking the process, not by restarting it blindly. If FFmpeg has exited, the issue is a process failure: look for an error near the end of its log, such as an invalid argument, an input read problem or an output error followed by termination. If it is still running, determine whether it is actively processing frames and whether the output is advancing, rather than assuming that a visible process is a healthy stream.
There are three useful cases to distinguish:
| What you observe | Likely failure class | Recovery layer to investigate |
|---|---|---|
| FFmpeg is active and logging continued frame progress, but RTMP output reports a temporary connection problem | Output or network interruption | FFmpeg FIFO output recovery, if supported by your build |
| FFmpeg process has exited | Process failure | An external supervisor that starts the command again |
| Process remains present but logs and output stop advancing | Possible hang or stall | A supervisor with a suitable progress or health check, not only exit detection |
A process listing alone can be misleading: a wedged process may remain visible without doing useful work. Compare the last log timestamps, frame counters and YouTube’s stream health messages. A home connection dropping briefly is not the same failure as FFmpeg exiting after an input file error, even if both appear to viewers as a frozen stream.
Record what happened before intervening. Capture the last relevant FFmpeg messages, the process state and the Live Control Room status. That evidence helps you decide whether to change output recovery, process supervision or the underlying encoder configuration. It also prevents repeated restarts from erasing the clue that explains a recurring failure.
If you are building a long-running playlist rather than sending one file, keep the content workflow separate from recovery policy. The guide to automating a YouTube playlist rotation with a Linux shell script covers the playlist side; a restart policy still needs to handle the FFmpeg process and output independently.
Use FIFO recovery for temporary output failures
FFmpeg documents a FIFO pseudo-muxer that can help with network output recovery. It sits between encoding and the final muxer, buffers packets and can attempt to reopen a failed output while FFmpeg continues processing. This is useful only when the process remains alive and the fault is in the output path; it is not a general restart facility.
The FFmpeg manual includes this illustrative RTMP example:
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://example.com/live/stream_name
This is an example of FIFO options, not a tested YouTube command. Replace the input, maps, codec choices, destination and stream credentials with your actual setup. YouTube’s encoder workflow uses the server URL and stream key shown for your stream; treat the key as a credential and do not place it in public scripts, screenshots or logs. The FFmpeg documentation for the FIFO muxer describes the options and example.
-attempt_recovery 1 enables attempts to recover a failed output. -recovery_wait_time sets the pause before another attempt; the example explicitly uses one second, while the manual documents a default of five seconds. Choose a delay you can test against your connection and stream behaviour rather than copying a value on faith. The manual also documents max_recovery_attempts as unlimited when set to its default of zero. Unlimited retries may suit a genuinely temporary network interruption, but they can also leave an impaired stream waiting indefinitely if the endpoint or configuration is wrong.
-drop_pkts_on_overflow 1 allows packets to be dropped instead of blocking the encoder when the FIFO queue fills. That choice favours continued processing over preserving every queued packet. Viewers may miss content during an interruption; dropping packets does not repair a weak uplink, restore a lost key or guarantee that YouTube will accept the returning stream.
The FIFO options and their availability can vary with the FFmpeg version or build. Before using them, check the installed muxer help with ffmpeg -h muxer=fifo and compare it with the documentation for that version. Test with a non-critical broadcast or a controlled stream. Do not assume an option is active because it was accepted in a different machine’s command.
What FIFO recovery cannot restart
FIFO recovery operates inside FFmpeg. If FFmpeg exits, its FIFO muxer no longer exists to retry the output. If the process is alive but wedged, output recovery does not necessarily detect that no useful progress is happening or restart the process. Those are separate problems and need separate controls.
This is why a command that reconnects successfully during a brief network interruption may still fail overnight if the machine reboots, an input disappears or the encoder encounters a fatal error. Conversely, a supervisor that restarts a process after it exits does not necessarily repair an intermittent RTMP output while that process is still running. Each mechanism covers a different failure class.
A restart also does not mean the stream’s viewing state is identical in every situation. YouTube’s workflow for a scheduled stream includes waiting for preview and then selecting Go live. Do not assume every restart of an encoder has the same live-state behaviour for scheduled and unscheduled streams. Check the intended stream in Live Control Room and confirm the preview and status after recovery using YouTube’s encoder setup guidance.
For a dependable always-on setup, write down the failure you expect each layer to handle. For example: FIFO retry covers a short output interruption while FFmpeg remains active; the supervisor restarts on exit; a separate progress check flags a process that is present but no longer advancing. If you need a broader view of the trade-offs between local and hosted approaches, see YouTube 24/7 streaming service vs OBS for Indian creators.
Configure a supervisor for process failure
A supervisor starts FFmpeg, observes its exit and applies a deliberate restart policy. The exact configuration depends on where the command runs: Linux systemd, Windows service or task tooling, macOS launchd, a container orchestrator or another runtime. There is no single safe configuration to paste in without knowing the operating system, service account, command, file locations and expected restart behaviour.
At minimum, decide these points before enabling automatic restarts:
- What counts as failure? Most basic supervisors can detect process exit. If you also need to catch a process that stays alive but stalls, specify what progress signal or health check will identify it.
- When should it restart? Choose a delay and a backoff policy so a bad command does not create a rapid restart loop. A process that exits immediately on every attempt should be investigated, not restarted repeatedly without limit.
- How many attempts are appropriate? Consider whether repeated failures should trigger an alert or a pause for human diagnosis. No one retry limit suits every input and deployment.
- Where do diagnostics go? Retain FFmpeg output and the supervisor’s restart events with timestamps. Protect the stream key if a command or error message could contain it.
- What happens after a host restart? Set a clear start policy and confirm that required media, credentials and network access are available before FFmpeg launches.
A short shell loop can restart FFmpeg when it exits, but it can spin rapidly if the command has a persistent error, and it normally cannot tell an active process from a stalled one. If you use one for a temporary test, include a pause, preserve exit details and stop it after the test. For ongoing use, an operating-system or deployment supervisor with a documented restart policy and logs is easier to inspect.
Keep the supervisor’s job narrow. It should launch the intended command and record its status; FFmpeg’s FIFO options can separately address eligible output failures. Avoid launching multiple copies after a restart or leaving an old process attached to the same stream. A service definition should have one clear owner for the FFmpeg process, and you should verify that a manual restart does not leave a duplicate encoder running.
If the workload is a fixed video playlist, the content loop and the process restart policy should be tested together but remain understandable as separate pieces. The article on streaming a pre-recorded playlist on YouTube 24/7 using a cloud platform explains a different operating model; it does not remove the need to verify what happens when an encoder stops.
Test recovery with the real 4K60 command
A 4K60 command needs to be checked as an encoder configuration as well as a recovery configuration. YouTube’s current encoder-settings page lists H.264 at 2160p60 with a 14 Mbps minimum and 50 Mbps recommended bitrate. For AV1 or H.265, it lists 10 Mbps minimum and 35 Mbps recommended. These are YouTube’s published ingest settings, not a promise that your computer can encode continuously or that your connection can sustain the upload.
YouTube lists CBR, up to 60 fps and a recommended two-second keyframe interval, with a maximum interval of four seconds. At an actual output rate of 60 frames per second, a two-second GOP corresponds to 120 frames, so an encoder option such as -g 120 is only appropriate if the output is indeed 60 fps. Confirm resolution, frame rate, codec, rate control and keyframe interval from the command and output rather than copying a value from a 30-fps example. See YouTube’s live encoder settings for the current values and check that page again before a planned broadcast.
Run a controlled test that exercises both recovery layers separately. First, with a non-critical stream, interrupt or simulate the output path in a way you can safely reverse and observe whether FFmpeg remains active and the FIFO attempts recovery. Then test a process exit and confirm that the supervisor starts a single replacement process after its configured delay. If a stalled process is in scope, test the health check independently; an exit-only restart policy will not prove stall detection.
Use representative content and audio. A static image may conceal a frame-rate or bitrate problem that becomes visible with motion. Confirm that the outgoing feed is 3840×2160 at 60 fps if that is what you intend, and that the chosen codec and bitrate fit YouTube’s published settings and your sustained upload capacity. A short successful preview is useful evidence, but it cannot demonstrate that every possible failure will recover.
Before testing, decide what success looks like: process status, continued FFmpeg progress, a returning preview, stream health messages and audible, visible output. Keep the stream key out of shared test notes. If you are not yet committed to a local encoder workflow, compare its day-to-day requirements with other approaches in OBS vs FFmpeg for scheduling playlist rotations on YouTube Live.
Monitor logs and confirm YouTube returns
Logs tell you what FFmpeg and the supervisor observed; YouTube tells you whether the intended live stream is receiving an acceptable feed. Keep both views available during testing. Note the time of an interruption, the last frame or progress message, any output retry message, whether the process remained alive and when a new process was started. These details help separate a recoverable output event from an encoder or input problem.
After recovery, inspect the expected stream in Live Control Room. Confirm that the preview returns, the stream health status and messages are reasonable, and the picture and sound continue. If the preview does not return, check the selected server URL and stream key, the actual output format, and whether the scheduled stream workflow requires an explicit action. Restarting FFmpeg is not proof that YouTube has resumed the broadcast.
Monitor for repeated retries, repeated process exits and rising restart frequency. A system that eventually reconnects after repeated failures may still be unsuitable for unattended operation. Look for a repeated cause in the logs, such as a missing input, invalid option, exhausted disk space or a persistent network issue. Fix the cause rather than widening restart limits until the symptoms disappear.
For a channel that must run through the night, make a short written runbook: how to check the process, where the logs are, how to confirm the YouTube stream, and how to stop the supervisor without creating duplicate encoders. Keep the stream key access restricted and have a manual recovery path available. After any FFmpeg, operating-system or stream configuration change, repeat the controlled test before leaving the channel unattended.
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 FFmpeg FIFO recovery restart FFmpeg after it exits?
No. FIFO recovery can attempt to reopen an output while FFmpeg is still running. If the process exits, an external supervisor must start it again.
Will FIFO recovery fix a frozen stream if FFmpeg is still listed as running?
Not necessarily. A process can be present but stalled, and output retry options do not by themselves prove that frames are advancing. Check logs and progress, then use an appropriate health check if you need to detect a hung process.
Which bitrate should I use for 4K60 YouTube Live?
YouTube’s current settings list H.264 at 14 Mbps minimum and 50 Mbps recommended, or AV1/H.265 at 10 Mbps minimum and 35 Mbps recommended. Treat these as published ingest settings, then test the actual encoder and upload connection with representative content.
How do I know the stream has returned after a restart?
Check the expected stream’s preview, health status and messages in Live Control Room, and verify that picture and sound continue. A supervisor reporting that FFmpeg started again is not enough to confirm that YouTube is receiving the intended stream.