To loop a pre-recorded video on YouTube Live from a DigitalOcean Droplet, create or schedule a YouTube event first, then point FFmpeg at that event’s current ingest URL and stream key. The -stream_loop -1 option repeats the input file, while -re reads it at real-time speed; neither option guarantees that YouTube will keep the event live indefinitely or preserve its archive indefinitely.
A Droplet is simply the Linux computer running FFmpeg. You manage the operating system, media file, encoder process and recovery plan yourself, while YouTube manages the event and its ingest connection. Keep those two jobs separate: first prepare the event in YouTube Studio, then configure and test the encoder.
Create or schedule the YouTube Live event
Open YouTube Studio and choose Create → Go Live. In Live Control Room, use the Stream workflow for a new broadcast or Manage to schedule one, following the current instructions in YouTube’s live-streaming guide. The labels and available choices can change, so use the current interface rather than relying on a remembered sequence.
An event and an encoder connection are related, but they are not the same thing. The event is the YouTube broadcast viewers can watch; FFmpeg is the software that sends audio and video to YouTube. Creating the event does not start FFmpeg, and starting FFmpeg does not necessarily make a scheduled event public or live immediately. You may need to check the incoming preview and select Go live in Live Control Room.
Before deciding on a long run, consider the shape of the broadcast. A single devotional video repeated all day has different editorial and audience expectations from a news playlist or a study channel that changes content by time of day. FFmpeg’s input loop repeats one file; it does not schedule a collection of videos or create transitions. If you need the content to change at set times, a playlist or schedule is a separate requirement. This guide to scheduling study sessions in a 24/7 stream covers that distinction.
For an initial setup, choose an unlisted or private test event if that suits your channel, and use representative motion and audio. Confirm you can see and hear the preview before inviting viewers to rely on the channel. A test also gives you a chance to check whether the Droplet can encode the chosen quality without being overloaded.
Copy the event URL and stream key
After the event is set up, copy its server or stream URL and its stream key from Live Control Room. Use the values shown for that event, not a URL or key pasted from an old tutorial. YouTube’s encoder setup instructions explain where to find these details and how to connect an encoder.
Treat the key as a credential. Someone who obtains it may be able to send a signal to your event, so do not publish it in a script repository, screenshot, support post or public terminal log. Keep it in a private shell session or a file accessible only to the account that runs FFmpeg. If you share the Droplet with other people, decide who can read the configuration and rotate the key if it is exposed.
The endpoint and key belong together. A useful mental model is that the URL identifies YouTube’s ingest destination and the key identifies the stream within that destination. If the preview does not appear, check both fields, including any path or key portion of the URL, before changing encoding options. A correct video codec cannot fix a key copied from a different event.
Avoid treating the ingest address as a permanent value. YouTube may show a different endpoint for a later stream or offer primary and backup choices. Copy the current event details each time you prepare a new connection, and keep the full value private when sharing diagnostic logs.
Prepare the video on the Droplet
Make sure the video file is available on the Droplet and that FFmpeg is installed. The Droplet is the machine executing the encoder; for a direct file-to-YouTube setup, you do not need to install an additional streaming-server layer simply to read the file and send it to YouTube. DigitalOcean’s material describes Droplets as virtual machines, but the workload still depends on your selected media settings and actual resources. Do not assume a particular Droplet size can encode a particular resolution without testing it.
Check the file before starting a long broadcast. Confirm the path, duration, image dimensions, frame rate, audio track and codecs. Make sure the file plays through to the end and that its opening and closing frames make sense together. -stream_loop -1 repeats the file at its end; it cannot remove a visible jump, an abrupt silence or a change in loudness at that boundary.
You can use FFmpeg’s inspection tools, such as ffprobe, to see what the file contains. The key decision is whether its existing video and audio formats are acceptable for YouTube and whether the Droplet can send them reliably. YouTube’s live encoder settings list supported video codecs, including H.264, H.265/HEVC and AV1, and audio support for AAC or MP3 over RTMP/RTMPS. Follow the current table for the resolution and frame rate you intend to send.
If you re-encode, FFmpeg uses CPU on the Droplet. A more demanding resolution, frame rate or codec can require more processing, so watch for overload during a representative test. Re-encoding gives you direct control over output settings, but it is not free of trade-offs: it adds compute work and can fail to keep up if the machine is under-sized for the chosen settings.
If the file already has compatible codecs and timestamps, stream-copying may reduce encoding work. That does not mean every file will be suitable for direct copying or accepted in every ingest situation. Test that path against your event and YouTube’s current requirements before depending on it. When compatibility is uncertain, encoding to a controlled H.264 video and AAC audio output is a more explicit starting point, provided the Droplet has sufficient headroom.
For a related discussion of balancing encoder load and output quality, see the FFmpeg hardware encoding settings guide. Its gaming context differs, but the principle applies: choose settings by testing the actual workload rather than assuming that a codec option makes an encoder run effortlessly.
Use FFmpeg looping and real-time pacing
DigitalOcean documents the FFmpeg pattern of reading a file with -re and adding -stream_loop -1 before the input to keep repeating it. The official FFmpeg options documentation describes input options and their placement. In practical terms, -stream_loop -1 tells FFmpeg to loop that input without a set repeat count, while -re asks it to read at native, real-time rate rather than sending the file as fast as it can be processed.
Here is a schematic command, not a tested configuration for every file or FFmpeg build:
ffmpeg -re -stream_loop -1 -i "/path/to/video.mp4" \
-c:v libx264 -preset veryfast -b:v VIDEO_BITRATE -maxrate VIDEO_BITRATE -bufsize BUFFER_SIZE \
-g GOP_FRAMES -c:a aac -b:a 128k \
-f flv "rtmps://YOUTUBE_INGEST_HOST/YOUTUBE_PATH/STREAM_KEY"
Replace the path, bitrate, buffer, GOP and ingest placeholders with values suited to your file and event. The loop option applies to the input that follows it, so keep -stream_loop -1 before that input’s -i. The URL must be the complete current address and key copied for your event. Do not paste a sample key, leave placeholder text in place or expose the real key when saving the command in a public location.
The example re-encodes video with libx264 and audio with AAC. VIDEO_BITRATE and BUFFER_SIZE are deliberately placeholders: choose them using YouTube’s current resolution and frame-rate guidance, then verify that the encoder and the Droplet can sustain them. The example’s audio bitrate is not a universal recommendation; check the current requirements and the needs of your programme. A static image with music, for example, has a different visual workload from a fast-moving video, but both still need audio that plays cleanly.
For a two-second keyframe interval, the GOP frame count depends on frame rate. At 30 fps, 60 frames represents two seconds; use the corresponding calculation for your selected rate rather than carrying that example over blindly. YouTube recommends a two-second keyframe interval and says it should not exceed four seconds. Its current encoder guide also lists support up to 60 fps. These are output constraints, not guarantees that a connection will remain healthy.
The command’s -re option matters because sending a file faster than real time is not the same as broadcasting it live. With real-time pacing, a video of a given duration takes that duration to play once; looping starts it again at the input boundary. A loop is not a playlist manager or a broadcast scheduler. If you need a different video at a particular hour, build that behaviour separately and test how it interacts with event changes and encoder restarts.
Prefer RTMPS when supported
Use the RTMPS endpoint shown by YouTube when available. YouTube recommends RTMPS, the secure extension to RTMP, and its ingestion protocol guide specifies the secure scheme and connection details. FFmpeg’s protocol documentation describes RTMPS as RTMP over a secure SSL connection.
Do not assemble the address from fragments found in different examples. Use the hostname, path and key associated with your event, and preserve the rtmps:// scheme where YouTube provides it. The secure connection also depends on FFmpeg being built with the relevant protocol support. If FFmpeg reports that a protocol or TLS connection cannot be opened, check the installed build and the copied address rather than quietly replacing the secure endpoint with an insecure one.
When selecting output settings, distinguish the video’s source properties from what you send. A file may be 25 fps, for instance, while the event output is configured differently; converting it has processing and motion consequences. Use a frame rate, resolution, codec and bitrate consistent with YouTube’s current guide and your own test. YouTube lists a two-second recommended keyframe interval, with a maximum of four seconds, and audio compatibility requirements. Avoid copying a full command from a different resolution or channel and assuming its bitrate is right for your case.
There are two reasonable encoder choices. Re-encoding with H.264 and AAC makes output settings explicit, but consumes Droplet CPU. Stream-copying may reduce that work if the file is compatible, but you must establish that by testing; it is not a universal shortcut. If you are comparing a self-managed process with a managed prerecorded-streaming tool, account for maintenance and restart handling as well as compute and bandwidth. YouTube’s encoder guidance names cloud-based prerecorded tools, including Gyre; check current features and terms directly rather than relying on an old comparison. This overview of alternatives for prerecorded YouTube Live may help you frame the choice without assuming one approach suits every channel.
Start the stream and check YouTube status
Start FFmpeg in a way that lets you see its output and record enough information to diagnose a failure. Watch for a connection error, unsupported codec, timestamp warning, encoder overload or non-zero exit. A command that begins successfully is only the first check; confirm that the preview appears in Live Control Room and that YouTube reports a healthy incoming signal.
For a scheduled stream, the creator may need to verify the preview and explicitly start the event in Live Control Room. Follow the current interface prompt. Do not assume the event is public just because FFmpeg is sending data, and do not mistake an active encoder process for confirmation that viewers can watch the event.
Test with audio and motion representative of the actual programme. Listen for clipping, silence, out-of-sync sound and a rough join at the file boundary. Watch the image for repeated black frames or visible discontinuity. YouTube recommends a test run and monitoring encoder warnings and stream health during the broadcast; this is particularly useful before leaving a channel unattended overnight.
For a 24/7 operation, also think through what happens when the process exits, the Droplet reboots or the network path breaks. A command launched in a terminal session can stop when that session ends, depending on how you run it. Process supervision and restart policy are separate from file looping: they can relaunch a process, but they do not automatically prove that the YouTube event accepts a reconnect or resumes at the point you expect. Plan and test the restart behaviour. This guide to resuming at the right point after a server reboot addresses that separate recovery problem.
A managed approach can remove the work of keeping a server process and file running. StreamNeo addresses that specific operational burden by letting you upload the video and use your YouTube stream key, so your own computer does not have to stay on; it is YouTube-only. This does not change the need to create the event correctly, confirm YouTube status or plan around event and archive limits.
Understand event and archive limitations
The loop belongs to FFmpeg, not YouTube. It tells the encoder to repeat its input; it does not promise that a single event will stay active without interruption, that a reconnect will be accepted on the same event, or that a recording will be retained forever. A process can be healthy while the event has ended, and an event can have rules or limits that affect its runtime independently of the media loop.
YouTube’s live-streaming instructions say streams under 12 hours are automatically archived. Do not turn that statement into a promise about longer broadcasts: it does not establish that a session above that duration will be archived, nor that one event can run indefinitely. Check the current official guidance for the runtime you intend to use, and decide whether your channel should use shorter planned sessions, a restart window or another event strategy.
A very long broadcast needs an operational plan, not only a looping flag. Decide who will notice a failed signal, how you will inspect FFmpeg logs and Live Control Room, and what action you will take if the event ends. If archiving matters, confirm the resulting recording in YouTube rather than assuming the live event and archive have identical lifetimes. Keep a separate copy of source media if you need a dependable master file.
The important boundary is simple: FFmpeg can repeat a local input and send it at real-time pace while the process and connection are functioning. YouTube controls the event status and archive behaviour. The Droplet operator controls the machine and process. Treat those as separate responsibilities, test the whole path, and revisit YouTube’s current rules when planning a long session.
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
What does -stream_loop -1 do?
It tells FFmpeg to repeat the input without a fixed loop count. Put it before the corresponding -i input option. It does not itself keep a YouTube event open, restart a failed process or control the archive.
Why use -re with a video file?
-re reads the input at its real-time rate, which is the intended pacing for sending a file as a live stream. Without real-time pacing, FFmpeg may process a file faster than its playback duration. Check the output and connection in YouTube after starting the encoder.
Can a DigitalOcean Droplet run a continuous YouTube stream?
A Droplet can run FFmpeg to send a file to YouTube, but whether your chosen settings work depends on the file, encoder build, resources and network path. You must also plan for process failures, event limits and YouTube’s archive behaviour. Test the actual workload and check current YouTube guidance before relying on a long run.
Does looping guarantee a YouTube archive?
No. The loop only repeats the input sent by FFmpeg. YouTube says streams under 12 hours are automatically archived, but that does not establish an archive guarantee for longer sessions or indefinite retention.