Key Takeaways
- The fastest way to loop a single video file into a 24/7 live stream is
ffmpeg -stream_loop -1 -re -i file.mp4 -c copy -f flv rtmp://your-server/app/stream, which repeats the file indefinitely and republishes through your streaming engine as HLS or DASH. - Raw ffmpeg looping works for one file but breaks down for real channels — timestamp discontinuities at each loop boundary cause brief freezes, and there’s no way to schedule different content at different times.
- Wowza’s StreamPublisher module and MistServer’s playlist/API scheduling exist specifically to solve multi-file, timed playout without the reset glitches raw ffmpeg looping produces.
- A 2 vCPU / 4 GB VPS comfortably runs one or two looped/scheduled 1080p channels at up to 6 Mbps without transcoding (pure repackaging); add a GPU or more vCPUs only if you’re transcoding multiple bitrate renditions simultaneously.
- This exact mechanism — VOD played out on a schedule instead of live camera input — is what powers FAST (Free Ad-supported Streaming Television) channels, IPTV “linear” tiers, church overflow/replay channels, and background-loop displays.
How Do You Loop a Single Video File as a Live Stream?
The most direct method is ffmpeg’s-stream_loop flag, which tells ffmpeg to re-read the same input file a specified number of times — -1 means infinitely. On a pre-installed Wowza or NGINX-RTMP VPS, the command looks like this:
ffmpeg -re -stream_loop -1 -i /home/streamer/channel1.mp4 \
-c:v copy -c:a aac -ar 44100 -b:a 128k \
-avoid_negative_ts make_zero \
-f flv rtmp://127.0.0.1:1935/live/channel1-re paces ffmpeg to read the file at its native frame rate instead of as fast as the CPU allows, which is required for anything you’re pushing to a live ingest point. -c:v copy avoids re-encoding video, which keeps CPU usage near zero on the loop process itself — on a 2 vCPU / 4 GB VPS we’ve measured under 3% sustained CPU for a single copy-mode loop, versus 35-45% if you force a video re-encode with -c:v libx264 at 1080p. -avoid_negative_ts make_zero prevents ffmpeg from emitting negative timestamps at the loop boundary, which is the single biggest cause of players showing a black frame or brief stall every time the file restarts.
Run this inside a systemd service or a tmux/screen session with an auto-restart wrapper so the loop survives a VPS reboot and restarts itself if ffmpeg crashes:
[Unit]
Description=24/7 loop stream - channel1
After=network.target
[Service]
Restart=always
RestartSec=3
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /home/streamer/channel1.mp4 -c:v copy -c:a aac -ar 44100 -b:a 128k -avoid_negative_ts make_zero -f flv rtmp://127.0.0.1:1935/live/channel1
[Install]
WantedBy=multi-user.targetWhat’s the Difference Between Looping One File and Running a Scheduled Playout Channel?
Looping one file is a repeat; a scheduled playout channel is a programmed lineup — multiple video files played in a defined order at defined times, similar to how a television network’s schedule works. If you only ever need to repeat the same file, raw ffmpeg is sufficient and simpler to maintain. If you need Monday’s sermon to play at a different time than Tuesday’s, or a rotation of ten training videos in sequence, you need a playout tool that manages a schedule and switches sources cleanly. On Wowza streaming VPS instances, we use the StreamPublisher module, a free Wowza add-on that treats a “stream” as a channel and a “playlist” as a program made of one or more video segments, scheduled by time. A SMIL playlist file defines the segments and start times, and settingrepeat to true makes the entire schedule loop once it reaches the end, rather than shutting the stream down — the config difference between a one-off scheduled broadcast and a genuine 24/7 channel. MistServer takes a different but comparable approach: its playlist and API-driven scheduling let you push a list of VOD sources to play out sequentially on a live-style output, which is the same underlying pattern IPTV middleware uses for linear channel tiers.
The practical tradeoff: StreamPublisher-style scheduling takes 30-60 extra minutes to configure over a raw ffmpeg loop, but it eliminates the timestamp-reset stutter at content boundaries and gives you a real programming grid you can update without touching the command line each time.
Comparison: Raw Loop vs. Scheduled Playout vs. Live-with-Filler
| Approach | Best for | Setup time | Handles multiple files? | Smooth transitions? |
|---|---|---|---|---|
ffmpeg -stream_loop | One file, repeated forever (background loop, single training video, hold slate) | 10-15 min | No — one file per process | No, brief reset at each loop |
| Wowza StreamPublisher (SMIL schedule) | Real programming grid — different content at different times, FAST-style channels | 45-90 min | Yes, unlimited playlist segments | Yes, engine-managed transitions |
| MistServer playlist/API playout | API-driven or dynamically updated schedules, IPTV middleware integration | 30-60 min | Yes, via API push | Yes |
| Wowza LoopUntilLive (filler + live override) | Channel that’s usually a loop but should switch to live camera when available | 45-60 min | Yes (filler + live source) | Yes, auto-switches on publish/unpublish |
| Ant Media / NGINX-RTMP + custom cron script | Budget setups needing basic day-parting without a commercial scheduler | 60-120 min (custom scripting) | Yes, self-managed | Depends on script quality |
How Much VPS Do You Need to Run a 24/7 Looped Channel?
If you’re repackaging a pre-encoded file without transcoding (the-c:v copy pattern above), a 2 vCPU / 4 GB VPS handles several simultaneous looped channels at typical bitrates — our own testing shows a single 1080p/6 Mbps copy-mode loop uses under 3% CPU, so CPU isn’t the constraint; egress bandwidth is. One 6 Mbps channel running continuously for 30 days pushes roughly 1.94 TB of egress per concurrent viewer (6 Mbps × 2,592,000 seconds ÷ 8 ÷ 1024 ≈ 1,940 GB), so a channel with even 20 concurrent viewers needs close to 39 TB/month of bandwidth headroom — size your VPS bandwidth allocation around expected concurrent viewers, not just channel count.
If you’re transcoding to multiple bitrate renditions for adaptive playback (see our ABR ladder guide), CPU becomes the real constraint — plan on a 4 vCPU / 8 GB VPS per channel for a 3-rung 1080p/720p/480p ladder in software (libx264), or add GPU transcoding if you’re running several channels on one node. Storage is comparatively small: a looped channel doesn’t need DVR-style recording unless you’re also archiving playout for compliance, in which case size storage the same way we outline in our VOD storage sizing guide.
Is Looping VOD the Same Thing as a FAST Channel?
Looping or scheduling VOD content is the underlying mechanism, and a FAST (Free Ad-supported Streaming Television) channel is the business model built on top of it. A FAST channel is a linear, ad-supported channel assembled entirely from existing VOD library content played out on a fixed schedule, rather than a live camera feed — think of it as “your video library, broadcast like a TV network.” The technical requirements are the same ones covered above: a playout schedule (StreamPublisher, MistServer, or a custom scheduler), ad insertion points if you’re monetizing with ads (SCTE-35 markers are the standard signal for this), and a streaming engine that republishes the schedule as HLS/DASH to viewers at scale. This same pattern shows up in non-FAST contexts too: churches replaying a Sunday service on loop during the week (see our church streaming guide), IPTV resellers offering a “classics” or “replay” tier alongside live channels (see our IPTV VPS hosting guide), and retail or event venues running a branded video loop as an always-on display feed.Can a Looped Channel Automatically Switch to a Live Camera?
Yes — this is a distinct and common requirement: run filler/loop content by default, and switch to a live camera feed automatically the moment it starts publishing, then switch back to the loop when the live feed stops. Wowza’s LoopUntilLive module is purpose-built for exactly this: you create a server-side stream holding the filler video, and the module detects when your real live source starts publishing and hands off to it, then reverts automatically when the live source disconnects. Ant Media and MistServer support comparable filler-to-live patterns through their own scheduling and stream-state APIs. This is the same building block used for a pre-show “we’ll be right back” slate before a scheduled live event, or a church/venue that wants a default announcements loop that automatically yields to the live camera the moment the service starts — no manual operator action required at the streaming server layer.Frequently Asked Questions
Can I loop an MP4 file as a 24/7 live stream on a VPS?Yes. The simplest method is ffmpeg with the
-stream_loop -1 flag pushing an MP4 to an RTMP ingest point on your streaming engine, which then republishes it as HLS or DASH to viewers. For a channel with a real schedule instead of one repeating file, use a playout tool like Wowza StreamPublisher or MistServer’s playlist API instead.
Does looping video 24/7 use more bandwidth than a normal live stream?No, bandwidth is the same as any live stream at the same bitrate and viewer count, since a looped file is delivered exactly like live camera footage once it hits the RTMP ingest point. The only difference is it runs continuously with no dead air, so monthly egress is closer to the theoretical maximum than a stream that only runs a few hours a day. What is a FAST channel and how is it related to looping VOD?
FAST stands for Free Ad-supported Streaming Television, a linear channel built entirely from VOD content played out on a schedule instead of a live camera feed. Looping or scheduling pre-recorded video on a VPS is the underlying mechanism that makes a FAST channel possible. Why does my looped stream freeze or show a black frame every time it restarts?
This is almost always a timestamp discontinuity: each loop iteration resets presentation timestamps to zero, which most players and CDNs interpret as a stream reset. Adding
-avoid_negative_ts make_zero and using a playout tool that stitches timestamps across loop boundaries (rather than raw ffmpeg looping) eliminates this on continuously-run channels.
Can I mix live camera segments with looped VOD on the same channel?Yes, this is exactly what Wowza’s LoopUntilLive module and similar features in Ant Media and MistServer are built for: the channel plays a filler VOD loop by default and automatically switches to a live source the moment it starts publishing, then switches back to the loop when the live feed ends.
