To loop a video file to YouTube Live with FFmpeg, create an encoder stream in YouTube Studio, then use FFmpeg’s -stream_loop -1 input option to repeat the file and send its output to the stream URL and key. Docker can package the runtime and make the video available inside a container, but it does not by itself make a broadcast reliable.
This is a safe outline to test, not a verified deployment recipe: no specific image, Compose file or supervisor configuration has been validated here. Check the chosen image and your own settings, then test the complete audio and video path in YouTube’s preview before relying on it.
Understand what Docker and FFmpeg each do
FFmpeg reads a media file, prepares an audio and video output, and sends that output to an ingest endpoint. Docker provides a containerised runtime in which FFmpeg and its dependencies can run. You still need to choose and review the image, make the media available to the container, supply the stream credentials securely, and decide how to observe and recover the process.
It helps to keep those responsibilities separate. If the video does not repeat, investigate FFmpeg’s input options and command. If the file cannot be read, check the mounted path and container permissions. If YouTube receives no video, verify the URL, key, output format and stream settings. A container can run a process; it cannot establish that your channel is eligible, your file is suitable or your broadcast is being received correctly.
YouTube’s encoder setup guidance says to create or select a stream in Live Control Room and enter its server URL and stream key into the encoder. Live streaming also requires an eligible channel: check YouTube’s current requirements and any restrictions on the channel before building around a scheduled broadcast. Keep the stream key private, as you would a password, and reset it if you believe it has been exposed.
For a one-off broadcast, a computer running FFmpeg may be simpler to understand and inspect. Docker becomes useful when you want a repeatable runtime or a clear boundary between the media and host environment. Neither choice removes the need for a dependable network connection and someone or something able to notice a failed stream.
Prepare the video and the loop workflow
Start with one file and a defined output target. Check that the recording plays from beginning to end, that its soundtrack is present at a sensible level, and that its content is suitable to repeat. A loop returns abruptly to the start unless the end and beginning were prepared to join smoothly. Watch that transition in advance; a long blank frame, silence or sudden change in volume can be more noticeable after hours of repetition.
The FFmpeg option -stream_loop controls repetition of an input. The official FFmpeg documentation defines -1 as infinite looping and identifies this as an input option. Its placement matters: put it before the -i for the file it should repeat. FFmpeg options apply to the next input or output, so moving it elsewhere may change what it affects.
For example, the command shape below shows where the loop option belongs. It is illustrative, not a tested end-to-end command; the encoders, output protocol, options and file compatibility need checking against your FFmpeg build and the stream settings you choose.
ffmpeg -re -stream_loop -1 -i /media/video.mp4 \\
-c:v libx264 -pix_fmt yuv420p -preset veryfast \\
-c:a aac -b:a 128k \\
-f flv "$YOUTUBE_INGEST_URL/$YOUTUBE_STREAM_KEY"
Treat the example as a map of the workflow, not a copy-and-run answer. Confirm which URL and protocol YouTube gives the selected stream, and whether the file’s video, audio, dimensions and frame rate suit the output you intend to send. A file that plays locally can still fail an encode or ingest test. Avoid publishing a real key in a command, screenshot or repository. Shell history can retain commands, so use an appropriate private runtime secret mechanism rather than typing a credential into a line you plan to save or share.
If you are deciding between a single file and a playlist, they are different workflows: looping one file does not select and schedule several recordings. For that separate job, see the guide to streaming a playlist of videos on YouTube Live. Keep the first Docker test deliberately small, so a failure has fewer possible causes.
Choose and review a Docker image
Docker images are not interchangeable recipes. Before using one, check who publishes it, what FFmpeg build it contains, how it starts the process, which user it runs as, and how updates are handled. Confirm the image’s documentation against its actual entrypoint and available options. This research does not validate a particular image, tag or Compose configuration, so there is no image here that can responsibly be presented as tested.
Review how the image expects media and secrets. A file path on the host is not automatically available in the container; it needs to be mounted or otherwise copied in. A key placed in an image layer, committed Compose file or public environment listing can be exposed to anyone who can inspect it. Use a secret mechanism appropriate to your deployment and restrict access to both the secret and the machine that runs the container.
Also check the licence and provenance of the image and any bundled components, and decide how you will identify the exact version you tested. A floating tag can resolve to different content later. Pinning a version improves repeatability but does not mean the image is maintained or secure; you still need to review updates and test changes before relying on them.
Avoid assuming that a restart policy is a production supervisor. A container may restart after a process exits, but a process can remain running while sending unusable output. A restart setting also says nothing about host power, storage, network access, or whether YouTube has accepted the stream. Those require separate monitoring and checks, described below.
If maintaining and checking a container is more work than the broadcast warrants, compare it with a machine you can observe directly. The PC electricity cost versus cloud service cost guide helps frame the operating trade-off; the choice depends on your equipment, connection and willingness to maintain the runtime, not on a promise that one arrangement will stay live.
Pass media and configuration into the container
Think in terms of three inputs: the media file, non-secret settings and credentials. Mount the media at a path the command can read, such as /media/video.mp4 in the conceptual example. Check the path from inside the container, and confirm the container user has permission to read it. A correct host path paired with the wrong container path is a common, simple failure to rule out early.
Keep the command and configuration separate from the secret where possible. The ingest URL and stream key are supplied by YouTube Studio; do not bake a real key into an image or place it in source control. Environment variables are convenient for passing values to a process, but they are not automatically secret: their visibility depends on the host, orchestration tools and access controls. Choose a secret store or protected runtime input that matches the environment, and do not print credentials in logs.
Before the stream starts, validate that the container can read the file and that FFmpeg can inspect its streams. Check the file’s duration, video and audio streams, dimensions, frame rate and codecs. If you intend to transcode, verify that the selected encoders are present in the image. If you intend to copy the file’s existing streams, first confirm those streams fit YouTube’s current ingest guidance. This is a decision to test, not a reason to assume a particular file will work.
Keep writable paths and logs intentional. A container that has no persistent storage may lose useful local logs when it is replaced; persistent storage should not casually become a place to retain a stream key. Decide which output is needed for diagnosis and who can read it. Test that a restart does not accidentally delete the media or change the location of the configuration.
Record the chosen image version, mount paths, output settings and a description of how secrets are supplied. That record helps you reproduce a known test without recording the secret itself. It also makes a later change—such as a new image version or a re-encoded file—something you can isolate rather than a simultaneous change to every part of the setup.
Connect FFmpeg to YouTube Live
In Live Control Room, create or select the encoder stream and copy the server URL and stream key shown for it. Use those values for the intended stream, and identify the protocol shown in Studio rather than guessing a URL. YouTube recommends RTMPS for the standard RTMP path in its encoder settings guidance. That recommendation does not establish that every FFmpeg build or URL accepts every possible codec and option.
The illustrative command uses the FLV muxer, a conventional pairing for an RTMP-style output, but this research has not verified a complete command across input files and builds. Check the output protocol, muxer and encoders against the stream settings and FFmpeg build you actually use. YouTube’s current encoder guidance lists supported video choices and audio options, along with recommendations for bitrate, frame rate and keyframe interval. Review that page at implementation time; do not treat a sample command as a substitute for its current requirements.
For H.264, YouTube’s settings page gives different recommended bitrates for different resolution and frame-rate combinations. For example, its recommendation for 1080p at 30 fps is 14 Mbps, with 5 Mbps listed as a minimum; for 720p at 30 fps it recommends 8 Mbps, with 3 Mbps as a minimum. These are YouTube’s H.264 ingest figures, not a guarantee about what a particular connection can sustain. Choose a target that fits both your media and available upload capacity, and leave room for other network traffic.
YouTube recommends a two-second keyframe interval, with a maximum recommendation of four seconds. Its guidance for stereo audio lists 44.1 kHz and 128 kbps. Those are settings to check against the actual output, not evidence that an arbitrary file or FFmpeg build produces them. YouTube’s streaming tips also advise leaving upload bandwidth headroom; account for the complete outgoing stream and other use of the connection, rather than measuring only when the channel is idle.
| Output choice | YouTube’s cited H.264 recommendation | What to check |
|---|---|---|
| 720p at 30 fps | 8 Mbps recommended; 3 Mbps minimum | Whether the file and connection support the target, with upload headroom |
| 1080p at 30 fps | 14 Mbps recommended; 5 Mbps minimum | Whether the higher target is appropriate for the content and connection |
The bitrate figures are not universal settings for every codec or frame rate. Use YouTube’s current table for your chosen combination, and verify the actual encoder output and stream health. If your upload link is constrained, a lower resolution and frame rate may be a more sensible starting point than aiming at a higher target without room for fluctuations.
The bitrate guide for a podcast with a still image offers a related way to think about matching a modest visual format to an output target. Do not copy its settings blindly: the source video, motion, frame rate and connection here may differ. Set an output you can inspect and sustain, then refine it from a real test.
Test the stream before relying on it
First confirm that YouTube Live is available to the channel and that you have selected the correct stream in Studio. YouTube’s eligibility guidance includes channel verification and no live-streaming restrictions in the preceding 90 days; check the current official requirements rather than assuming an old account or an earlier successful stream proves eligibility now. Keep the test separate from a public event where possible, and understand which Studio controls make the stream visible to viewers.
Run the container with a test stream or an appropriate preview. Watch the incoming picture and listen to the audio, including the point where the video loops. Confirm that the picture is not frozen or unexpectedly cropped, that sound is present and in sync, and that YouTube reports healthy ingest. A process log saying that FFmpeg started does not prove that Studio is receiving a usable stream.
Test the key handling as well as the media. Check that the runtime can access the credential without exposing it in terminal output, logs, a saved command or repository history. If you need to paste a value during setup, use a private environment and remove temporary copies. If the key may have leaked, use YouTube Studio’s reset option and update the runtime with the replacement.
Before a longer broadcast, check that the file is still available after a container restart and that the process returns to the expected input and output. A test that only lasts until the first loop boundary may miss a discontinuity; let it run through that point and inspect again. The time needed depends on the file’s length and the test environment, so there is no universal test duration to promise.
YouTube advises setting up in advance, starting early and checking the preview before selecting Go live. Follow its current operating instructions for the selected stream. If you end the event, stop the encoder as well. YouTube says streams shorter than 12 hours are automatically archived; do not assume a longer broadcast will be archived in the same way, and check the current archive guidance if the recording matters to you.
Plan monitoring and recovery carefully
A 24/7 loop has failure modes outside FFmpeg: the host may lose power, the network may drop, the file may become inaccessible, or YouTube may stop receiving an acceptable signal. A container restart policy can help with a process that exits, but it cannot detect every bad picture or confirm that the platform has resumed ingest. Do not promise continuous uptime on the basis of a Compose setting or a running process.
Decide what you will monitor before leaving the stream unattended. At minimum, establish how you will notice that the container stopped, how you will check YouTube’s stream health and preview, and who can act on an alert. A log should help distinguish a file-read error, an encoder failure and a connection problem without exposing the stream key. Monitor the broadcast at the platform as well as the process on the machine.
Write down a recovery procedure that you can follow when tired: verify power and connectivity, inspect the container and recent logs, confirm the media mount, check the Studio stream status, then restart only after identifying what failed. If YouTube reports a different ingest problem, consult the current platform guidance rather than repeatedly cycling the process. Test recovery deliberately while the broadcast is private or otherwise safe to interrupt, and confirm that a restart does not create an unwanted public event or use the wrong stream key.
If you are weighing how much host maintenance you want, compare the Raspberry Pi and VPS options for a 24/7 YouTube stream. A small local device may suit someone able to manage power, storage and connectivity; a hosted machine changes those practical responsibilities but still needs oversight. If the specific pain is keeping a computer on and manually restarting a dropped file-based broadcast, StreamNeo removes that computer-running and process-restart task by running an uploaded video as a YouTube live stream, while leaving the channel and stream setup yours to manage.
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 Docker make the stream 24/7 by itself?
No. Docker runs the process in a container, but a host, network, media file and accepted YouTube ingest are still required. A restart policy can restart an exited process; it does not prove that viewers are receiving usable video or prevent outages.
Where does -stream_loop -1 go?
It is an input option and belongs before the -i for the file you want to repeat. FFmpeg documents -1 as infinite repetition. Check the full command and output separately, because looping the input does not establish that the encoder or YouTube connection is configured correctly.
Can I paste the example command into a container unchanged?
No. It is a conceptual shape, not a verified Docker recipe. The image, FFmpeg build, mounted file path, permissions, output protocol, codecs and secret handling all need checking in your environment before a test.
Will YouTube archive an all-day stream?
YouTube’s guidance says streams under 12 hours are automatically archived. Do not assume a longer stream will be archived, and check the current official archive guidance if you need a recording. Keep your own source file and any required backup independently.