A Linux machine can send a looping video to YouTube continuously, provided the host, network connection, source media and YouTube event remain available. FFmpeg handles the media feed, while a Linux service manager can start it at boot and relaunch it after a process failure.
That combination reduces manual work, but it does not make an unattended broadcast self-healing. You still need to configure YouTube’s ingest settings, protect the stream key, allow enough upload capacity, inspect logs and test the exact command on the Linux system that will run it.
What you need before streaming from Linux
Start with four things: a YouTube channel that can go live, a prepared video or generated feed, an always-on Linux host, and a network connection with sufficient upload capacity. The host may be a computer in your office, a dedicated machine, or a rented Linux server. It must stay powered, avoid sleep, and be able to reach YouTube for the duration of the broadcast.
A laptop running inside an interactive terminal is a poor unattended arrangement. Closing the terminal, logging out, applying a restart, or allowing the laptop to sleep can stop the process. A service manager is more suitable because it separates the FFmpeg process from your login session and gives you a place to review its status.
Your media also needs checking before it becomes a live source. Confirm that the file plays from beginning to end, has the intended audio track, and does not depend on a removable drive or a mounted location that may disappear. A devotional channel, for example, should not rely on a USB disk that is routinely unplugged after the initial setup. If you are preparing an ambience channel, the guide to rain, nature and ambience loops covers content considerations that sit alongside the technical setup.
Measure upload capacity, not just download speed. YouTube recommends leaving 20% headroom and accounting for the primary and backup bitrate. Other people or devices sharing the connection can reduce the capacity available to FFmpeg, so choose a stream target that remains practical during normal use rather than matching the maximum shown by a speed test.
You also need an FFmpeg build appropriate for the machine and a way to store the stream key without exposing it. Avoid placing the key in a public script, a screenshot, a tutorial copied into a repository, or a command history that is routinely shared. YouTube provides a reset path in Live Control Room if the key is exposed.
Before choosing this route, compare the operating burden honestly. A self-managed Linux host gives you control over files, codecs, process settings and logs. It also makes you responsible for updates, power, disk space, network faults and recovery. A hosted service removes some of that maintenance. StreamNeo is intended for the narrower case where you want to upload a file, supply the YouTube key and have the channel run without leaving your own computer switched on.
Prepare the YouTube Live event and ingest settings
Create or schedule the event in YouTube Live Control Room. YouTube’s encoder settings documentation provides the current stream URL, encoder requirements and bitrate guidance. Copy the stream URL and stream key into the configuration you will use on Linux, but keep the key private and out of ordinary logs where possible.
YouTube recommends RTMPS, the encrypted extension of RTMP. Its current encoder guidance lists H.264, H.265 or HEVC, and AV1 video for RTMP and RTMPS, with AAC or MP3 audio and frame rates up to 60 frames per second. The useful choice depends on what your FFmpeg build supports and what the selected YouTube ingest profile accepts.
The encoder guidance recommends constant bitrate encoding and a two-second keyframe interval. It states that the interval must not exceed four seconds. These are output properties, not simply labels in the YouTube event form, so make the FFmpeg video encoder produce settings that match the profile you select.
For H.264, YouTube’s current table lists 5 Mbps as the minimum and 14 Mbps as the recommended bitrate for 1080p30. For 720p30, it lists 3 Mbps minimum and 8 Mbps recommended. These are YouTube’s published encoder figures, not a promise that a particular Linux host, home connection or source file will sustain them. If your upload connection is uncertain, a lower resolution can be a more dependable starting point than selecting 1080p and repeatedly losing the connection.
| Example H.264 profile | YouTube minimum video bitrate | YouTube recommended video bitrate |
|---|---|---|
| 720p30 | 3 Mbps | 8 Mbps |
| 1080p30 | 5 Mbps | 14 Mbps |
Treat the table as a starting reference rather than a complete command specification. You still need to select an audio bitrate, pixel format, keyframe interval and encoder preset that your machine can maintain. If you change resolution or frame rate, return to YouTube’s current table instead of carrying the old bitrate across unchanged.
The YouTube streaming tips also recommend testing with audio and motion similar to the intended broadcast. A static image with quiet audio can hide problems that appear when the real channel contains music, talking, animation or scene changes. Open the Live Control Room preview before publishing and check both picture and sound.
YouTube’s archive behaviour also affects planning. YouTube says streams under 12 hours are automatically archived. Do not assume that a single uninterrupted broadcast lasting 12 hours or more will produce one complete replay under that rule. If an archive matters, plan a suitable recording or stream-segmentation approach and verify the current platform behaviour before launch.
Create or loop the media feed with FFmpeg
For a prerecorded file, the general FFmpeg pattern is to read the input at its natural playback rate, loop it, encode or copy compatible streams, and send the result to an FLV-formatted RTMP or RTMPS destination. A basic shape looks like this:
ffmpeg -re -stream_loop -1 -i /srv/media/channel.mp4 \
-c:v libx264 -preset veryfast -b:v 8M -maxrate 8M -bufsize 16M \
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 48000 \
-f flv "rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
This is a configuration shape, not a universal production command. The example uses the 720p30 recommended video bitrate from YouTube’s table, but it does not force the input to 1280 by 720. Add an explicit video filter or output size only after deciding what the source and event should be. If you choose 1080p30, use the corresponding current YouTube guidance and confirm that the Linux host can encode it in real time.
The -re option asks FFmpeg to read the file at approximately its normal playback rate rather than sending it as quickly as the machine can read it. -stream_loop -1 repeats the input indefinitely. The -g 60 and -keyint_min 60 values correspond to a two-second interval at 30 frames per second, but the correct values change with frame rate. A 60-frame GOP at 60 fps is not a two-second interval.
Do not use stream copy merely because it consumes less CPU. Copying can be appropriate when the source streams already match the required codec, format, bitrate behaviour and timing. It can also preserve a source that is unsuitable for the selected ingest profile. When in doubt, inspect the file with ffprobe, then decide whether to transcode video, audio or both.
For example:
ffprobe -hide_banner /srv/media/channel.mp4
Look for the video codec, dimensions, frame rate, pixel format, audio codec, sample rate and duration. A file can play correctly in a desktop player while still producing awkward timestamps or an incompatible audio stream at the live output. Test the exact output with a private or unlisted event before using it for a public channel.
A single file is the simplest loop, but it has an editorial cost. Every repeat returns to the same opening frame and the same audio sequence. For a lecture, news loop or devotional rotation, use a carefully ordered playlist or a pre-rendered programme if repeating one file would be distracting. The article on preventing a lecture playlist from repeating the same video deals with the content side of that problem.
Aspect ratio deserves a separate check. YouTube can display a vertical or square source, but the available viewing space and presentation are different from a conventional landscape stream. Read about vertical and square video on a 24/7 stream before selecting a canvas simply because the source file has that shape.
Set output recovery behaviour
FFmpeg has a documented FIFO muxer pattern for temporary output failures. The FFmpeg formats manual describes using the FIFO muxer with real-time processing, recovery attempts and a one-second wait between attempts. A representative output section is:
-f fifo -fifo_format flv \
-drop_pkts_on_overflow 1 \
-attempt_recovery 1 -recovery_wait_time 1 \
"rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
The relevant FFmpeg FIFO documentation explains the available options and their interaction. The FIFO muxer can continue handling the stream during a temporary output problem and attempt to reconnect. That is useful for a short network interruption, but it is not the same as proving that the YouTube event, source file, host or process will remain healthy indefinitely.
Do not interpret -attempt_recovery 1 as a promise that every connection drop will recover. Recovery may fail if the network remains unavailable, the event has ended, the key is invalid, YouTube rejects the connection, the host runs out of resources, or the input itself has stopped producing frames. The setting also needs checking against the FFmpeg version installed on the target machine.
If you combine the FIFO settings with a looped source, test the complete command rather than testing each fragment separately. A command may reconnect successfully while still producing unusable timestamps or silent audio. Conversely, a clean media feed may be terminated by a service manager before FFmpeg gets an opportunity to recover.
There are two distinct failure layers to plan for. FFmpeg’s output recovery deals with a temporary problem while the process is still running. A service manager deals with a process that exits. Neither layer repairs a dead machine, a full disk, a deleted media file, a revoked key or a sustained broadband outage.
Run FFmpeg reliably as a Linux service
If the target system uses systemd, create a service rather than relying on a terminal multiplexer or an open SSH session. The exact locations, user names, permissions and hardening options vary by distribution and by how systemd is configured, so treat the following as a model to adapt and validate, not as a universal unit.
[Unit]
Description=YouTube FFmpeg channel
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/srv/media
EnvironmentFile=/etc/streamer/youtube.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/media/channel.mp4 -c:v libx264 -preset veryfast -b:v 8M -maxrate 8M -bufsize 16M -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -c:a aac -b:a 128k -ar 48000 -f fifo -fifo_format flv -drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This example illustrates the relationship between startup ordering, a non-root service account, an environment file and process restart. It does not establish that those exact paths or directives are correct on your distribution. Check the installed FFmpeg path with the tools available on the host, verify that the service user can read the media, and validate the unit with your distribution’s systemd documentation before enabling it.
Do not put a real key directly into a unit that will be copied or displayed. A protected environment file can reduce accidental exposure, but it is still a secret-bearing file and must have suitable ownership and permissions. Be aware that command-line arguments may be visible to local users through process inspection, depending on the system. Use the least exposed arrangement available on the host and rotate the key if it is disclosed.
After saving a unit, the normal systemd workflow is to reload its configuration, start it, inspect its status and enable it for future boots. The precise commands are familiar on systemd systems, but a successful start only proves that the process launched. It does not prove that YouTube is receiving a healthy picture and audio feed.
Test a reboot before calling the setup unattended. Confirm that the network becomes usable, the service starts once, the media path is mounted, the process has the expected permissions and the YouTube preview receives the feed. If the service starts before a required disk is available, a correct FFmpeg command can still fail immediately.
Restart=on-failure is deliberately narrower than a claim that FFmpeg will always restart. It normally covers an abnormal process exit, not every possible condition in every service configuration. A process can remain alive while producing no useful media, and a service can be prevented from restarting by local limits or administrative policy. Observe the result instead of assuming the unit has solved the problem.
Check logs, connection and YouTube stream health
Use three views when diagnosing the channel: the Linux service state, the FFmpeg log, and YouTube’s Live Control Room. Each answers a different question. The service state tells you whether a process exists. FFmpeg tells you what it is reading and attempting to send. YouTube tells you whether the received stream is acceptable to the platform.
For a systemd service, inspect its status and recent journal entries using the commands appropriate to the target machine. Look for repeated exits, permission errors, missing files, connection failures, encoder errors, timestamp warnings and audio-related messages. If you have redirected FFmpeg output to a file, check rotation and disk usage as well. A log that grows without limit can become a failure of its own.
In Live Control Room, check the preview before publishing and monitor stream-health messages while the test runs. Confirm that the video is moving, the audio is present and the quality is appropriate for the intended resolution. YouTube’s guidance recommends monitoring both audio and video rather than treating a connected status as sufficient.
Keep a small operating record during the first long test. Note when the process started, when the preview became available, whether the source loop returned to its beginning, whether the audio remained synchronised and what happened when the network was briefly interrupted. This is more useful than assuming that a short successful launch represents a full night of operation.
Do not confuse a network connection with a healthy broadcast. A host can have an active internet connection while the upload is congested, the event is no longer accepting data, or FFmpeg is stuck on a source read. Similarly, YouTube can display a connected encoder while reporting video or audio quality problems. Match the symptom to the layer before changing options.
Bitrate problems often appear as buffering, quality warnings or a blurry image. YouTube’s table is a platform recommendation, while the source bitrate and the encoder’s actual output may differ. If a scene becomes soft or blocky, the guide to a blurry fireplace stream explains the practical causes worth checking before simply increasing bitrate.
Plan for media and network failures
Write down what should happen for each likely failure instead of treating “24/7” as a single setting. If the input file is missing, FFmpeg may exit and the service manager may restart it repeatedly. If the file is corrupt at a particular point, the same restart can return to the same fault. Keep a known-good fallback file available and test how your chosen command handles it.
If the network drops briefly, the FIFO recovery settings may attempt to reconnect. If the outage lasts longer, the service can still be running without delivering a usable broadcast. Set expectations around that distinction and use YouTube’s stream-health view to confirm recovery. Do not publish a message claiming the channel is live merely because the Linux process has not exited.
Power interruptions and reboots are separate from application recovery. Configure the host to restart after a power event where appropriate, and check that the media storage is available at boot. A battery-backed setup may help a local installation, but no generic hardware is required by FFmpeg and no battery arrangement removes the need to test the actual machine.
Keep enough free disk space for logs, temporary files and any local recordings. A full filesystem can prevent logs from being written, stop a recording, or interfere with normal service operation. Review old files rather than allowing a successful stream to hide a growing storage problem.
Plan key management as part of operations. If someone leaves the project, if the key appears in a support ticket, or if a script is published accidentally, reset it in YouTube Live Control Room and update the service configuration. Never paste the key into a public issue or include it in a screenshot used for troubleshooting.
Content failure also matters. Copyright claims, unsuitable music, a silent segment or a broken playlist can make a technically connected stream a poor channel experience. YouTube’s platform rules and current live-stream guidance should be checked for your content and channel circumstances. Technical continuity does not establish permission to broadcast a particular recording.
Finally, decide whether self-management is worth the ongoing work. Linux with FFmpeg is a sensible choice when you need direct control and already have a dependable host. A managed option can be more suitable when your main requirement is to keep a prerecorded YouTube channel running while avoiding server maintenance, but confirm that the service supports your exact file, channel and workflow before relying on it.
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 FFmpeg loop one video on YouTube Live indefinitely?
It can repeatedly read a prerecorded file with -stream_loop -1 and send the resulting feed to a YouTube ingest endpoint. That does not guarantee an uninterrupted broadcast, because the host, source, network, event and platform can each fail. Test the complete command with the actual media and output profile before publishing it.
Will FFmpeg automatically reconnect when the RTMPS connection drops?
FFmpeg’s FIFO muxer documents recovery attempts for temporary output failures, including a one-second recovery wait in its example. Recovery is conditional, not guaranteed, and it does not replace process supervision. Check the installed FFmpeg documentation and confirm the result in YouTube Live Control Room.
Should I use systemd to run a 24/7 FFmpeg stream?
Use systemd when it is the service manager on your Linux system and you are prepared to adapt and test the unit. It can start the process at boot, keep it separate from an interactive shell and restart it after some process failures. Distribution-specific paths, permissions, boot ordering and policies still need validation on the target machine.
Does YouTube automatically archive a multi-day live stream?
YouTube says streams under 12 hours are automatically archived. Do not apply that statement to a stream that reaches or exceeds 12 hours without checking the current official guidance. If the replay matters, plan recording or segmentation separately.