A Debian computer can use FFmpeg to send a media file to YouTube Live and repeat it continuously. The looping option handles repeated playback; it does not guarantee an uninterrupted broadcast, which also depends on the computer, network, credentials and YouTube ingest.
This guide takes you from checking channel eligibility to preparing media, configuring an output and monitoring the stream. Treat each test as part of the setup: a command that starts successfully is not proof that it will keep running through a night or a network interruption.
Check that your channel can go live
Before installing software or preparing a stream, open YouTube Studio and confirm that live streaming is available for your channel. YouTube requires a verified channel and no live-streaming restrictions in the previous 90 days. Check the current YouTube eligibility guidance, because channel status and platform requirements can change.
If this is the first time you enable live streaming, do not plan a same-day launch. YouTube says first-time activation may take at least 24 hours. Wait for the feature to become available in Studio, then check that the account you intend to use can create a live stream. Activation timing is not a reason to expose credentials or skip testing once access appears.
Decide whether this stream is a one-off event or a continuing radio-style broadcast. That affects how you create it and how you communicate the viewing URL, but it does not change the need to check channel access, encoder settings and stream health. For a long-running channel, keep a record of the intended event, its schedule or persistence settings, and who is authorised to manage it.
A 24/7 stream also needs an operating plan, not just a media file. Decide who will notice a failed broadcast, how they will reach the host, and what they will check before restarting. If you are considering a remote host rather than a Debian computer at home, the practical trade-offs are discussed in this guide to an affordable VPS for an always-on YouTube stream.
Create the event and retrieve its URL and key
In YouTube Studio, use Live Control Room to create or schedule an encoder stream. Select the event you mean to operate and note its stream URL and stream key from the encoder settings. These credentials are specific to the intended stream configuration; do not assume a key copied from an earlier event is the right one.
YouTube provides the ingest details that an encoder such as FFmpeg needs. Its encoder settings documentation describes the supported configuration and workflow. Keep Live Control Room open during initial testing so you can see the preview and any health messages while FFmpeg sends data.
For this workflow, YouTube recommends RTMPS. It is RTMP carried over TLS/SSL, so use the RTMPS URL shown for your event rather than substituting an address from an old tutorial. The key is generally appended to the destination in the encoder configuration; the exact placement depends on how you form the FFmpeg output URL. Use the current URL and key displayed in Studio, not a guessed pattern.
When a stream is scheduled, distinguish the public watch link from the encoder destination. The watch link is for viewers; the ingest URL and key are for the software sending the broadcast. Keep notes labelled clearly so you do not accidentally send the key to someone who only needs the viewing page.
Protect the stream key
Treat the stream key like a password. Anyone who obtains it may be able to send content to the associated stream, so keep it out of shared shell history, public configuration files, screenshots, chat messages and logs. Do not paste a real key into an example command that you plan to publish or share.
A command typed directly into a shell can remain in that shell's history. A private configuration file is not automatically safe either: permissions, backups, synchronisation and account access all matter. Limit access to the account and machine that need the credential. For a small operation, agree who can retrieve or reset it, and avoid sending it through a group chat merely to make a launch easier.
In a schematic command, use a placeholder such as YOUR_STREAM_KEY, never the actual credential. If the key is exposed, reset it in YouTube Studio and update the encoder configuration before resuming. Do not assume that deleting a screenshot or removing a line from a file revokes a key that someone may already have copied.
Keep the key separate from the public watch URL when you make operating notes. The distinction is especially useful if a helper is asked to check whether the event is visible: they can use the viewer link without needing access to the credential. A stream key is not a substitute for channel access controls, and it should not be shared as a troubleshooting shortcut.
Prepare a rights-cleared media source
Choose audio, recordings and artwork that your channel has permission to use in a YouTube live broadcast. A file being available online, included in a software package or licensed for personal listening does not by itself establish that you can rebroadcast it. Secure the appropriate rights for the material and the way you intend to use it; do not treat a particular licence label as automatic clearance for every use on YouTube.
Start with a source you can inspect and play locally. On Debian, install FFmpeg from the package repository for the Debian release you have selected, then use its probing tools to check what streams the file contains. Confirm that it has the expected audio and, if you are sending video, a video stream with the dimensions and frame rate you intend to use. An audio-only radio stream still needs an output format appropriate to the YouTube event configuration.
A file that already matches the required output can demand a different amount of processing from one that needs conversion. Actual load depends on the source, filters and selected output settings, so do not rely on a generic CPU or memory figure as proof that a host is adequate. Run the intended encode and watch system load while testing. A modest-looking visual loop can still require substantial work if FFmpeg must transcode it continuously.
Inspect the start and end of the media as well as its middle. A single file repeated indefinitely can have an audible or visible jump at the boundary. A scheduled set of tracks with transitions is a different problem from looping one file; do not assume a simple loop produces seamless joins. If your station is devotional, the guide to looping devotional meditation music covers related programming considerations, but you still need to validate your own source and rights.
Configure FFmpeg looping and pacing
FFmpeg has input options for repeating and pacing local media. -stream_loop -1 means repeat the input indefinitely, while -re reads file input at its native rate. Because both are input options, place them before the corresponding -i input. A schematic beginning looks like this:
ffmpeg -re -stream_loop -1 -i /path/to/authorised-media.mp4 ...
The ellipsis is intentional: this is not a complete production command. A working output also requires suitable stream mapping, codecs, filters if needed, bitrate and the destination URL formed with the event's stream key. Those choices depend on what the source contains and what you selected in YouTube. Copying a partial line and assuming it is ready to broadcast can result in no audio, an incompatible output or a stream that fails to reach the event.
The two options solve different parts of the input behaviour. The loop option asks FFmpeg to reopen the input after it reaches the end. The pacing option avoids reading a file as quickly as the computer can process it. Without pacing, a file-based source may be consumed faster than real time rather than behaving like a live broadcast. Verify the result in Live Control Room; command-line output alone does not tell you what viewers receive.
A looped file is not a playlist scheduler. It will repeat the same input, and the sources reviewed for this guide do not establish a playlist method or promise gap-free transitions between separate items. Listen to the boundary and inspect the picture during a test. If the boundary is distracting, edit the source or use a playback approach whose transitions you have tested rather than attributing the problem to YouTube.
Choose compatible output settings
Set output settings to match the event and the source. YouTube's current encoder guidance lists H.264, H.265/HEVC and AV1 for video over RTMP/RTMPS, and AAC or MP3 for audio. For a straightforward SDR setup, H.264 video with AAC audio is a practical starting point, provided your file, encoder and selected output parameters agree. Check YouTube's current recommended encoder settings before launch.
YouTube recommends constant bitrate (CBR), a two-second keyframe interval, and says the keyframe interval should not exceed four seconds. It permits frame rates up to 60 fps. These are platform recommendations, not a promise that every source or network will work at every setting. Set the keyframe interval deliberately and make the video bitrate appropriate to the chosen resolution and frame rate.
For context, YouTube's encoder settings page lists 5 Mbps as its recommended H.264 bitrate for 1080p at 30 fps, and 8 Mbps for 720p at 60 fps, as accessed in 2026. These are YouTube recommendations for those particular combinations, not independent test results. Do not infer from them that 1080p is always preferable: a lower-resolution stream at a sustainable bitrate may be a better fit for your source and connection.
| Output choice | YouTube-published H.264 recommendation | What to weigh |
|---|---|---|
| 1080p at 30 fps | 5 Mbps | More detail, with a sustained upload requirement that includes audio and overhead |
| 720p at 60 fps | 8 Mbps | Higher frame rate, but a higher listed video bitrate than the 1080p example |
The figures are not a like-for-like quality ranking, and YouTube publishes recommendations for other combinations as well. Consult the current table for your selected codec, resolution and frame rate rather than extrapolating from these two rows. Total stream bitrate matters when planning the network, including audio and any additional feed you send.
For a radio station with a static image or modest visual, the picture may not need a high frame rate. Choose a setting that suits what viewers will see and that the host can encode and upload steadily. If the video needs conversion, measure the actual host load during a long enough test to expose heating or resource constraints; the documentation does not specify a minimum Debian machine for this task.
Test upload capacity and start the stream
Measure the available upload capacity on the actual connection and at a time representative of normal use. YouTube recommends 20% upload headroom beyond the total stream bitrate and advises using a reliable connection. Its streaming tips explain the need to check upload capacity. This headroom is a recommendation, not a guarantee against congestion, outages or changes in the route to YouTube.
Compare sustained upload capacity with the total bitrate you have configured, not only the video number in a settings table. If your output is 5 Mbps for video, the overall stream also includes audio; allow room above that total. If the household or office connection is busy with other uploads, the capacity left for FFmpeg may be lower. YouTube Help recommends running a speed test to test your upload bitrate, but a single result does not demonstrate that a connection will remain steady all night.
Before a real launch, run a test with the same input, output settings and host you plan to use. Watch the Live Control Room preview, confirm the audio is present and balanced, check the image and loop boundary, and look for stream health messages. Confirm the public viewing page is reachable when you expect it to be. This catches errors that a successful local FFmpeg process cannot show, such as an incorrect event key or an ingest warning.
Start the encoder only after the event is ready in Live Control Room. Keep the key private when entering the destination, and compare the preview against the intended source before announcing the stream. If changing resolution or bitrate, repeat the test: a setting change can alter both the network requirement and the host's encoding work.
Monitor and troubleshoot the broadcast
A continuous broadcast relies on several parts working together: FFmpeg, the Debian host, power, network connectivity, the event credentials and YouTube ingest. A looping input addresses only playback repetition. A process manager or restart policy may help restart a process that exits, but it cannot fix an expired or reset key, a failed machine, a lost connection or an ingest-side problem.
Watch FFmpeg's output and keep useful logs private, without recording the stream key. Check Live Control Room for preview and stream health messages, and arrange an alert or a human check that can distinguish a dead process from an ingest or network issue. Define what counts as a failed stream and who will respond. After a reconnect, verify the preview and audio again instead of assuming an automatic restart restored the broadcast correctly.
For a host in your home or shop, consider power cuts, router restarts and the internet connection shared with other people. For a remote Debian host, consider how you will access it when the process is unhealthy and whether you can review logs without exposing credentials. Neither hosting category removes the need to check the machine and connection. A power-loss recovery guide for a 24/7 music stream may help you think through one failure mode, but no restart setting covers every failure.
If FFmpeg stops, inspect its last error and the host's system logs before restarting repeatedly. Check that the file is still present and readable, that disk space is available for any logs, that the destination and key correspond to the event, and that the network can reach the ingest service. If the local process appears healthy but the preview is missing or degraded, use Live Control Room's messages to narrow down whether the issue is encoding, upload or ingest. Make one change at a time and retest.
A 24/7 broadcast is not necessarily one complete replayable archive. YouTube's encoder workflow documentation says streams under 12 hours are automatically archived; that does not establish that an uninterrupted stream running beyond that duration becomes one complete archive. If viewers need a replay, plan a separate recording or shorter broadcast segments and confirm the current platform behaviour rather than relying on a single indefinite event.
If ongoing attention to the host, process and reconnects is the part you cannot reliably cover, StreamNeo removes that specific local-machine burden by running an uploaded video as a YouTube live stream with your computer switched off; you still need to prepare the file and manage your channel and content rights.
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 forever in FFmpeg?
Use -stream_loop -1 before the input's -i option to repeat that input indefinitely. For file-based playback, -re is also an input option and reads at the file's native rate. Neither option configures a compatible YouTube output or guarantees that the stream stays online.
Where do I put my YouTube stream key?
Use the key associated with the intended Live Control Room event as part of the FFmpeg destination configuration, alongside the RTMPS URL shown by YouTube. Keep it private as you would a password, and do not put it in public examples, screenshots or shared notes. Reset it in Studio if it is exposed.
What bitrate should I use for a 24/7 YouTube stream?
Use YouTube's current recommendation for your selected codec, resolution and frame rate, then account for the total stream bitrate and leave the recommended upload headroom. YouTube lists 5 Mbps for H.264 at 1080p/30 fps and 8 Mbps for H.264 at 720p/60 fps in its encoder guidance accessed in 2026. Those recommendations do not guarantee that your host or connection can sustain the stream, so test the intended configuration.
Will a 24/7 stream be archived?
YouTube says streams under 12 hours are automatically archived in its encoder workflow documentation. That does not mean an uninterrupted 24/7 broadcast will be preserved as one complete archive. If a replay matters, plan for that separately and check YouTube's current guidance.