A Docker container can keep FFmpeg running to send a pre-recorded children’s programme to YouTube Live, and a restart policy can bring the process back after some exits. Neither tells you whether the video is still moving, the audio is present or YouTube is receiving a healthy feed, so a dependable 24/7 operation needs monitoring and a human recovery plan as well.
The practical sequence is to prepare media you are authorised to use, verify the channel, test the complete ingest path, and decide how you will handle interruptions and archives. This guide walks through that sequence, including where a simple loop is useful and where it is not enough.
What Docker and FFmpeg each do
FFmpeg reads and encodes media, then sends the resulting audio and video to YouTube’s ingest endpoint. Docker packages the FFmpeg command and its dependencies into a container, so you can run and manage it as a service without installing the same media tools directly on the host. These are complementary jobs: FFmpeg handles the stream; Docker manages the process environment.
For a basic children’s channel, your source may be a long programme file or a playlist of short segments. FFmpeg can read a file in real time, loop it, and publish the output. A container can make the command repeatable, preserve its configuration and provide a place to inspect logs. You still need a host with reliable power and upload connectivity, correctly configured YouTube credentials, and an operator who can respond when the process is not behaving as expected.
A container being “up” is not the same as a healthy broadcast. It can remain running while FFmpeg is stuck on an input, repeatedly failing to publish, or sending frozen frames. The distinction matters overnight: process supervision can notice an exit, but it cannot by itself establish that viewers see continuous, audible, current content. The monitoring section covers the checks that close that gap.
If you are comparing approaches, a pre-recorded 24/7 stream workflow offers a useful contrast in how source material and presentation shape a continuous channel. The mechanics here are container-focused, but the source and destination still determine what you need to test.
Check channel and stream prerequisites
Before building a container, confirm that the channel is eligible to go live. YouTube’s live-streaming help says the channel must be verified and must not have live-streaming restrictions in the previous 90 days. Check the current help page and the channel’s Studio account status rather than assuming an older setup is still eligible.
In YouTube Studio, create or select the event in Live Control Room. The encoder workflow provides a server URL and stream key. The key is a credential that allows an encoder to send video to your channel, so treat it like a password: do not place it in a public repository, paste it into a public support thread or include it in screenshots. If it becomes exposed, reset it in Live Control Room and update the encoder configuration.
The preview is an important preflight check, not a formality. Start the encoder before scheduling or going live, wait for YouTube to show the incoming picture and sound, and check that the selected event is the one you intend to use. A correctly running FFmpeg process pointed at an old or wrong key can still fail to reach the audience.
Set the audience designation accurately. For streams designated “made for kids”, YouTube restricts or disables features that include live chat, comments, notification bell and personalised advertising; other features may also be limited. Do not base the programme or operating plan on chat being available, and do not forecast revenue on personalised ads. YouTube’s made-for-kids feature guidance is the place to check the current feature list. This article is about technical setup, not a determination of your legal obligations.
If you already use Studio with another encoder, the stream-key setup walkthrough can help clarify where the key fits in a publishing workflow. The same secret-handling principle applies when the key moves into a container configuration.
Prepare authorised source media
A streaming process can only send what its source provides. Assemble video and audio files that you have permission to use, and verify that the files play through from beginning to end before relying on them overnight. A children’s playlist might contain an episode, a quiet transition card, and another episode. Check for abrupt volume changes, black gaps, incorrect aspect ratios and material that should not be repeated.
FFmpeg can loop a single file with an input loop option, but a file loop is not an editorial plan. At the end of the file, viewers may see the same opening, transition or credits repeatedly. For multiple files, make a playlist with compatible codecs, dimensions and audio properties, or prepare a single continuous programme. If you need to mix varied formats, test the playlist in the exact FFmpeg build you will run; concatenation has format and timestamp constraints that a bare list does not solve automatically.
Keep a clean copy of the original media. If you convert or normalise files for streaming, write the converted output separately and play it back to check synchronisation and sound. The FFmpeg batch-conversion guide is relevant if you need to standardise a folder before the container starts. Avoid leaving a workflow dependent on files that can be renamed or moved while the service is running.
Plan for the difference between transmission duration and archive duration. YouTube’s encoder workflow says streams under 12 hours are automatically archived. That is not a promise that one open 24/7 event will become a complete, usable replay. Decide whether to use planned event segments, when to close and start an event, and how to check the resulting archive in Studio. Test this with your own channel before publishing a schedule that depends on replays.
Configure FFmpeg for YouTube ingest
Use YouTube’s current encoder settings as the baseline, then choose a profile that matches both your media and the upload connection. YouTube recommends RTMPS, constant bitrate encoding and a keyframe interval of two seconds, not exceeding four seconds. It supports several video codecs, including H.264, H.265/HEVC and AV1, and AAC or MP3 audio. Confirm what your FFmpeg build supports rather than assuming every codec is available in every image.
Bitrate depends on codec, resolution and frame rate. For one example from YouTube’s settings, 1080p30 H.264 has a minimum of 5 Mbps and a recommended 14 Mbps. That is not a universal target: a lower-resolution stream has a different range, and the bitrate your media can sustain depends on the actual upload path. Choose a profile from YouTube’s current table and test it from the location where the stream will run.
A simplified command illustrates the pieces, but is not a universal drop-in configuration:
ffmpeg -re -stream_loop -1 -i /media/programme.mp4 \
-c:v libx264 -b:v 4500k -maxrate 4500k -bufsize 9000k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -f flv \
"rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
This example assumes a 30 fps input when setting a 60-frame GOP, and its video bitrate is only illustrative; choose values from the appropriate YouTube profile and verify the keyframe timing for the actual output frame rate. Replace the ingest URL and key using a secure configuration mechanism. Do not commit a real key in a Dockerfile or share it with an untrusted party. In a real deployment, inspect FFmpeg’s output and test the command before using it as a continuous service.
FFmpeg’s FIFO muxer supports some output recovery behaviour. The FFmpeg documentation describes options such as -f fifo, -fifo_format flv, -attempt_recovery 1 and -recovery_wait_time 1 in an example. These may help the output continue after a temporary network failure, but their effect depends on the failure and build. Input reconnection flags, where relevant, concern reconnecting to an input; they do not automatically repair output delivery to YouTube. Test failure behaviour deliberately, and do not treat retries as a guarantee of gapless transmission.
Network capacity is part of the encoder configuration. YouTube’s network guidance recommends leaving 20% upload headroom and accounting for primary and backup streams when checking capacity. Measure upload performance, not only download speed, and test at the time and location you expect to run the channel. A wired Ethernet connection may suit a fixed installation; a UPS battery backup may help with brief power interruptions. These are practical choices, not substitutes for a tested network or recovery plan.
Build and run the container
Start with a small image that includes the FFmpeg build and codecs you have tested. Mount media read-only where practical, and keep logs accessible to the operator. The container should receive its stream key from a secret store or protected environment configuration, not from a value embedded in a publicly visible image. Limit who can inspect the host’s environment and configuration, because secrets can leak through operational tooling too.
A basic Docker invocation might mount a media folder and run a script that launches FFmpeg. Keep the command in a version-controlled script without credentials, then supply the key outside the repository. The exact Dockerfile and flags depend on your chosen image and host, so validate the resulting command rather than copying a generic image from an unfamiliar source. Pinning a known image version can make a later change deliberate; periodically review updates and retest before deployment.
Before running unattended, check container logs, CPU and memory use, disk space for any local recordings, and whether the mounted file is actually readable by the container’s user. A process that can read the file from your shell may fail when its container runs under a different account or path. Run it in the foreground for initial tests so you can see startup errors, then use your normal service manager or Docker tooling for controlled operation.
Test the exact workflow from boot to stream preview. Stop the container intentionally and confirm the expected policy behaviour. Restart the Docker daemon during a maintenance window if that is part of your failure model, and verify that the event returns as expected. Also test what happens if the source file is missing and if the network becomes unavailable. A successful one-time launch is not evidence that the channel has a workable overnight operating plan.
Choose a restart policy that matches operations
Docker’s restart policy documentation describes always and unless-stopped. Both can restart a container after it exits and can bring it back when the daemon restarts, with an important difference: unless-stopped respects a manual stop and leaves the container stopped after a daemon restart, while always can start it again. Choose according to who is allowed to stop the service and what should happen after host maintenance.
| Policy | Useful when | Operational consequence |
|---|---|---|
always |
You want the container to start again after an exit or daemon restart | A deliberate stop may not remain stopped after a daemon restart |
unless-stopped |
A manual stop should remain in effect across a daemon restart | An operator must deliberately start it again after that stop |
| No automatic restart | You want every failure to require an operator decision | An exit remains down until someone intervenes |
Docker notes that restart-policy monitoring begins after successful startup, defined as the container running for at least 10 seconds. More importantly, the policy responds to container exit, not broadcast health. If FFmpeg stays alive but outputs frozen pictures or silent audio, Docker has no reason to restart it. Nor can it know that YouTube rejected the stream key or that the event in Studio is misconfigured.
A restart policy is therefore one recovery layer, not an uptime commitment. Make manual stop and maintenance procedures explicit: record how an authorised operator pauses the container, how it is brought back, and how to avoid a restart loop when the source or credentials are broken. Test those procedures rather than relying on a policy name to predict every edge case.
Monitor the feed and recover failures
Monitor three separate views: the host and container, FFmpeg’s logs, and YouTube Live Control Room. Host checks can show that Docker is running and whether the process uses resources or exits. Logs can reveal a missing file, encoder error or output retry. Live Control Room and the public watch page help establish whether YouTube is receiving a feed and whether the viewer-facing picture and sound are usable.
YouTube recommends testing the full encoder setup ahead of an event, inspecting the preview before going live, testing backup failover, and monitoring audio and video continuously. For a planned test, stop the primary encoder or disconnect its network path and confirm that the person on duty knows what to do. If you cannot maintain a second encoder, document the simpler recovery route honestly: who checks the alert, who can reset the key, and who can restart or reschedule the event.
Use alerts that distinguish a process exit from a stalled or unhealthy feed. A basic container-state alert is useful, but it cannot detect every frozen image, silent track or ingest issue. Have an operator periodically check the Live Control Room health indicators and the watch page from a separate device. For ingest-specific symptoms, the guide to reading YouTube Live Control Room ingest logs can help you interpret the evidence before changing settings.
Write a short incident checklist and keep it where the operator can reach it. It should cover checking the network and power, confirming the source file and key, reading recent FFmpeg logs, inspecting YouTube’s preview or ingest status, and deciding whether to restart, switch to a backup encoder or end and recreate the event. Avoid repeated blind restarts: if a wrong key, corrupt file or inadequate connection is the cause, the same process is likely to fail again.
For long-running operation, separate planned segments from incident recovery. Schedule time to close or renew events, inspect archives, rotate media and apply tested image updates. Record when a change is made and whether it was followed by a preview check. StreamNeo can remove the need to keep your own computer switched on to send an uploaded file continuously, which addresses that particular burden; it does not replace accurate audience settings, checking the YouTube feed or deciding how you will respond to a failed event.
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
Can Docker keep a YouTube stream live if FFmpeg stops?
A restart policy can restart an exited container, provided its policy and host state allow it. It cannot guarantee that FFmpeg will start successfully, that the source will be readable or that YouTube will accept the feed. Check the logs and Live Control Room after recovery.
Does FFmpeg retry make a stream uninterrupted?
No. Output recovery can help with some temporary failures, but the network, credentials, input media and YouTube ingest can fail in ways that retries do not resolve. Treat retries as a recovery aid and keep an operator response plan.
Will one 24/7 event be archived as a complete replay?
Do not assume so. YouTube says streams under 12 hours are automatically archived; plan intentional event segments and verify current archive behaviour in Studio before relying on a replay.
Can children’s streams rely on live chat or personalised ads?
Not when the stream is designated made for kids: YouTube restricts or disables live chat and personalised advertising among other features. Set the audience accurately, check YouTube’s current guidance, and do not build the operating plan around unavailable interactions or ad assumptions.