To run a YouTube Live loop with systemd and FFmpeg, YouTube provides the ingest address and stream key, FFmpeg repeats and sends your media, and systemd supervises FFmpeg as a foreground process. You can run this on an always-on Linux machine you already control; a rented host is optional, not a requirement.
The important distinction is that systemd can restart a process that exits, but it cannot tell you whether YouTube is receiving a usable picture and sound. You need to test the stream in YouTube Live Control Room and keep checking its health separately.
Understand YouTube ingest, FFmpeg, and systemd
These three components have separate jobs. You create or schedule a live event in YouTube Studio, then use the current ingest URL and stream key shown for it. The key is a secret: treat it like a password, do not paste it into a public script or share a terminal transcript that exposes it, and rotate it if you believe it has leaked. See YouTube’s encoder settings and live ingest guidance for current connection details.
FFmpeg reads your video or playlist, optionally encodes the media into a suitable format, and sends the resulting stream to YouTube’s ingest endpoint. systemd starts FFmpeg, keeps it in the foreground under service supervision, and can attempt a restart when the process fails. Neither FFmpeg’s continued existence nor a green-looking service status proves that the event is playing correctly to viewers.
Before you build a service, confirm that live streaming is enabled on the channel, that the event is ready, and that the host can read the media. YouTube’s stream creation instructions say streams under 12 hours are automatically archived. This matters for a loop intended to run continuously: plan event boundaries and check YouTube’s current limits rather than assuming one event or archive can continue indefinitely.
For a household or small channel, an existing Linux computer may be sufficient if it can remain available and its network connection is dependable. A VPS or dedicated host is another deployment choice when you do not want to leave a local machine running, but it adds recurring cost and another system to maintain. Choose based on the availability you need, not because this workflow requires a particular machine.
Prepare the media and YouTube stream details
Use absolute paths for the media, playlist and any scripts. A service does not necessarily start in the same directory as your interactive shell, so relative paths that work manually can fail when systemd launches the process. Store the media somewhere readable by the service account and use an account with only the access it needs where practical.
Decide whether the input is one file or a playlist. A single file has fewer transition and compatibility problems. A playlist can offer variety or sequence several lessons, bhajans or ambience clips, but transitions depend on consistent stream layouts and timestamps. If the files differ in codecs, resolution, audio layout or time bases, test the actual transitions instead of assuming a playlist will behave like one seamless file.
The FFmpeg concat demuxer accepts a defined list of files and has a playlist loop directive. Its file and stream expectations matter; consult the FFmpeg formats documentation that corresponds to your installed release. For a single file, FFmpeg also has input-level looping options, but their behaviour depends on the input demuxer and option placement. Do not confuse those options with the concat demuxer’s own playlist directive.
Gather the current YouTube event’s ingest URL and stream key, and decide whether to use RTMPS. YouTube recommends encrypted RTMPS when supported by your FFmpeg build and configuration. Do not put a real key in an illustrative command, a unit file readable by every local user, or a repository. If using an environment file or systemd credential feature, check the installed systemd documentation and permissions on your system first; directives and secure handling can vary.
Configure FFmpeg to repeat and send the feed
Start by deciding whether FFmpeg should copy the input streams or encode them again. Stream copy avoids encoding work, but only makes sense when the source codecs and stream properties are suitable for YouTube and remain appropriate across every playlist item. Re-encoding uses more CPU, but gives you more control over resolution, frame rate, codec, bitrate, audio and keyframe interval. Neither route is automatically better; a short test with your real files is the useful check.
YouTube documents RTMP/RTMPS ingest, H.264, H.265 or AV1 video, AAC or MP3 audio, constant bitrate (CBR), and a recommended two-second keyframe interval, with four seconds as the maximum. Match the output bitrate to the chosen resolution, frame rate, codec and reliable upload capacity. YouTube’s current encoder table lists, for example, 14 Mbps as the recommended H.264 bitrate for 1080p at 30 fps and 10 Mbps for H.265 or AV1 at that resolution and frame rate. Those are recommendations in YouTube Help, checked in October 2026, not promises of quality or requirements for every source.
If your connection cannot sustain the selected output reliably, lower the output target rather than choosing settings that exceed the available upload capacity. Leave headroom for ordinary network variation and other traffic on the connection. For a separate discussion of how upload problems appear, see this guide to troubleshooting dropped frames in a YouTube stream.
The FFmpeg command needs to express a repeatable input, the desired output encoding or stream copy, and the YouTube ingest destination. Option order matters in FFmpeg: input options apply before the corresponding input, while output options apply to the destination. Confirm the option behaviour in the manual for your build and test whether the loop returns cleanly to the start without a timestamp jump, black interval or audio discontinuity. Avoid copying a command blindly from another source file or FFmpeg version.
Run FFmpeg as a managed foreground process
A systemd service should own a process that stays in the foreground. Do not background FFmpeg with shell syntax or rely on an interactive terminal session: systemd needs to observe the process it starts so it can report its exit and apply restart policy. A simple long-running service model is commonly suitable, but confirm directives and behaviour against the systemd version on the target host.
Use a stable working directory if the workflow needs one, though absolute paths reduce dependence on it. Arrange for standard output and error to reach the journal so you can inspect FFmpeg’s messages with the service logs. Configure a restart-on-failure policy and a delay appropriate to your situation; repeated rapid failures should not become an endless retry storm. The systemd project documentation discusses restart behaviour for services, but check the manual matching your installation before adopting specific directives.
Keep service credentials and file permissions in view. A stream key embedded directly in a unit can be exposed to users who can read that file or its rendered command details. A protected credential mechanism or narrowly permissioned configuration may be preferable, but the right mechanism is version-dependent. Do not treat an environment file as secret merely because it is not in the main unit; verify who can read it and how your systemd version handles it.
Create and start the systemd service
Create the unit only after the FFmpeg input and output have worked in a manual test and you have a safe way to provide the key. The unit should identify the service account, the foreground FFmpeg command, any required working directory, log handling and the restart policy. Use placeholders while drafting, never a real stream key in a shared example. Where a command contains special characters or paths with spaces, validate the systemd quoting rules for the local version rather than borrowing shell quoting assumptions.
After saving a unit, ask systemd to reload its configuration, then start the service and inspect its status. The exact commands for unit management are standard on many installations, but this guide does not claim a command has been tested on a named distribution or version. Use the local systemd manual and your administrator’s conventions, especially on managed or production hosts.
Starting the unit only establishes that systemd attempted to run the process. Open the event in Live Control Room, wait for the preview, check both image and sound, and then begin the event if the workflow requires you to do that manually. YouTube recommends testing and monitoring stream health, not just confirming that an encoder has connected. If you want a broader file-loop approach without a service manager, compare the workflow in using FFmpeg to stream a folder continuously.
Check logs and stream health
Use the service status and journal to distinguish basic process failures from media and network faults. FFmpeg output may reveal an unreadable path, unsupported codec, failed connection or encoding error. A service that is active can still be sending the wrong input, frozen imagery, silence or media that YouTube flags as unhealthy. Check the preview and the stream-health indicators in Live Control Room, and listen to the actual output rather than relying on a process status alone.
If there is no preview, first verify the event is configured for the correct stream, the key and ingest URL are current, and the host can reach the endpoint. If the preview appears but warnings or poor playback persist, check the upload connection, bitrate, codec, keyframe interval, timestamps and the source media. YouTube’s troubleshooting guidance and interface can change, so consult the current official page instead of relying on an old click path.
For an event that shows an upcoming video instead of playing, the problem may be with event configuration or the live handoff rather than the looping process itself. The separate guide on an upcoming video appearing instead of playback covers that viewer-facing symptom. A local check that the file is advancing and audio is present is still useful, but it cannot replace checking YouTube’s preview.
Test restart behaviour and choose where it runs
Test failure recovery deliberately before relying on the service overnight. First establish that the event plays normally. Then stop or interrupt the FFmpeg process in a controlled test and observe whether systemd applies the intended restart policy. Confirm that the restarted process reconnects to the event and produces a usable preview; a restart message in the journal alone is not a successful recovery test.
Restart-on-failure handles a process that exits unexpectedly. It does not detect every stalled connection or unusable output if FFmpeg remains alive. If your channel needs stronger operational assurance, add monitoring that checks the stream’s actual behaviour and alerts you to a problem, or make regular manual checks part of the schedule. Keep retry delays and any systemd start-rate limits in mind so a bad key or persistent network fault does not create repeated rapid attempts.
For a small channel, compare the deployment choices before making the loop permanent:
| Choice | Useful when | Trade-off |
|---|---|---|
| One file on an existing Linux host | You want the simplest repeat and already have a suitable machine | The host and its connection must remain available; one file can become monotonous |
| Playlist on an existing Linux host | You need a sequence of clips without manual changes | File compatibility and transitions need testing; more inputs create more ways for the loop to fail |
| A rented continuously available host | You do not want a local computer running all the time | Recurring cost and remote administration; it is optional, not a requirement |
| Re-encode in FFmpeg | The source needs controlled output settings | Uses CPU and needs a test at the intended settings |
| Copy compatible streams | Source streams already match the required output | Less control, and every playlist item must remain compatible |
If you already have a Linux computer that can stay on, it may be the more practical starting point than renting capacity. If no machine can remain available, compare hosting options and their current terms directly; there is no requirement to choose a particular VPS. For a spare-computer setup and the practical constraints of running one in India, see the guide to a 24/7 channel on a spare PC.
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 loop a video on YouTube Live?
Create or schedule a YouTube Live event and use its current ingest URL and stream key. Configure FFmpeg to repeat the file and send output in a format YouTube accepts, then test the preview and actual playback before relying on the loop.
How can I stream a prerecorded video 24/7 on YouTube?
You can keep FFmpeg running on an always-available Linux host under systemd, but YouTube event and archive limits still apply. YouTube Help says streams under 12 hours are automatically archived, so plan event boundaries and check current official guidance rather than assuming one event can run without limit.
How do I keep FFmpeg running after I log out?
Run it as a systemd service in the foreground, rather than in your interactive shell or as a manually backgrounded process. Configure a suitable restart policy, then verify both the journal and the YouTube stream; supervision alone does not establish healthy playback.