A Debian machine can send a prepared video to YouTube Live continuously by looping the input in FFmpeg and publishing to the stream details from YouTube Studio. For a dependable setup, you also need to check channel eligibility, match output settings to YouTube’s guidance, supervise the FFmpeg process and monitor the broadcast separately.
A looping command is only one part of the arrangement. It cannot guarantee uninterrupted streaming: the host, network, media, encoder and YouTube ingest can each need attention, so test the whole path and plan how to recover.
Check channel live-stream eligibility
Before installing packages or preparing a service, confirm that the channel is allowed to go live. YouTube’s live-streaming eligibility guidance says the channel must be verified and must not have had live-streaming restrictions in the past 90 days; it also states that the streamer must be at least 16. Check the current page and the channel’s status rather than assuming an older setup still qualifies.
Eligibility is separate from the Debian host. A correctly configured FFmpeg process cannot resolve a channel restriction, and a local preview cannot substitute for confirming that YouTube Studio accepts the broadcast. If this is a new channel or you have not streamed recently, resolve the account steps before planning an unattended schedule.
Decide what “24/7” means for your channel as well. It may mean keeping a prepared loop ready to publish at all times, not necessarily one broadcast that continues indefinitely without a break. YouTube’s guidance says streams under 12 hours are automatically archived. It does not establish every outcome for a longer continuous stream, so check current Studio behaviour if archiving or the handling of long broadcasts matters to you.
Create or select a YouTube Live stream
In YouTube Studio, create a live stream or select an existing one, then use the stream’s server URL and stream key in the encoder. YouTube’s encoder setup instructions describe connecting an encoder and testing the stream. Follow the instructions currently shown in Studio: ingest details and scheduling choices belong to the specific broadcast, not to a generic Debian command.
A scheduled event and a reusable stream configuration serve different operational needs. A scheduled event can help you present a broadcast at a chosen time; a reusable stream setup may suit a channel that regularly sends the same kind of programme. Check the current Studio controls and make sure you understand which event or stream you are connecting to before starting FFmpeg. Do not assume that restarting the encoder will create or schedule a new event for you.
After copying the connection details, use YouTube Studio’s preview and stream-health messages to confirm that the correct video and audio are arriving. A successful process launch only means FFmpeg started. It does not prove that YouTube has accepted the ingest, that viewers can see the intended picture, or that the stream is healthy.
If you are weighing a local Debian host against a rented machine, the trade-off is control versus remote availability and ongoing cost. A local host can use hardware you already have, but your power and network path remain part of the broadcast. A rented Linux host can be useful when your own connection or power is less dependable, but it introduces a recurring cost and still needs configuration and monitoring. The Hetzner Cloud setup guide covers that hosted route; it does not make it the right choice for every channel.
Protect the stream URL and private key
Treat the stream key as a credential. Anyone who obtains it may be able to send a signal to the associated stream, so do not include a real key in a public command, screenshot, repository, support post or log excerpt. Use an obvious placeholder in notes and examples, such as YOUR_STREAM_KEY, and copy the real values only into the private configuration used by your encoder.
YouTube provides the server URL and stream key through Studio for the selected stream. YouTube recommends RTMPS for encrypted ingestion; consult its RTMPS guidance and use the secure ingest URL provided for your stream when available. Encryption protects the connection in transit, but it does not make careless handling of the key safe.
Avoid putting the real key directly into a shell command that you paste into a terminal or save in shell history. For a Debian service, keep sensitive values in a configuration file readable only by the account that needs them, or use another suitable secret-handling method. Do not put the key in a broadly readable service unit. Restrict access to the file and to the account that runs FFmpeg, and rotate the key in Studio if it has been exposed.
A placeholder in a published command is not a substitute for protecting the private value on the machine. Check file permissions, backups and diagnostic output as part of setup. A service can be restricted to the media and configuration it needs, rather than running with broad access by default.
Prepare media and choose YouTube-supported output settings
Start with a finished media file that plays correctly from beginning to end. Check that its video dimensions, frame rate, audio track and duration are deliberate, and watch across the point where the loop will return to the beginning. An edit that looks harmless in a short preview can create a visible jump or an audio gap every time it repeats.
For RTMP or RTMPS ingest, YouTube lists H.264, H.265 and AV1 as supported video codecs, and AAC or MP3 for audio. Its encoder guidance recommends constant bitrate (CBR), a two-second keyframe interval and a maximum interval of four seconds, with frame rates up to 60 fps. Use YouTube’s current encoder settings and bitrate table to choose a bitrate for the resolution and frame rate you actually plan to send; do not reuse a number from an old tutorial as though it fitted every profile.
H.264 video with AAC audio is a practical compatibility profile, not the only supported combination. Your installed FFmpeg build must include the encoder you select, and your host needs enough compute capacity to encode the chosen picture at the chosen frame rate. If the file is already encoded appropriately, you may investigate whether stream copying is suitable, but test the result against YouTube’s ingest guidance rather than assuming it will match the profile you want.
Resolution and bitrate are not goals to maximise in isolation. A higher-quality profile may require more upload capacity and encoding headroom; if either varies, dropped or unstable output can be worse for viewers than a more modest profile. Test over the actual connection and with the kind of movement and audio that will be present in the broadcast. For a closer look at choosing a workable rate, see how to compare video quality at different bitrates. If your upload path is constrained, the guide to streaming with a slow internet connection helps frame the quality trade-off.
Install FFmpeg from the packages available for the Debian release you intend to run, then inspect the installed version and available encoders. Debian’s FFmpeg manual documents the command-line options, but package versions and build features can differ. Check locally with ffmpeg -version and ffmpeg -encoders; do not assume a command copied from another distribution has the same codec support.
Run FFmpeg with a looping input
FFmpeg’s -stream_loop -1 option requests infinite looping of an input. Because FFmpeg options generally apply to the next input or output, put input options before the corresponding -i, and output options before the destination. The following is an illustrative command shape, not a tested or crash-proof recipe. Adapt it to the media, the encoders in your Debian build, YouTube’s current bitrate table and the exact RTMPS URL shown in Studio.
ffmpeg -re -stream_loop -1 -i /srv/live/loop.mp4 \\
-c:v libx264 -preset veryfast -b:v 2500k -maxrate 2500k -bufsize 5000k \\
-r 30 -g 60 -pix_fmt yuv420p \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://INGEST_URL/YOUR_STREAM_KEY'
The example values are only illustrative; in particular, do not treat its bitrate as a universal recommendation. The example assumes libx264 is available, which you should verify on the target machine. Check the chosen output against YouTube’s guidance and test a private or otherwise suitable stream before relying on it for an unattended schedule. With -re, FFmpeg reads the file at a rate intended to match real time; confirm how the full command behaves with your source formats.
If your media has no audio track, decide deliberately how the output should provide audio rather than assuming an audio-less file will behave as expected at ingest. If you combine separate audio and video playlists, verify that their loop points and timing stay aligned; a basic single-input loop does not solve synchronization across independent sources. Listen and watch across several transitions during a test.
Do not mistake “the command did not exit” for “the channel is broadcasting correctly”. Watch FFmpeg’s output for errors, check that the YouTube preview shows the intended material and verify that audio is present. Stopping the foreground process is useful for an initial test; an unattended setup needs a service manager or another deliberate process supervisor.
Supervise the process and handle interruptions
On Debian, systemd can run FFmpeg as a service and start it again if it exits unexpectedly. The systemd service documentation describes restart behaviour; Restart=on-failure is a common policy for a long-running service, and a delay such as RestartSec=5s can prevent an immediate retry. Restarts are subject to start-rate limits, so do not configure an unbounded rapid loop that repeatedly launches a command which cannot work.
Run the service under a dedicated, restricted account where practical. Give it access to the media file and private configuration it needs, and no more access than necessary. Keep the stream key out of a broadly readable unit file. Test how the service behaves after a deliberate process stop and after a host reboot, then confirm that the expected stream actually returns in Studio. A systemd restart can restore a process; it cannot repair a bad key, an unavailable file, broken network access or a rejected ingest.
When FFmpeg exits, inspect the service status and journal before making repeated changes. systemctl status your-service gives a quick view of the unit, while journalctl -u your-service shows its logs. Look for a missing input, unsupported encoder, authentication or ingest error, permission failure, or resource problem. Resolve the cause instead of merely raising restart frequency.
There are several failure domains to plan for: the Debian host can lose power, the network can drop, FFmpeg can terminate, and the broadcast can have a problem even while the process remains active. A rented host and a local machine shift which of these problems you manage directly; neither removes the need to test the complete route. If you prefer a graphical encoder and reconnect controls over a command-line service, the OBS reconnect-delay guide covers a different operating approach. Choose based on how you will diagnose the system at night, not just on which setup is quickest to launch.
Monitor stream health and test recovery
Monitor two things separately: process health on Debian and broadcast health in YouTube Studio. The service may report as active while the media is frozen, the audio is missing, the ingest is unhealthy or YouTube is displaying a warning. Conversely, a brief reconnect may leave the process running while Studio still needs time to show the current state. Use Studio’s preview, connection messages and stream-health indicators alongside service status and logs.
Run a deliberate test before relying on the system. Use media with movement and audio similar to the actual programme, check the picture and sound, and observe the loop transition. Test the output profile and the real network path, not just a local file decode. YouTube recommends testing and monitoring the stream; its current encoder guidance is the authority for settings and health messages, so check it again when changing profiles.
Then test recovery in a controlled way. Stop the FFmpeg process and confirm that the supervisor responds according to the policy you chose. If suitable, simulate a brief network interruption without risking a public event, and check both the logs and Studio’s response. Do not infer from one successful restart that every interruption will recover automatically. A changed key, persistent network failure, invalid input or restart-rate limit can prevent recovery.
Write down a small recovery procedure that someone can follow without guessing: where the service status and logs are, where the protected configuration lives, how to verify the key in Studio without exposing it, and how to confirm that viewers receive the expected programme. Keep the procedure current when the media, stream configuration or Debian release changes. A short checklist is more useful during an overnight fault than a long command copied without context.
For a channel that must be available at all hours, consider whether one continuous broadcast suits your archiving and scheduling needs. YouTube documents automatic archiving for streams under 12 hours, but that does not settle every case for longer sessions. Check Studio’s current behaviour and decide whether planned shorter sessions or a restart schedule better fit your publishing needs. Neither approach removes the need to test how a broadcast ends and resumes.
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 stream uninterrupted?
No. It loops the input file, but it does not guarantee that FFmpeg, the Debian host, the network or YouTube ingest will remain healthy. Supervise the process and monitor Studio separately.
Which bitrate should I use?
Use YouTube’s current bitrate table for your selected resolution and frame rate, then test that profile on the upload connection and hardware you will actually use. The value in an example command is not a universal setting.
Can I run this with my computer switched off?
Not if FFmpeg is running only on that computer: the encoder needs an operating host and a working connection to YouTube. StreamNeo is for the different case where you upload a video and want the prepared broadcast to keep running without leaving your own computer on; it is YouTube-only.
Will YouTube archive a continuous 24/7 broadcast?
YouTube says streams under 12 hours are automatically archived. Its cited guidance does not establish every outcome for a longer continuous stream, so check current Studio behaviour before choosing a schedule if the archive matters to you.