To loop a video continuously from a Contabo VPS, put -stream_loop -1 before the -i option for that video. To publish it at its normal playback rate rather than processing it as fast as possible, use -re as an input option.
The command below is a template to adapt and validate, not a tested Contabo deployment. You need a real video path and a publishing URL provided by your receiving service or by an RTMP server you have configured; running FFmpeg on a VPS does not create that destination for you.
What an infinite loop does
FFmpeg’s -stream_loop -1 option tells it to repeat an input indefinitely. With one file, FFmpeg reaches the end and starts reading that file again, continuing until the process is stopped or it encounters an error. The option is attached to an input, so put it before the -i that names the file it should repeat. The FFmpeg command-line documentation defines -1 as infinite looping.
A loop repeats the media; it does not make the content itself live or add new material. If a five-minute devotional recording is the input, the same recording will begin again when playback reaches its end. Check the join between the end and beginning: a hard cut, silence, a spoken sign-off or a fade that does not meet cleanly can be noticeable every time the video repeats.
This approach is useful when one finished video is intended to run continuously. It is different from rotating through a collection of files. For a playlist, you would need a playlist or another input arrangement, and should verify how that arrangement handles transitions and errors rather than assuming one file’s loop option schedules a programme. For a broader treatment of a repeating programme, see this guide to a recorded Orthodox Christian services stream.
Looping also does not resolve rights, channel settings, or destination requirements. Make sure the recording is suitable for your channel and that the receiving platform accepts the content and stream format. For YouTube, check its current live streaming help and the stream settings shown in your account before scheduling a long run.
Prepare the video file on the VPS
Before composing a command, identify the file you want to publish and its exact path on the VPS. You can transfer it using a method you already trust, then confirm that the account running FFmpeg can read it. A path such as /path/to/video.mp4 in an example is a placeholder, not a file that exists automatically.
Use a simple filename without spaces while you are getting the first run working. If your chosen path does contain spaces, quote it as one shell argument, for example -i "/home/channel/Evening prayer.mp4". Quoting protects the shell from treating the spaces as separators; it does not check that the file exists or that FFmpeg can decode it.
Inspect the media before a long broadcast. Confirm that it has the video and audio you expect, and watch enough of its beginning and end to spot accidental black frames, silence, or a discontinuity at the loop point. If you are unsure about a file’s frame rate or audio track, inspect it with the FFmpeg tools available in your chosen environment. The relevant build and operating system were not supplied here, so package names and commands to install or inspect a particular version depend on your VPS setup.
A video that plays on your desktop is not automatically suitable for every live ingest. Codec, resolution, frame rate and audio characteristics may affect whether the receiver accepts it or whether it needs conversion. If you are working through those settings, the FFmpeg resolution guide for a small Indian VPS is a useful companion; do not copy its settings blindly into a different source and destination combination.
Finally, plan for the process to outlast your SSH session. Starting FFmpeg in an interactive terminal may leave it tied to that session; closing the terminal or disconnecting can stop the process. Use a persistent process manager or service appropriate to the Linux distribution and operating practices you have actually chosen, and decide how you will notice and recover from a failure. No particular Contabo plan, distribution, package version or restart policy is assumed here.
Put -stream_loop -1 before -i
Here is the basic template for a file published to an RTMP destination:
ffmpeg -re -stream_loop -1 -i /path/to/video.mp4 \\
-c:v libx264 -c:a aac -f flv \\
'rtmp://RTMP_SERVER/APP/STREAM_KEY'
In this layout, -stream_loop -1 is before -i /path/to/video.mp4, so it applies to that input. Keep the placement when you substitute your own values. FFmpeg options can apply to inputs or outputs according to where they appear; moving an input option after the input can change what it affects or cause the command not to behave as intended.
The example includes -re before the input too. The next section explains why. The output options after the input select video and audio encoders and an FLV container; they are examples, not proof that your ingest accepts those choices. The final quoted string is a stand-in for the real destination URL. Replace it only with the address supplied by the service you intend to publish to or by your separately configured RTMP server.
Adapt and validate the whole command in your environment. The installed FFmpeg version, available encoders, file and destination formats, credentials and receiver requirements have not been tested here. The FFmpeg online documentation is regenerated regularly and may describe a newer revision than the package installed on your VPS, so consult the local version’s documentation where behaviour or available options differ.
For more than one input, do not assume that the same loop setting applies to every file. Match each input-specific option to the input it describes and test the full command with representative media. If what you need is a Hindi-language file playlist rather than a single repeating file, see using a Hindi video playlist file with FFmpeg.
Use -re for real-time input playback
-re asks FFmpeg to read the input at its native rate. For a file, that means pacing the read to the media’s playback timing instead of consuming it as quickly as the machine can process it. FFmpeg describes -re as an alias for reading at the input’s native frame rate, and its protocol documentation uses it in an RTMP publishing example.
That pacing matters for a prerecorded file intended to feed a live destination. Without it, FFmpeg may read ahead or process the file faster than its intended playback rate, subject to the rest of the pipeline. -re does not turn the recording into a live camera feed, change its frame rate, or guarantee smooth playback at the receiver. It controls input reading pace; the connection, encoding workload and destination still matter.
Do not treat -re as a universal option to add to every FFmpeg job. FFmpeg’s guidance is particularly relevant when reading a file as a real-time input. Other input types and workflows can have different timing requirements. If the destination reports irregular timing or stalls, look at the logs and stream health rather than assuming that this one option fixes every cause.
A long-running publisher also needs enough available processing capacity for the chosen encoding workload and a stable route to its destination. There is no benchmark here for a particular Contabo instance or source video, so avoid selecting a configuration on the basis of a claimed CPU figure. Test with your own media and encoding settings, and watch for persistent errors or increasing delays.
Set encoding and the RTMP destination
The sample selects libx264 for video, AAC for audio and FLV as the output container. Those are explicit choices in the template, not settings automatically applied by Contabo or YouTube. Confirm that your FFmpeg build has the requested encoders and that the receiving service accepts the codecs, container and stream characteristics you send.
If the source streams are already compatible with the destination, -c copy can copy streams without decoding and re-encoding. That can avoid encoding work, but it is not a safe shortcut to assume will work for an unspecified file and ingest. Container, codec, timestamps and receiver requirements all matter. If copying produces an error or the service rejects the stream, inspect the actual input and destination requirements before choosing conversion settings. FFmpeg explains the distinction in its documentation on stream copy and transcoding.
The endpoint is as important as the codecs. An RTMP destination URL can include a server, an optional port, an application and a playpath or stream name. Obtain the correct address from your live service or from the configuration of the RTMP server you operate. A generic URL in a template cannot tell FFmpeg where your particular channel is ingesting.
There are two different arrangements to keep clear:
| Arrangement | What the VPS does | What you need to configure |
|---|---|---|
| Publish to an external ingest | FFmpeg opens an outbound connection to a service’s RTMP or RTMPS endpoint | The service-provided URL and any required stream credential; compatible output settings |
| Host an RTMP ingest yourself | The VPS accepts a connection from a publisher or other client | A separately configured RTMP server, its listening address and port, and appropriate inbound firewall rules |
In the first arrangement, the Contabo VPS is a publisher, not the ingest server. In the second, running FFmpeg alone does not make the VPS an RTMP server: that is additional software and configuration to operate. The choice depends on whether you need a receiving endpoint of your own, and on your willingness to maintain it.
RTMPS is RTMP over a secure SSL connection, according to FFmpeg’s protocol documentation. Use it if the destination supports and specifies it, and ensure your FFmpeg build and URL scheme support the endpoint. It is not a reason to invent a URL or change an endpoint supplied by the service. Confirm transport and output requirements with the receiver before a live run.
Protect and substitute the publishing URL
Replace RTMP_SERVER/APP/STREAM_KEY with the publishing URL issued for your channel, following the exact format the destination gives you. Some services provide a server address and a separate stream key; others display them together as one URL. Do not guess the application name, port or path. A malformed or incomplete URL can lead to a connection failure even when the file and encoding are fine.
Treat the stream key as a credential. Do not publish it in an article, screenshot, shared terminal transcript or support message. The example uses conspicuous placeholder text rather than a real endpoint. Avoid leaving the key in scripts or shell history that other users of the machine can read; access controls and the method for supplying credentials should match your environment. If the key is exposed, follow the platform’s current process for replacing or resetting it.
Shell quoting keeps the URL together as one argument, but it does not hide it from every process viewer, log or shell history. Consider who can access the VPS account and where command output is saved. For a service-managed process, store sensitive configuration with permissions appropriate to that service rather than placing an actual key in documentation or a public repository.
For YouTube, copy the current ingest information from the live control room and check the platform’s instructions for connecting an encoder. The YouTube live encoder help can help you understand the setup, but details shown in your account are the ones to use. StreamNeo turns an uploaded video into a YouTube-only 24/7 live stream, which removes the need to keep an FFmpeg process running on your own VPS when the specific pain is maintaining that process; it does not change the need to prepare suitable content or follow YouTube’s current requirements.
Test playback and inspect FFmpeg logs
Do a short, attended test before relying on a process overnight. Start with the intended file and a valid destination, then check that FFmpeg opens the input, identifies the expected audio and video streams, begins encoding or copying, and establishes the output connection. Watch the receiving player or live control room as well as the terminal: an FFmpeg process can be running while the stream is not appearing as expected at the destination.
Let the test reach the end of the file if practical. Confirm that the next pass begins and look for a visible or audible problem at the join. Check the terminal output for repeated connection errors, missing-stream messages, encoder failures or output interruptions. A single successful connection at the beginning does not establish that a long-running process will reconnect correctly after a later network or service interruption.
Keep enough log information to diagnose a failure, while removing or protecting credentials before sharing logs. Record which file, output settings and destination type you tested; do not include the actual stream key. If you change the command, test the revised version rather than assuming that a small edit cannot affect option scope or output behaviour.
If the VPS is only publishing outward, do not open an inbound RTMP port just because the output protocol is RTMP. Contabo Product Documentation says that when its firewall is activated, “All inbound traffic is blocked from the moment a firewall is activated; the customer decides what is allowed in.” It also says outbound traffic is unrestricted. For an outbound-only publisher, the inbound default does not call for an inbound RTMP rule. Consult Contabo’s firewall documentation and check the guest operating system’s firewall as well.
If you are hosting an RTMP server on the VPS, the answer changes: configure the relevant inbound rule for the actual listening port and protocol, then check both the network-level firewall and the operating system’s firewall. Do not open a port based on a tutorial for a different service. Confirm what your server is listening on and limit access to what the intended clients need.
For a continuously running channel, plan who will notice a stopped process and what they will do next. A process manager or service can help keep a process running across a shell disconnect or a restart, but behaviour depends on its configuration and the machine’s environment. Decide how logs are retained, how a failed run is restarted, and how you will verify the stream after a restart. If you prefer not to manage a VPS publishing process, compare that operational burden with other options for a 24/7 YouTube channel by the tasks you need them to handle, not by a general promise of uptime.
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 with FFmpeg?
Place -stream_loop -1 before the -i option for the video input. Substitute the actual file path, choose output settings the receiver accepts, and use -re when reading a file for real-time publishing. Test the loop and its join before leaving it unattended.
Does a Contabo VPS automatically provide an RTMP destination?
No. FFmpeg needs an RTMP or RTMPS endpoint to publish to, and the VPS does not become an ingest server simply because FFmpeg is installed or running. Use an endpoint from a receiving service, or configure and maintain a separate RTMP server if the VPS must accept inbound connections.
Which port should I open for RTMP?
It depends on whether the VPS publishes to an external endpoint or hosts a receiving service. An outbound publisher does not need an inbound RTMP rule simply because it sends RTMP; a self-hosted ingest may need an inbound rule matching its actual configuration. Check the current Contabo and operating-system firewall rules before changing them.
Is -c copy always better than encoding?
No. Stream copy avoids decoding and re-encoding, but the source streams must be compatible with the destination’s requirements. If compatibility is unknown, validate the media and receiver settings rather than assuming that copying will work.