To keep an FFmpeg YouTube stream running after a process exits, run FFmpeg as the container’s foreground process and configure a Docker restart policy. That can relaunch the container after a qualifying exit; it does not repair the cause of the exit or guarantee an uninterrupted broadcast.
There are two separate recovery layers to understand: Docker can restart a stopped process, while FFmpeg has output options that may help recover from some temporary network failures. You still need to test the complete path from media input to YouTube and watch the platform’s stream health.
Keep FFmpeg in the foreground
A container is easiest to supervise when its main process is the work you intend to run. In this setup, that process is FFmpeg. When FFmpeg runs in the foreground, Docker can observe whether it is still running and record its output; if it exits, a configured restart policy can act on that exit.
Avoid starting FFmpeg in the background and leaving a shell, script, or unrelated process as the container’s main process. If that main process remains alive after FFmpeg has stopped, Docker may see a running container even though there is no stream. If the wrapper exits first, it can also obscure which process failed. Keep the process chain simple and make its logs available to you.
Docker’s guidance recommends restart policies rather than using a process manager to start containers. Read the current Docker restart policy documentation before choosing a policy, especially if you need to distinguish a deliberate stop from an unexpected exit. A policy is a response to process state, not a diagnosis.
Before building the container, decide what it will read and how you will check it. A local file needs to be visible inside the container, usually by mounting the relevant host directory and referring to the file at its container path. A network source needs its own reachable URL and credentials, if any. Check file permissions and paths from the container’s point of view rather than assuming that a path on the host exists unchanged inside it.
Connect media input to YouTube RTMPS
The stream path is input, then FFmpeg, then YouTube Live ingestion. Docker packages and runs FFmpeg; it does not choose the correct source, encode settings, or YouTube destination for you. Those depend on the media and the output you intend to send.
Get the current RTMPS URL and stream key in YouTube Live Control Room. YouTube says to use RTMPS, its secure extension to RTMP, and explains where to reveal and copy the RTMPS URL in its RTMPS setup guidance. Do not put a real stream key into a public Dockerfile, example, screenshot, or repository. Treat it as a credential: restrict access to it, avoid echoing it in logs, and replace it if you believe it has been exposed.
A command shape can clarify the parts without pretending there is one universal FFmpeg command:
ffmpeg [input options] -i /media/programme.mp4 [encoding or stream-copy options] \
-f flv "rtmps://YOUR-INGEST-URL/YOUR-STREAM-KEY"
This is a template, not a ready-to-run configuration. Substitute the RTMPS URL and key supplied for your YouTube broadcast, and verify which output format and options your installed FFmpeg build supports. Avoid sharing the substituted command if it reveals the key. Depending on how you pass credentials, inspect the container’s configuration and logs to make sure they are not exposed to people who should not have access.
Whether you can stream-copy or must decode and re-encode depends on the input streams and the output you need. Copying avoids an encoding step, but it is only suitable when the source streams are acceptable for the destination. Re-encoding gives you control over codec, bitrate and frame properties, at the cost of processing work and additional failure points. Check the codecs and properties of your actual media and the encoder support in your FFmpeg build before settling on options.
YouTube’s current encoder settings and bitrate guidance lists H.264, H.265 (HEVC) and AV1 as video codec choices for RTMP/RTMPS, along with CBR guidance and a recommended keyframe frequency of two seconds, not over four seconds. Its bitrate recommendations differ by codec, resolution and frame rate; use the current table rather than copying a setting from a different source or stream. These are platform recommendations, not a promise that a particular connection, encoder or container will perform reliably.
If you are choosing settings for an FFmpeg broadcast, the practical CBR bitrate checklist for FFmpeg can help you think through output constraints. Remove the space after the opening parenthesis in that markdown link when publishing: the intended URL is /blog/cbr-bitrate-settings-for-ffmpeg-youtube-live-streaming.
Choose a Docker restart policy
Docker provides several restart policies. The choice is about what Docker should do after the container exits and, in some cases, whether a manual stop should remain in effect. It is not an instruction to retry forever until the underlying problem disappears.
| Policy | Behaviour to consider | When it may fit |
|---|---|---|
no |
Do not automatically restart the container. | You want to inspect and relaunch it yourself. |
on-failure |
Restart after a non-zero exit; an optional retry limit can cap attempts. | You want retries for failures, but not every exit. |
always |
Restart after an exit, subject to Docker’s handling of manual stops and daemon restarts. | You want Docker to bring the container back after it stops, and have considered intentional stops. |
unless-stopped |
Restart after an exit unless you have deliberately stopped the container. | You want it to return after daemon restarts while preserving an intentional stop. |
Read Docker’s current policy behaviour carefully before choosing: the details matter when you stop a stream for maintenance or restart the Docker daemon. A retry limit, where supported, can prevent endless immediate retries, but it does not identify a bad file, expired or incorrect key, or unavailable network. If the container repeatedly exits, use its logs and exit status to investigate rather than treating repeated starts as recovery.
In a Compose service, set the restart policy in the service configuration. Do not mistake docker compose restart for applying edits to that configuration: Docker’s Compose restart command reference notes that restarting services does not reflect changes made in the Compose file. After changing configuration, use the appropriate Compose operation to recreate or update the service, following the current Compose documentation and your deployment needs.
A deliberate stop deserves particular thought. If you stop the stream to change the media, a policy that brings it back may work against your intention. Test the policy by observing what happens after an ordinary process exit and after a deliberate stop, and document how you will stop or start the service when working on it.
Separate container restarts from output recovery
Docker restart policy and FFmpeg output recovery operate at different layers. Docker reacts when the container’s main process exits. FFmpeg’s FIFO muxer has options intended to attempt recovery after an output failure while FFmpeg remains running. One can relaunch a process; the other can attempt to resume output without first relying on a container exit.
| Mechanism | Trigger | What it attempts | What it cannot promise |
|---|---|---|---|
| Docker restart policy | Container process exits, subject to the selected policy. | Start the container again. | Repair invalid media, credentials, incompatible streams or a continuing network fault. |
| FFmpeg FIFO output recovery | An output failure handled by the configured FIFO muxer. | Attempt in-process recovery after some output interruptions. | Recover from every permanent error or ensure YouTube receives an uninterrupted stream. |
FFmpeg documents options such as attempt_recovery and recovery_wait_time for its FIFO muxer and includes an RTMP example in its protocol documentation. The example is a starting point for understanding the mechanism, not a command to copy blindly for every RTMPS destination or media source. Confirm how your FFmpeg version handles the selected output and options, and test with the same kind of input and network conditions you expect to use.
Recovery settings can also change what happens to data during an interruption. FIFO overflow handling, for example, involves trade-offs around packets and continuity. Decide whether an output recovery attempt suits your content and tolerance for gaps or dropped data. A devotional audio stream, a live news loop and a visual ambience feed may not have the same practical tolerance for a discontinuity.
Do not assume the layers will neatly hand off in every situation. If FFmpeg keeps running but output is unusable, Docker may have no process exit to react to. If FFmpeg exits due to a permanent fault, an output-level recovery option cannot help once that process is gone. Check both FFmpeg’s own messages and Docker’s container state.
Test the complete stream before relying on it
A container that starts successfully has only passed an early check. Test the entire route: the container can read the chosen media, FFmpeg can produce the intended output, YouTube receives it, and the picture and sound are acceptable in the actual live preview. Leave enough time to notice failures that appear after startup, such as a file ending, a bad loop boundary, or output that stops progressing.
Use a non-public or otherwise suitable test setup where available, and avoid exposing the stream key while testing. Confirm that the container sees the expected file and that the FFmpeg command refers to the correct path. Check the container logs for input errors, missing codecs, permission problems and output connection messages. Then inspect YouTube Live Control Room rather than relying only on a running container or a successful initial connection.
YouTube recommends testing with audio and video movement similar to the planned stream and monitoring stream health and messages during the event. That matters for a static-image devotional stream as well: test the actual audio, image and duration behaviour, not only a short synthetic clip. If you are preparing recorded bhajans, the practical considerations in setting up a Hindi bhajan stream from recorded videos are relevant to the media side of the same workflow.
Test failure handling deliberately, but do it in a controlled window. You can confirm what the container does after FFmpeg exits and whether the selected policy starts it again. Do not simulate a key failure or interrupt a production broadcast casually: a test that causes a stream to fail is useful only if you can see the result, restore the intended configuration and confirm that the platform receives output again.
For a stream intended to run overnight, observe an extended test that includes the transitions that matter to your content. For a looping file, check what happens at the loop boundary; for a single file, know whether FFmpeg exits at the end. If you need a playlist or folder workflow rather than one input file, compare the continuous folder-to-YouTube approach and test its own end-of-file and ordering behaviour.
Monitor YouTube stream health
Monitoring should answer two different questions: is the FFmpeg process running, and is YouTube receiving a healthy stream? Docker status and logs help with the first. YouTube Live Control Room’s preview, stream health and messages help with the second. A container marked “up” is not proof that the right video and audio are reaching viewers.
Check the stream’s actual picture, sound, and connection state in YouTube’s interface. Look for platform messages about missing or unsuitable input and compare them with FFmpeg’s output. If the preview freezes while the container remains active, investigate FFmpeg’s input and output path rather than waiting for a restart policy that may never trigger. If FFmpeg exits and Docker relaunches it, verify the stream again; a new process is not evidence that the problem is fixed.
Decide how you will learn about a failure when you are away from the machine. A useful alert should reach a person through a channel they check, contain enough context to distinguish a stopped container from unhealthy YouTube input, and avoid leaking secrets. The guide to alerts for a 24/7 stream covers the operational side. Whatever tools you use, test the alert route rather than assuming that a configured notification will arrive.
Keep a brief record of changes and symptoms: when the stream stopped, what FFmpeg logged, whether Docker restarted the container, and what Live Control Room reported. This makes it easier to tell a one-off exit from a recurring fault. Do not post logs publicly without checking for stream keys, private file paths or other credentials.
Diagnose faults that restarts cannot fix
If FFmpeg exits repeatedly, first establish why. A missing or unreadable input, an invalid command option, an unavailable codec, a malformed stream key, a changed YouTube destination, or a media format the output cannot handle may fail again each time the container starts. Restarting replays the same setup; it does not alter it.
If the process stays up but the stream drops or becomes unhealthy, look for an output or network problem. Confirm that the RTMPS URL and key are current, the container can reach the destination, and the network is not continuing to fail. A restart can sometimes coincide with a temporary recovery, but it cannot remove a continuing network fault. Likewise, adding FIFO recovery options is not a remedy for a permanent authentication or input error.
Check the source media separately from the output. Probe the file and verify its streams, duration, and playback in the intended loop. If you re-encode, confirm that the chosen encoder exists in the build and that the target settings are supported. If you stream-copy, confirm that the input’s existing codecs and properties are suitable for the destination. YouTube’s current encoder guidance should be checked alongside the capabilities of your own FFmpeg build and available upload capacity.
For a persistent problem, stop the restart loop long enough to inspect it. Preserve the relevant logs, correct one likely cause at a time, then test again from the input through YouTube. A repeated restart without inspection can make a fault look like a succession of brief recoveries, while the stream remains unavailable or unhealthy.
If maintaining a host, container, credentials and monitoring is more operational work than you want, StreamNeo can remove the need to keep your own computer running for this file-to-YouTube workflow. That does not change the need to select media you can use, protect your channel credentials and confirm the resulting stream in YouTube.
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 keep FFmpeg streaming to YouTube after a crash?
Run FFmpeg as the container’s foreground process and choose a Docker restart policy that fits your stop and recovery behaviour. Then inspect logs and verify in YouTube that the stream returns; a restart can relaunch the process but does not fix the cause of a crash.
How do I restart a Docker container automatically?
Configure a restart policy such as on-failure, always or unless-stopped in the container or Compose service, after checking Docker’s current descriptions of their behaviour. Test both an unexpected process exit and the deliberate-stop behaviour you expect, and remember that Compose configuration changes need to be applied rather than merely issuing a restart command.
Does Docker restart fix an RTMP or RTMPS disconnect?
Not by itself. Docker reacts to container exits, while FFmpeg’s FIFO muxer has separate options that may attempt in-process output recovery after some failures. Neither mechanism guarantees recovery from a continuing network problem or every permanent error.
Where do I get the YouTube RTMPS URL and stream key?
Get them from YouTube Live Control Room for the stream you are setting up, and use the RTMPS URL rather than assuming the default RTMP address is the one you need. Keep the stream key private and check YouTube’s current instructions if the interface or setup changes.