To loop a prerecorded video to YouTube Live from Debian, install FFmpeg, place -stream_loop -1 before the input, pace the file with -re, and send the output to the RTMPS URL and stream key shown in YouTube Studio. This makes the file repeat while the process runs; it does not guarantee an uninterrupted broadcast.
You still need a suitable source file, enough sustained upload capacity, a protected stream key, and a way to notice and respond to failures. The steps below give you a starting command and explain what to check before leaving it unattended.
What you need before starting
Use a Debian machine with a stable internet connection, an FFmpeg build that includes the encoders you intend to use, and a local video file with a known video and audio stream. You also need access to your YouTube channel’s Live Control Room. You can prepare the file and install FFmpeg before setting up the event, but do not start a public broadcast until you have checked the event settings and preview.
A prerecorded file is different from a camera or other live source. For a file, FFmpeg can read at its native rate and repeat it at the end. A live source already arrives in real time, so applying file pacing without understanding that input can cause problems. This guide assumes one local MP4 containing video and audio. A file without audio, a playlist, or an unusual codec needs a deliberate adjustment and a test.
Decide on resolution and frame rate based on the source, the visual content and the upload capacity of the host. A static devotional image with audio may not need the same video settings as a moving news loop. Do not upscale a small source merely to choose a larger output size: scaling cannot restore detail that is not in the file.
If you are choosing between a local Debian computer and a remote machine, compare the practical constraints rather than assuming either is automatically more reliable. A local computer depends on household or office power, network and whether someone can respond to a problem. A remote host adds a recurring cost and provider-specific limits, and you must confirm sustained upload capacity and acceptable use with that provider. For a broader comparison of operating approaches, see free and paid cloud services for 24/7 YouTube streaming.
Install FFmpeg on Debian
On a Debian system with configured package repositories, install the distribution package:
sudo apt update
sudo apt install ffmpeg
The Debian package version varies by release and can change as packages are updated. Check the package available for your own release rather than copying a version number from a guide written for a different Debian version. The Debian FFmpeg package listing is a primary source for package information. After installation, check what is present:
ffmpeg -version
This identifies the installed FFmpeg build. It does not confirm that your media will encode successfully or that the host can sustain the chosen output settings. If FFmpeg reports an unknown encoder when you try the command later, check the build and package available for your release before changing the command at random.
Debian also publishes FFmpeg documentation, including its protocol documentation. The documentation is useful for understanding the RTMP-family output and available options, but a documented option does not remove the need to test your own input file, network route and YouTube event.
Get the YouTube ingest URL and stream key
In YouTube Studio, create or select a live stream and open its Live Control Room. Copy the server URL and stream key displayed for the event or encoder. YouTube’s live streaming encoder setup guidance covers connecting an encoder, while its stream settings guidance explains the stream key and related controls.
Treat the stream key as a password. Anyone who gets it may be able to send a feed to your stream. Do not put a real key in a public script repository, a screenshot, a shared terminal transcript, or a troubleshooting post. Avoid pasting it directly into a command that your shell may retain in history. Use a suitably restricted local configuration or service environment, and limit access to it to the account that needs to run FFmpeg.
The example later uses a placeholder URL. Use the exact server URL YouTube shows you, including the scheme and path; do not assume every account or stream has the same endpoint. RTMPS is YouTube’s recommended encrypted transport for the feed to its servers. If you think a key has been exposed, reset it in YouTube Studio and update the encoder configuration before sending another feed.
Starting FFmpeg and making an event public are not always the same step. Depending on the stream’s settings, sending the feed may start the event automatically, or you may need to wait for the preview and select “Go live” in Live Control Room. Confirm the current event behaviour in Studio rather than relying on an assumption from a previous broadcast.
Build the looping FFmpeg command
For a local file with video and audio, this is a starting example. It is illustrative, not a tested command for every Debian release or input. Replace the file path and the placeholder destination locally, and choose bitrates appropriate to the output settings and your connection.
ffmpeg -hide_banner -re -stream_loop -1 -i /path/to/video.mp4 \\
-c:v libx264 -preset veryfast -b:v 8000k -maxrate 8000k -bufsize 16000k \\
-r 30 -g 60 -pix_fmt yuv420p \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
The important placement is before -i: -stream_loop -1 applies to the input and requests indefinite repetition. The -re option paces file reading at its native rate, rather than allowing FFmpeg to send the entire file as quickly as the machine can process it. The output options follow the input. -f flv selects the conventional container for RTMP-family output.
The example’s video rate of 8 Mbps is YouTube’s recommended H.264 ingestion bitrate for 720p30, as listed in its encoder settings. It is not a universal setting: use a bitrate suited to your selected resolution, frame rate, source and sustainable upload capacity. The -g 60 GOP setting corresponds to a two-second interval only when the output is exactly 30 frames per second. If you change the frame rate, revisit the keyframe interval rather than assuming the same GOP value means the same duration.
This example re-encodes video as H.264 and audio as AAC. Re-encoding can make the output more predictable but consumes CPU. If the file already contains compatible H.264 video and AAC audio, stream-copying may reduce CPU use, but it can also fail if the source streams or timestamps do not suit the output muxer or destination. Test the exact media and installed FFmpeg build before using stream copy for a long run. The choice between encoding and copying is a compatibility and resource trade-off, not a guaranteed shortcut.
If the input has no audio, do not assume -c:a aac creates an audio stream. Decide whether the output should have no audio, a separate audio source, or generated silence, then build and test that workflow explicitly. A playlist made from several files also needs testing: transitions can expose format and timestamp differences that are not present when looping one file. For another way of checking loop playback behaviour, see OBS media source playback speed settings for a YouTube loop stream.
Match YouTube encoder settings
The command should reflect the actual stream you plan to send. YouTube’s current encoder guidance lists RTMP or RTMPS transport, H.264, H.265 or AV1 video, AAC or MP3 audio, constant bitrate encoding, and a recommended two-second keyframe interval not exceeding four seconds. This guide uses H.264 and AAC as a broadly compatible example, not because other supported combinations are invalid.
For H.264, YouTube lists these recommended video bitrates:
| Output | YouTube recommended H.264 video bitrate |
|---|---|
| 720p30 | 8 Mbps |
| 1080p30 | 14 Mbps |
| 1080p60 | 17 Mbps |
| 1440p60 | 34 Mbps |
YouTube’s listed H.264 minimums include 3 Mbps for 720p30 and 5 Mbps for 1080p30. These are guidance for encoder settings, not a promise that every source, route or receiving viewer will look the same. Stereo audio guidance is 128 Kbps at 44.1 kHz, and SDR guidance is Rec. 709. Check YouTube’s current encoder settings table before publishing, since its requirements and account options may change.
Choose a frame rate that suits the source. A 30 fps output is a reasonable example for a file mastered at that rate; converting a 60 fps source down may be acceptable for some material but changes motion, while converting a lower-rate file upwards does not add genuine motion detail. Test a representative section with movement and audio, not only a static opening frame. Watch for a mismatch between the selected output and the settings in the Live Control Room.
Keep upload capacity in view as you choose. YouTube recommends leaving 20% headroom beyond the stream bitrate. For example, its 14 Mbps recommendation for 1080p30 implies about 16.8 Mbps of sustained available upload capacity when applying that margin (14 × 1.2). That calculation is derived from YouTube’s guidance, not a separate published capacity guarantee. Measure from the Debian host and the network route you will actually use; another device’s download test does not establish the host’s sustained upload capacity.
Run and monitor the stream
Before a long run, start FFmpeg with a short test and check both the terminal output and YouTube’s preview or stream health display. Confirm the right file is visible, that audio is present where expected, and that there are no encoder or connection errors. A process that remains open in a terminal only tells you that the process has not exited; it does not prove that the feed is healthy or that the YouTube event is live to viewers.
For a temporary test, run the command in a terminal you can observe. For an unattended deployment, run it under a process supervisor or service manager configured to restart after process failure, retain logs, and alert you when the process exits. Also monitor the availability of the source file, disk space if you use local logs or media, network state, and YouTube’s stream health. A restart policy cannot correct an invalid key, missing or corrupt input, incompatible streams, insufficient bandwidth, or an event waiting for a manual action in Studio.
Plan for people and procedures as well as software. Decide who checks the stream, how they receive an alert, and how they will confirm the event is back after a restart. If the stream is important to a business, local information channel or devotional programme, test the recovery steps while someone is available to watch the result. A machine reboot, router outage, power cut or software update can interrupt a local process; automatic restarts reduce some manual work but do not make those causes disappear.
If you need a setup that runs while your own computer is switched off, consider whether maintaining the file, key, monitoring and recovery process on a machine you manage is practical. StreamNeo removes the specific burden of keeping your own computer running for a file-based YouTube broadcast: you upload the file once and provide the YouTube stream key, while the broadcast runs with your computer off and is monitored and restarted automatically if it drops. It is YouTube-only, so this does not replace checking your live event, source rights, key security or current YouTube requirements.
For alternatives involving a compact local device, the Raspberry Pi restart-after-reboot setup explains a different operating approach. A small computer may suit a low-cost installation you are able to maintain, but it still depends on the device, power, network and the supervision you arrange.
One long event also has archive implications. YouTube says streams under 12 hours are automatically archived. Do not interpret that statement as a promise that a longer stream cannot run or will be archived in the same way. For an always-on channel, plan event transitions or restarts and check the current YouTube guidance, archive behaviour and account settings before relying on a single extended event.
Protect the stream key and troubleshoot interruptions
Keep the key out of scripts that are readable by other users, repositories, routine logs and screenshots. If a service manager runs FFmpeg, restrict who can view or change its configuration and environment. Review what your shell, supervisor and logging setup record before putting credentials into them. If the key appears in a place you do not control, rotate it in Studio and replace the old value in the encoder configuration.
When a feed stops or becomes unhealthy, check causes in a practical order. First, inspect the FFmpeg log for a failed input, encoding error or connection closure. Confirm that the file path still exists and that it plays or probes correctly. Next, check the host’s connection and sustained upload capacity, including whether other devices or applications are using the link. Then check YouTube Studio for stream health, key status and event actions still required. This separates problems in the media, encoder, network and YouTube event rather than treating every interruption as an FFmpeg fault.
If FFmpeg reconnects or exits, do not assume a restart alone will solve the cause. A repeated restart against a revoked key, unavailable file or saturated connection can produce a repeating failure. Keep enough logs to identify the error, but do not allow credentials to be written into them. For a related error-specific checklist, see fixing FFmpeg reconnect errors in a nonstop rain-sounds stream.
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 -stream_loop -1 make the YouTube broadcast permanent?
No. It repeats the input for as long as FFmpeg continues to run and can send the feed. The machine, network, media, encoder and YouTube event can still fail or require action, and YouTube’s archive behaviour must be considered for long events.
Why are both -re and -stream_loop -1 before -i?
They are input options for the file in this workflow. -stream_loop -1 requests indefinite looping, while -re paces file reading at its native rate so the file is not sent as fast as the host can process it. Do not apply file pacing blindly to an already-live source.
Can I stream-copy instead of encoding with H.264 and AAC?
Possibly, if the file’s streams and timestamps are compatible with the output and destination. Copying may reduce CPU use, but it is not a universal fit and can fail where re-encoding works. Test the exact file and FFmpeg build before depending on it unattended.
Will YouTube archive a 24/7 stream?
YouTube says streams under 12 hours are automatically archived; that does not establish what will happen to a longer event. Review YouTube’s current guidance and your account’s event settings, and plan any needed transitions or restarts rather than relying on one continuous event.