To loop a video on YouTube Live from a Hetzner VPS, FFmpeg can repeat the input file with -stream_loop -1 and read it at playback speed with -re. Those options control the file and its timing; they do not keep FFmpeg, the network connection or the YouTube broadcast alive by themselves.
The workflow is to prepare a readable video and a suitable VPS, obtain a stream URL and key in YouTube Live Control Room, then send a correctly timed feed and watch its health. Treat the command below as a template to adapt and test, not a tested configuration or a promise of continuous service.
What this setup does, and what it cannot do
FFmpeg reads a media file, optionally encodes its video and audio, and sends the resulting live feed to YouTube. The VPS is the computer running FFmpeg, so your own desktop does not need to stay switched on while the process is running. The VPS still needs to have the file, enough resources for the chosen workload, and a working route to YouTube.
The distinction between looping and staying live is important. -stream_loop -1 tells FFmpeg to repeat an input indefinitely. It does not restart FFmpeg after a crash, repair a failed connection, renew a YouTube broadcast or guarantee that viewers can watch without interruption. Even a perfectly repeating file may stop reaching YouTube if the process or its network path fails.
Plan each part separately: file playback, FFmpeg process management, network delivery, and the YouTube event. For example, if a devotional video ends and FFmpeg reaches its loop point, the input can begin again. If the VPS reboots at that same moment, the loop setting has no effect until some process starts FFmpeg again.
This guide focuses on a single file sent to one YouTube Live stream. If your goal is a playlist that changes between clips, first account for transitions, different aspect ratios and audio continuity. The considerations in fitting playlist videos to the screen can help you plan mixed source material, even though that article covers OBS rather than this FFmpeg workflow.
Prepare the VPS and the source video
Create or choose a Hetzner VPS with a supported Linux distribution, and install FFmpeg from a trusted source for that distribution. This article does not name a server size: the available research does not establish which Hetzner plan can encode a particular file, and performance depends on the resolution, frame rate, codec and encoding settings. Check Hetzner’s current specifications and terms before choosing, then benchmark the actual workload rather than relying on a generic size recommendation.
Put the source video somewhere the account running FFmpeg can read it. Check the path, permissions and file format before connecting to YouTube. A typo in /path/to/video.mp4, an unreadable file or a damaged file can prevent the input from opening; a stream key cannot fix those local problems.
Check which encoders your installed FFmpeg build includes before using an encoder such as libx264. Builds differ, and the presence of the ffmpeg command alone does not show that every requested codec is available. You can also consider stream-copying compatible media rather than encoding it again, but that is only suitable when the source codecs and stream characteristics fit the intended output. Re-encoding offers control over output settings but uses CPU; stream-copying reduces encoding work but does not convert an unsuitable source into a suitable one.
Compare the work your setup needs, not just the file extension. A high-resolution file may need substantial encoding effort if it is being converted, whereas sending compatible compressed streams without re-encoding can require less CPU. Neither option removes the need to send the selected bitrate over the network. If you want to estimate the traffic implications, use the method in estimating monthly VPS bandwidth for a continuous stream, and verify the provider’s current traffic terms before relying on an estimate.
YouTube lists H.264, H.265 and AV1 for video, and AAC or MP3 for audio in its encoder settings guidance. These are platform-supported choices, not evidence that a particular VPS build can encode each one at your target quality. If your source has no audio, confirm that the output is acceptable in YouTube’s preview rather than assuming a silent track will be handled as you expect.
Get the YouTube Live URL and stream key
In YouTube Studio, open Live Control Room and create or select the stream you intend to use. The encoder workflow provides a server URL and stream key; copy the values shown for that stream rather than assuming a fixed address. YouTube’s encoder setup instructions describe the preview workflow and the point at which you make a scheduled event live.
Use the RTMPS URL when YouTube offers it. RTMPS carries RTMP over a protected connection, and YouTube explains where to reveal that URL in its RTMPS instructions. The exact address can depend on what Live Control Room displays, so do not hard-code an endpoint copied from an old tutorial if the current interface gives you a different one.
For your first attempt, use an unlisted stream or another suitable test arrangement. Start the encoder, wait for YouTube’s preview, and check that the picture and sound are what you expect before making a scheduled event public. If you are new to this step, the practical checks in testing a YouTube stream before making it public are relevant beyond lofi: verify the feed before inviting viewers.
A stream is not public merely because FFmpeg is sending data. YouTube’s workflow may require you to confirm the preview or use the Live Control Room controls to begin the event. Follow the current instructions shown for your event type; do not treat a running FFmpeg process as proof that the public broadcast is live.
Use FFmpeg to loop the input
The key input option is -stream_loop -1. Place it before the input it applies to. The negative one value means repeat that input indefinitely, so FFmpeg can continue reading the file after it reaches its end. Consult the FFmpeg documentation for the option’s current behaviour and for details that depend on your build.
Here is an illustrative command shape:
ffmpeg -re -stream_loop -1 -i /path/to/video.mp4 \
-c:v libx264 -preset veryfast -b:v 5000k -maxrate 5000k -bufsize 10000k \
-g 60 -c:a aac -b:a 128k -f flv \
'rtmps://<server-url-from-live-control-room>/<stream-key>'
This is a starting template, not a tested command. Replace the file path and the output address with the values and choices appropriate to your system, and make sure your FFmpeg build contains the encoders requested. The URL shape shown is illustrative; use exactly the server URL and key that YouTube provides, and check how those values are combined for the endpoint in the current instructions.
The sample video bitrate is tied to a specific case, not a general VPS recommendation. YouTube’s encoder settings list 5 Mbps for H.264 at 1080p30; that figure does not establish that your source, VPS or connection will work well at that setting. Audio bitrate is additional to video bitrate, and actual output depends on the source and encoding choices. If you change resolution, frame rate or codec, revisit the settings rather than copying the sample numbers blindly.
The -g 60 example corresponds to a two-second keyframe interval at 30 frames per second. YouTube’s encoder guidance recommends a two-second interval and says not to exceed four seconds. If your output frame rate differs, a fixed GOP value of 60 no longer means two seconds. Confirm the actual output frame rate and use a suitable interval; do not assume an input’s nominal frame rate is necessarily the output’s frame rate.
The command uses H.264 video, AAC audio and an FLV output container as an example of an RTMP-family publishing workflow. Options, build support and the input’s properties all matter. If FFmpeg reports an unknown encoder, invalid option or incompatible stream, resolve that mismatch before drawing conclusions about the VPS or YouTube connection.
Read and send at real-time speed
-re tells FFmpeg to read the file at its native rate. For a stored video, this matters because a file can be read faster than its playback duration; without real-time pacing, the sender may try to deliver packets too quickly for a live event. The FFmpeg manual describes this input option. It is about pacing the input, not about guaranteeing that packets reach YouTube on time.
Keep the roles of the two options distinct. -stream_loop -1 governs what happens when the input reaches its end; -re governs how quickly FFmpeg reads that input. Neither option supervises the process or reconnects to YouTube by itself. You can have a correctly paced repeating input and still lose the feed because of a process failure, VPS reboot, network interruption or event-side problem.
YouTube’s guidance says to leave upload headroom beyond the stream’s total bitrate; its streaming tips recommend roughly 20% above the combined primary and backup bitrate. On a VPS, check actual outbound capacity and allow for the audio and any other stream load rather than treating the video bitrate as the whole requirement. The streaming tips also explain why network disruptions can affect a broadcast.
If the VPS cannot encode at the chosen settings, lowering output resolution or bitrate may reduce CPU or bandwidth demand, with a corresponding quality trade-off. If YouTube reports unstable delivery, review the outgoing bitrate and the VPS’s network conditions rather than adjusting -stream_loop; that option does not influence the network. Do not infer capacity from the provider name alone: test the actual file, settings and destination.
Protect the stream key
Treat the stream key as a credential. Anyone who obtains it may be able to send a feed to the associated stream, so do not paste it into a public shell transcript, a public repository, a support screenshot or a script you intend to share. YouTube’s live stream settings help explicitly describes the key’s sensitive role.
For a one-off test, avoid leaving the key visible in a command history or terminal recording. For a longer-running setup, keep credentials in a file or environment mechanism with access limited to the account that needs them, and avoid printing them in logs. Exact handling depends on your operating system and how you start FFmpeg; whatever method you choose, check who can read it and whether your process manager exposes command arguments.
If you believe the key has been exposed, use YouTube Studio to manage or replace it, then update the sender with the new value. Changing the key may interrupt a running feed while you make the change, so plan a safe window and confirm the new feed in preview. Do not include the key when asking for help with a failed connection: share the error text after removing credentials and identifying information.
Test the feed and plan for failures
Begin with a controlled test, not an unattended overnight run. Start FFmpeg, inspect its output for input or encoder errors, and wait for the preview in Live Control Room. Check video framing, motion, audio level and synchronisation, then inspect YouTube’s stream health indicators. Finally, view the watch page from a separate device or browser so you know what a viewer actually receives.
A clean preview is useful evidence for that test, not a guarantee about what happens later. Watch for repeated connection errors, dropped frames, unexpected black video, missing audio or a feed that stops when the file reaches its end. If the stream ends at the file boundary, confirm that -stream_loop -1 is applied to the right input. If the feed disappears while FFmpeg is still running, investigate the connection and YouTube event state separately.
For longer operation, run FFmpeg under a process supervisor or service manager that can record output and apply restart behaviour you have chosen. Configure logging so you can tell whether FFmpeg exited, could not open the file, failed to connect or encountered an encoder error. A restart policy can start the process again after an exit, but restarting does not guarantee that YouTube accepts the new connection or that viewers see an uninterrupted event.
FFmpeg documents a FIFO muxer pattern that can attempt recovery after temporary network trouble, but it is an optional technique with its own configuration and limitations. Do not treat it as a substitute for supervision, log review and checking the YouTube event. Any recovery approach needs a test in your own setup, and repeated reconnects may still require action in Live Control Room.
Also account for YouTube-side limits and event behaviour. Its encoder setup guidance says streams under 12 hours are automatically archived; that should not be read as evidence that a single event can stay live forever. Check current official guidance for the event you plan to run, and consider how you will handle a planned restart, archive and new event if the broadcast must continue beyond platform limits.
Before relying on a VPS for a devotional, study or local information channel, run the intended source and settings long enough to reveal ordinary failure modes, then review the logs and stream health. A setup that has only been started once has not demonstrated how it behaves after a reboot, connection loss or scheduled event change. Write down the steps to restart it and confirm the preview, so recovery does not depend on remembering a command during a failure.
If managing file paths, credentials, process supervision and reconnect behaviour on a VPS is the part that has already caused trouble, StreamNeo removes that specific burden by turning an uploaded video into a YouTube live stream that runs without your computer on. This guide’s FFmpeg method remains useful when you want control of the sender on your own VPS; whichever route you take, check the stream in YouTube and do not assume a repeating file guarantees continuity.
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 guarantee a 24/7 YouTube stream?
No. It repeats the input indefinitely while FFmpeg is able to keep reading it, but it does not protect against a crashed process, network failure, VPS reboot or YouTube-side interruption. Use supervision and monitoring, and check the current event limits in YouTube’s official help.
What does -re do in this command?
It makes FFmpeg read the file at its native rate, which is useful when sending file content as a real-time live feed. It does not reconnect the sender or keep the YouTube event active if something else fails.
Can I use any Hetzner VPS size?
There is no size recommendation here because the needed capacity depends on whether you encode, the source resolution and frame rate, the chosen settings and network conditions. Check Hetzner’s current specifications and test the actual workload before relying on a server for a live channel.
Is it safe to put the stream key in a script?
A key in a private, access-controlled script may be workable, but it must not be exposed in a public repository, terminal capture or logs. Limit who can read it, avoid sharing it when troubleshooting, and replace it through YouTube Studio if it is compromised.