A VPS can loop a local video file and send it to YouTube as a live broadcast. The basic workflow is FFmpeg reading an authorised file, repeating it with -stream_loop -1, pacing playback with -re, and publishing to the RTMPS URL and stream key shown in YouTube Live Control Room.
The command is only one part of a dependable setup. You also need to confirm your YouTube live access, check the file and its audio, keep the stream key private, choose settings the VPS can sustain, and test the complete path before leaving it running.
Check your YouTube Live setup
Before logging in to a VPS, confirm that the channel can use YouTube Live and that you know which broadcast or stream configuration you intend to use. Open YouTube Live Control Room and create or select the stream there. The controls and available options can change, so use the current interface rather than copying an old tutorial.
YouTube’s live streaming setup guidance explains the steps for starting a stream and finding the relevant encoder details. You need a destination supplied for the selected stream, not an address taken from a random example.
For a simple looped-file channel, decide what the viewer should see when the file reaches its end. The same file may repeat from its opening frame, which is straightforward but can be noticeable. A longer programme, a collection assembled into one file, or deliberate transitions can make the repetition less abrupt, but each option adds preparation work. Do not solve a content problem by changing the FFmpeg command before you understand the source file.
You should also decide whether a live broadcast is suitable for the channel’s intended material. A video being available on your computer does not mean you have permission to rebroadcast its music, images, performances, recordings or spoken content. Keep records of the permissions or licences relevant to the file and review YouTube’s current rules for the type of content and channel you are operating. Technical success does not establish policy approval.
If your aim is an always-on devotional or spiritual channel, the content decisions deserve as much attention as the process. Our guide to a 24/7 meditation and spiritual talks channel covers practical questions about format and repetition that sit outside the encoder itself.
Prepare an authorised media file
Place the video on the VPS and confirm its exact path. Use a file you are authorised to broadcast, and do not download material merely because it is easy to find. A VPS does not change the rights attached to the source.
Before starting a live process, check that the file plays from beginning to end and contains the audio and video streams you expect. An apparently successful upload can still produce a silent broadcast, an unexpected aspect ratio, a frozen section, or a file that stops before its advertised duration. Watch enough of the opening and closing sections to catch those problems, and inspect the whole file if it has previously failed in production.
Keep the media in a predictable location with a simple filename. Avoid moving or replacing it while FFmpeg is using it. If you need to update the programme, prepare a new file, test that file separately, and change the input only during a planned maintenance window.
The file’s properties influence the encoding work. Resolution and frame rate affect CPU use, while the chosen output settings affect both CPU use and the amount of data sent to YouTube. There is no universal minimum VPS specification established by the sources for this workflow. Compare the sustained CPU capacity and outbound network capacity of the VPS with the encoding workload and the settings you choose. Treat that as an operational judgement, not as an official YouTube requirement.
If you are building the channel from a single long recording, it is worth planning the viewer experience before you upload it. The guide to building a 24/7 channel from one 20-minute video discusses the practical limitations of relying on one repeating source.
Get the RTMPS destination and stream key
In Live Control Room, copy the stream key and the RTMPS server URL for the selected stream. YouTube Help says the RTMPS address can be shown through the lock icon beside Stream URL. Use the destination shown for your broadcast rather than substituting an address from a blog post.
The stream key acts like a password for publishing to that configuration. Do not place it in a public script, a screenshot, a ticket, a chat message, a source repository or an article. Be careful with shell history and process listings as well. If a key is exposed, rotate or reset it in YouTube and update the process that uses it.
The Google for Developers RTMPS ingestion guide describes the ingestion model. For this workflow, the connection must use the rtmps protocol and the destination must include the valid host and application path supplied by YouTube, normally on port 443. The URL shown in Live Control Room remains the authoritative value for the particular broadcast.
A destination usually looks structurally like this:
rtmps://HOST:443/APP/STREAM_KEY
That line is a shape, not a destination to paste into production. Replace every placeholder with the exact values YouTube provides. Do not copy HOST, APP or a sample key from this article. If the URL in Live Control Room differs, use that URL.
If the connection times out or reports an SSL problem, check the protocol, host, port, application path and whether the FFmpeg build supports RTMPS. Do not immediately change several settings at once. A copied character or an incorrect protocol is often enough to prevent a connection.
Build the FFmpeg loop command
The essential FFmpeg roles are separate. -stream_loop -1 tells FFmpeg to repeat the input indefinitely. -re tells it to read at the input’s native frame rate rather than consuming the file as quickly as the VPS can process it. The input-specific options belong before the input they apply to.
A conceptual command is:
ffmpeg -re -stream_loop -1 -i /path/to/authorised-video.mp4 [encoding and audio/video options] -f flv 'rtmps://HOST:443/APP/STREAM_KEY'
This is deliberately a template, not a universal copy-and-paste command. Replace the source path and destination with your own values, and choose encoding and audio options that match the source, the VPS and YouTube’s current encoder guidance. Do not add settings simply because they appear in a different tutorial.
The three important pieces have different jobs. The input path identifies the file. The loop option controls what happens when the file reaches its end. The real-time option controls how quickly FFmpeg reads it. The RTMPS URL controls where the resulting stream is published. Removing one of these can produce a command that starts but does not behave as intended.
The -f flv output format is part of the pattern for this RTMPS workflow. It does not decide the video codec, audio codec, resolution, frame rate or bitrate by itself. Those choices still need to be specified appropriately for the source and the current YouTube encoder table.
Read the relevant FFmpeg documentation for the version installed on the VPS, particularly when adapting the command for more than one input or for a specialised filter. FFmpeg options are order-sensitive: an input option can apply to the next input, so moving options around while troubleshooting can change their effect.
You should keep the secret out of reusable public material. One practical approach is to restrict access to a private script on the VPS and limit who can read it. That is not a substitute for rotating a compromised key, and it does not make a public log safe if the full command is recorded there.
Use real-time pacing and choose suitable output settings
Without real-time pacing, a file-based process can read ahead as fast as processing allows. That is not a live programme. The stream may arrive too quickly, buffer behaviour may become confusing, and the process may reach the end of the file before you expect it. -re gives the file input live-like pacing by reading at its native frame rate.
Looping and pacing are not the same thing. -stream_loop -1 answers “what should happen at the end of the file?” It repeats the input. -re answers “how quickly should the input be read?” It keeps the reading rate aligned with playback. Both roles matter in this workflow.
The output settings then determine what FFmpeg sends. Check YouTube’s current encoder settings, bitrates and resolutions for the resolution and frame rate you intend to use. The guidance covers protocol, supported codecs, audio choices, frame rate, keyframe interval and bitrate. YouTube recommends choosing quality that is reliable for the connection available, testing before going live, and monitoring stream health during the event.
Do not choose a high output setting merely because the source file has a high resolution. A larger output can increase encoding demand and sustained upload demand without improving a viewer’s experience if the original material is smaller or soft. Conversely, reducing settings too far can make text, devotional artwork, news tickers or study notes difficult to read. Make the choice from the source, the audience and the capacity you have measured.
The FFmpeg protocols documentation is useful when you need to understand a protocol-specific error, but it does not replace YouTube’s current ingestion instructions. YouTube lists several ingestion protocols, including RTMP, RTMPS, HLS and DASH. For this basic looped-file workflow, RTMPS is the direct default; choose another protocol only when its documented capabilities and implementation requirements fit your use case.
A speed test is relevant before a long run. YouTube’s guidance says, “We recommend running a speed test to test your upload bitrate.” Treat the result as an indication of the available connection at that time, not as proof that the VPS will sustain the stream under every condition. Also check CPU use while the chosen encoding settings are active.
Test the broadcast and audio
Run a short test with the actual file, command structure, VPS and YouTube destination. Check the signal in Live Control Room before you rely on the process. You are testing the complete path, not just whether FFmpeg prints a line that looks positive.
Look at the preview and stream health. Confirm that the picture moves, the aspect ratio is correct, the audio meter responds, and the output does not stutter. Listen with headphones as well as checking the meter. A meter can move while the audio is distorted, delayed, too quiet or carrying the wrong track.
Let the test cross a natural point in the file if possible. For a loop, that means checking what happens at the transition from the final frame back to the opening frame. Watch for a brief silence, a frozen image, a visible jump or a change in audio loudness. If the first loop is not acceptable, a process that runs for longer will not correct it.
Check the selected keyframe interval and other output values against YouTube’s current table. YouTube’s guidance recommends a two-second keyframe interval and says it should not exceed four seconds. Use the current official page when choosing the setting rather than assuming that a value from an older guide is still appropriate.
A test should also include failure observations. Note what FFmpeg prints when the network is interrupted, when the input cannot be opened, and when the process exits. This gives you something concrete to look for later. Do not interpret one successful test as evidence of an uninterrupted long-running broadcast or acceptance of every future loop.
If your file is a prerecorded programme, read the guidance on streaming a pre-recorded video as live on YouTube as well. It is particularly important to separate the technical ability to send a file from YouTube’s current treatment of the content and channel.
Monitor the VPS stream
Once the test is healthy, keep two monitoring views in mind. The first is the process on the VPS: is FFmpeg still running, is it reading the expected file, and are errors appearing? The second is YouTube: is the incoming signal healthy, and does the public playback behave as expected?
A shell session that closes can terminate a foreground process, depending on how you started it. Use a suitable service manager or process supervisor if you need the process to start after a planned reboot or restart after a crash. Configure it carefully and test the restart behaviour. A supervisor can start a process again; it cannot guarantee that YouTube accepts the new connection, that the same broadcast continues, or that the viewer sees an uninterrupted programme.
Keep logs useful but private. They can help identify an input error, connection failure, encoder problem or repeated restart. They can also reveal the full destination if the command is logged carelessly. Mask the stream key in stored output and restrict access to logs and scripts.
Watch resource behaviour over a meaningful period. A process that starts cleanly may still exhaust disk space through unbounded logs, run into CPU contention, or encounter an outbound connection problem later. Check the VPS provider’s current terms and the actual capacity of the plan you have selected. The available technical sources do not establish a universal CPU, memory or bandwidth requirement for every file and output setting.
For a channel where managing a VPS, a secret script and recovery checks is the main burden, StreamNeo removes the need to keep your own computer running by letting you upload the video once, provide the YouTube key, and have the stream monitored and restarted from the cloud.
Be precise about what your monitoring arrangement proves. It can show that the process is running and that YouTube is receiving a signal at a particular moment. It does not prove continuous availability, earnings, viewer growth, policy approval or a maximum live duration. The official technical pages reviewed here do not settle YouTube’s treatment of every continuously looped prerecorded broadcast, so check the current platform rules for your intended use.
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
Can FFmpeg loop one video forever on a VPS?
The -stream_loop -1 input option tells FFmpeg to repeat the input indefinitely. That controls file repetition, not YouTube’s acceptance of the broadcast or the reliability of the VPS and network. Test the transition between loops and monitor both FFmpeg and Live Control Room.
Why is -re needed if the file already has a frame rate?
A file can be read faster than real time by a computer. -re makes FFmpeg read the input at its native frame rate, which gives the file live-like pacing. It does not choose your output bitrate or guarantee that the VPS can encode and upload the stream reliably.
Where should I get the YouTube RTMPS URL and key?
Get both from the selected stream in YouTube Live Control Room. Use the exact RTMPS URL shown there, including its host, application path and port, and keep the key private. If it is exposed, reset it and update the command or private script.
Does a successful FFmpeg test prove that a 24/7 stream is safe to leave unattended?
No. It proves that the file, encoder, VPS, connection and YouTube destination worked during the test. A supervisor and monitoring can help you respond to failures, but they do not establish uninterrupted operation, policy approval or a guaranteed continuous broadcast.