To rotate videos on a 24/7 YouTube stream from Linux, have FFmpeg read a playlist and send the output to YouTube Live. Keep FFmpeg running under a supervisor such as systemd; use cron for bounded jobs such as refreshing a playlist or checking a health signal, not as the sole keeper of the stream.
This is a practical community pattern, not a YouTube requirement. It gives you a clear division of responsibility: one process handles continuous playout, a service manager handles process recovery, and scheduled scripts take care of maintenance. The exact playlist format and update behaviour depend on your media and FFmpeg setup, so test the complete path before leaving it unattended.
Prepare local video files and a playlist
Start by putting the clips on storage that remains accessible to the Linux machine while the stream is running. Give the files stable names and organise them in the order you intend to play them. A playlist is only a list of inputs; it does not make mismatched files compatible or guarantee a clean transition between them.
Inspect the clips before building the list. Check their containers, video and audio codecs, dimensions, frame rates, audio streams and durations. For a devotional channel, for example, you might have a folder of bhajan recordings with a still image, a longer video with motion, and a few files with different audio formats. If those differences cause gaps, failed reads or inconsistent output, normalise the files before unattended playback or choose an FFmpeg input approach that suits the set.
FFmpeg supports several ways of reading concatenated or playlist-oriented inputs. Its formats documentation explains the available formats, including the concat demuxer. Do not treat a format reference as a ready-made recipe: the command and playlist syntax need to match your files, and some approaches expect compatible streams or particular file properties.
Keep the playlist separate from the media. A simple text file can be convenient, but ensure paths are unambiguous and readable by the user account that runs the service. Absolute paths avoid dependence on a shell's current directory. If filenames contain spaces or special characters, follow the syntax required by the chosen playlist format rather than assuming ordinary shell quoting rules apply inside the list.
A useful first test is to play through a small sample set locally, including the transition between every type of clip. Watch for black frames, audio gaps, frozen pictures, unexpected scaling and a playlist that ends instead of returning to the beginning. If you are weighing playlist handling in another workflow, the guide to switching between video playlists in an OBS YouTube stream covers a different tool, but the same need to test transitions applies.
Keep a known-good copy of the current playlist and FFmpeg command. When you change either, you want to be able to tell whether a problem came from the media, the list, the encoder options or the connection to YouTube. Avoid changing several of those at once during your first live test.
Get the YouTube server URL and stream key
In YouTube Studio, create or select a live stream and open the Live Control Room workflow. YouTube supplies the server URL and stream key for the encoder. The exact screen and workflow can change, so use the current YouTube Help instructions for creating a live stream with an encoder when configuring your channel.
The server URL tells FFmpeg where to send the encoded media; the stream key associates the incoming feed with the relevant YouTube setup. Treat the key like a password. Do not commit it to a public repository, paste it into a support post, or make a configuration file readable by every local account. Keep it out of logs where practical, and use a protected configuration file or a mechanism appropriate to your system for passing it to the service.
YouTube describes a broadcast and a stream as related but distinct objects: the broadcast is the viewer-facing event or video, while the stream is the incoming media configuration. The YouTube Live Streaming API guide to broadcasts and streams discusses this distinction, including a 24/7 feed used alongside a separate broadcast. For a channel operator, the practical point is to check that the incoming encoder is connected to the intended live setup, not to assume that one long-running process dictates every aspect of the viewer-facing event.
Before starting FFmpeg, confirm the stream is configured for the output you plan to send. The encoder settings, YouTube's current options and your files must agree. Do not copy an encoding profile from an unrelated tutorial without checking it against the current YouTube guidance and what your media can sustain.
Start FFmpeg and verify the live output
First run the intended FFmpeg command manually from the same Linux account that will own the service. This makes permission and path problems visible before you add systemd. Use your actual playlist, output settings and YouTube ingest details, but avoid putting a real stream key into a command history that other users can read.
Check FFmpeg's output for errors while it opens the input, encodes media and sends data. A process that remains present is not proof that the correct picture and sound are reaching viewers. Open the relevant YouTube preview or live page and verify that the image moves, audio is audible, the expected clip is playing and the transition to the next item behaves as intended.
Let the test run across a playlist boundary. Then confirm that the list loops as expected, rather than exiting after its last entry. Listen for audio that drifts out of sync and look for clips that display at an unexpected size or frame rate. Local tests can reveal a malformed list, but only checking the public YouTube playback confirms the full route from the encoder to the viewer-facing output.
If YouTube does not show the feed, separate the possible causes: a local FFmpeg input or encoding error, a network or ingest problem, a key or URL issue, or a Live Control Room workflow step that remains incomplete. Check the current Studio state and YouTube's troubleshooting guidance rather than repeatedly restarting an unchanged command. For other examples of continuous playback choices, see the article on setting up a 24/7 meditation music live stream on YouTube.
Do not begin with an expectation that a 24/7 broadcast will produce one complete archive. YouTube Help says streams under 12 hours are automatically archived; that is not a promise that a stream running longer will be archived in full. If you need a durable copy, plan and test a separate recording workflow and check YouTube's current guidance.
Keep FFmpeg running under systemd
A 24/7 encoder is a long-running process, so tie its lifecycle to a service manager rather than to an open terminal. A systemd unit can start FFmpeg at boot, run it as a chosen user, and apply a restart policy if the process exits. This is an operator's design choice, not a requirement from YouTube.
Keep the unit definition explicit: identify the executable, working directory if needed, configuration and playlist paths, and the account that should run the process. Make sure that account can read the files and write any required logs or state. A service started by systemd does not inherit the interactive shell environment you used during testing, so use full paths and do not rely on aliases, shell profiles or a mounted drive that is only available after login.
A restart policy can recover from an FFmpeg crash, but it cannot determine whether the outgoing picture is fresh or whether viewers can reach the stream. A process might still exist while stalled, disconnected or repeatedly failing to open an input. Review service logs and the actual YouTube playback together. The community FFmpeg reconnection guide can help frame disconnection recovery, though reconnection and playlist rotation are separate concerns.
A community setup example combines FFmpeg under systemd with cron-based watchdog and restart jobs. Treat that as one implementation pattern, not as a proven interval or universal requirement. A scheduled restart deliberately interrupts the outgoing feed; whether and how YouTube presents that interruption depends on the live setup. Avoid adopting a routine restart schedule just because someone else reports using one.
Use cron for bounded maintenance tasks
Cron is useful when a task starts, does a finite piece of work and exits. For example, it can run a script that rebuilds a playlist after new files arrive, checks whether a local progress signal has stopped changing, or schedules planned maintenance. The recurring schedule belongs to cron; the ongoing media connection belongs to FFmpeg supervised by systemd.
Give each cron job explicit paths and a predictable environment. Cron often runs with a smaller environment than your login shell, so set needed variables or invoke the expected interpreter deliberately. Write output somewhere you can inspect, rotate or otherwise manage the logs, and make a failure visible rather than discarding all output. The job should be safe to run when a file is missing or a previous run has not completed.
Prevent overlap. A playlist refresh that takes longer than expected should not collide with another refresh, and a watchdog should not launch a second FFmpeg instance beside the supervised one. Use a lock or another reliable single-instance method appropriate to your distribution and script. More importantly, design the watchdog to signal or report a fault through the service manager's lifecycle, not to create competing encoders.
A cron-triggered restart can be useful for deliberate maintenance, but it creates an interruption and is not the same as automatic recovery after an unexpected process exit. State the reason and expected effect to anyone who depends on the channel. If the interruption is unacceptable at a particular time, schedule maintenance around the channel's needs and verify the recovery path beforehand.
A simple operational division is:
| Responsibility | Suitable owner | What to check |
|---|---|---|
| Continuous playlist playout | FFmpeg process | Correct order, looping and transitions |
| Process startup and exit recovery | systemd service | Status, exit reason and service logs |
| Rebuilding a list or a finite health check | Script invoked by cron | Explicit paths, clear result and no overlap |
| Viewer-facing delivery | YouTube playback and Studio | Fresh picture, audio and connection state |
Cron syntax, locking and the way a running FFmpeg process notices playlist changes depend on the Linux distribution, shell, playlist type and command. They are not defined as a single YouTube recipe. Keep the scheduled job narrow, and test what it does when the machine is rebooted or the input directory is unavailable.
Update playlists without relying on a short-lived process
Do not assume that editing a playlist file changes what an already-running FFmpeg process will play next. Some input methods read their list when they start; others have different behaviours. Establish this for your chosen format and installed FFmpeg version with a small test before designing a live update around it.
One conservative method is to have a script generate a new playlist file alongside the current one, validate that the entries exist and are readable, and then replace the active file in a controlled step. Whether the running process will use that replacement still depends on how it opened the input. If it does not reload the list, your choices may include using a playlist mechanism designed for updates, signalling a supported control interface, or arranging a controlled service restart. Each choice has different interruption and complexity costs.
Do not truncate the active list and then fill it gradually if FFmpeg might read it during the incomplete state. A safer pattern is to build a complete candidate, check it, and only then make it active in the manner your input method supports. Preserve the previous version long enough to roll back if the new order contains a missing path or an unsuitable file.
For example, a local news loop might add an updated weather segment during a quiet maintenance window. The update script should check that the new file is present, readable and in the expected format before publishing the revised list. Then verify that the on-air sequence actually includes it. A successful cron exit only says that the script completed; it does not prove FFmpeg adopted the new playlist.
If a restart is the only reliable way to load changes, make that an explicit, controlled action through systemd rather than launching a replacement process directly from cron. The feed may briefly drop while the service stops and starts. Test the interruption and reconnection in advance, and communicate the maintenance window if viewers rely on uninterrupted playback.
Test restart and watchdog behaviour
Test recovery while the channel is not depending on the stream for an important event. First confirm that the service starts after a machine reboot, then stop or terminate the FFmpeg process in a controlled test and see whether systemd brings it back. Check the service status and logs, and confirm in YouTube playback that the new connection produces fresh video and audio.
A watchdog needs a meaningful signal. A process ID alone is weak evidence: FFmpeg may be alive but not advancing media. A local progress file or monitored output can provide a clue, but local progress still does not prove that YouTube is receiving usable media. Pair local checks with a viewer-facing check, and make the watchdog report what it observed so that repeated false alarms do not trigger repeated restarts.
Check for duplicate-process behaviour explicitly. If the service manager owns FFmpeg, a cron job that also starts FFmpeg can create two encoders competing to use the same channel. Design the cron job to inspect or request action on the existing service, and test both the normal case and the case where the service is already restarting.
Run through at least one playlist update during testing. Confirm the expected order, whether the current clip completes, whether the next clip is loaded, and what happens if the new list contains a missing file. Record the final working configuration and the recovery steps. This turns a setup that only one person understands into something you can operate after a late-night failure.
If this operating burden is not a good fit, a hosted workflow may suit you better. YouTube's own encoder listing includes hosted services such as Gyre for prerecorded 24/7 streaming; that is an alternative workflow, not a component required for a Linux cron setup. StreamNeo can remove the need to leave your own computer running for this particular file-to-live-stream task: you upload a video, provide the YouTube stream key, and the stream is managed from there. It is YouTube-only, so first decide whether you need the control of a Linux playlist and scripts or prefer a hosted workflow with less machine maintenance.
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 cron keep FFmpeg running all day?
Cron can start a command on a schedule, but a short-lived cron job is not a sound sole supervisor for a process intended to run continuously. Run FFmpeg under a service manager such as systemd, and reserve cron for finite maintenance, checks or planned actions.
Will a playlist edit change the running stream immediately?
Not necessarily. It depends on the playlist format and how FFmpeg opened it, so test the update behaviour with your installed version and command. If a restart is needed, make it controlled through the service manager and account for the interruption.
Does YouTube require systemd and cron?
No. YouTube provides the server URL and stream key for an encoder; systemd plus cron is a community implementation pattern for Linux operations, not a platform requirement. Choose a process supervisor and maintenance approach you can test and maintain.
Will YouTube archive a 24/7 stream in full?
Do not assume so. YouTube Help says streams under 12 hours are automatically archived, which does not assure a complete archive for a longer continuous stream. Check current YouTube guidance and plan separate recording if you need a durable copy.