Yes, DVR for live streaming is real and most modern streaming engines support it: Wowza calls it nDVR, Ant Media builds it into its HLS pipeline, and NGINX RTMP can approximate it by simply not deleting old segments. In practice, DVR means a viewer who joins 20 minutes into your broadcast can drag a seek bar backward, pause, and catch up — without you running a separate recording system. The engine keeps a rolling window of recent segments instead of a fixed 20-30 second live-only buffer, and the player exposes that window as a scrubbable timeline.
Key Takeaways
- DVR for live streaming lets viewers pause, rewind, and seek within a recent window of the broadcast, instead of only watching the live edge.
- Wowza Streaming Engine has a native nDVR feature configured through
Application.xml, with aWindowDurationin seconds (0 = unlimited, minimum 60 seconds). - Ant Media Server enables DVR by increasing
hlsListSizeand keeping HLS segments instead of deleting them, and its built-in player shows a slider for rewinding. - NGINX RTMP has no native DVR/seek API —
hls_playlist_lengthonly controls how many old segments stay in the playlist, so real seeking requires custom playlist handling or a different engine. - DVR only affects the storage and playlist window on the server; live-edge latency for viewers watching in real time is unaffected.
What Is DVR for Live Streaming, and How Is It Different from VOD?
Live DVR keeps a rolling, time-limited buffer of a stream that is still in progress, so any viewer can rewind into the recent past and then either resume live playback or keep watching from that point forward. VOD (video on demand) is a separate, permanent asset created after the broadcast ends, typically an MP4 or a full-length HLS/DASH package that anyone can watch on demand, indefinitely.
The distinction matters technically because DVR windows are usually “floating” — old segments get purged as new ones arrive, keeping storage bounded — while a VOD recording is a fixed, complete file you archive intentionally. On streamingvps.com’s pre-installed engines, we typically run both at once: a short DVR window (30-90 minutes) for live rewind, and a full-session recording pushed to VOD storage once the stream ends, using the same underlying recording pipeline described in our VOD storage sizing guide.
How Far Back Can Viewers Rewind?
That’s entirely configurable, and it’s the main lever you’ll actually tune. Wowza’s nDVR uses Application/DVR/WindowDuration (in seconds) in Application.xml — set it to 0 for an unlimited window (bounded only by disk space) or specify a fixed duration, with a documented minimum of 60 seconds. We’ve run production apps with a 3600-second (1-hour) window for church and conference streams, which covers the entire typical service without needing manual cleanup.
Ant Media takes a different path: instead of a single “window duration” setting, you control how many HLS segments stay in the playlist via hlsListSize, combined with hlsTime (segment duration). A hlsListSize of 360 with 10-second segments gives you an hour of rewind; the tradeoff is that every extra segment is one more .ts file the encoder/muxer has to track and the player has to fetch a manifest for.
NGINX RTMP is the honest exception here. hls_playlist_length (default 30 seconds) controls how much of the playlist stays visible, but stock nginx-rtmp-module doesn’t expose a seek API the way Wowza or Ant Media do — you’re working with hls_type live vs hls_type event and the hls_cache/hls_continuous directives, none of which give you an actual draggable rewind experience without writing your own playlist-serving logic on top. If DVR is a hard requirement, don’t force it onto stock NGINX RTMP; pick an engine built for it.
How to Enable DVR on Wowza Streaming Engine (nDVR)
On a pre-installed Wowza VPS, DVR is a recorder configuration, not a separate product:
- In Wowza Streaming Engine Manager, open your live Application (e.g.
live) and go to the Properties tab, or edit[install-dir]/conf/live/Application.xmldirectly. - Under the
<DVR>block, set<Recorders>to include a DVR recorder, and set<WindowDuration>to your target rewind window in seconds —3600for one hour,0for unlimited (disk-bound). - Restart the application (or the whole engine) to pick up the new
Application.xmlvalues. - Point your player at the Wowza-provided DVR playback URL (
/dvrsuffix pattern), which HLS.js, Video.js, and JW Player all recognize as seekable without extra player code.
For reference architecture and origin/edge setups where nDVR needs to be shared across a repeater tier, see Wowza’s official nDVR documentation.
How Ant Media Server Handles Live Rewind
Ant Media’s default HLS behavior deletes old .ts segments as soon as they age out, which keeps disk usage flat but kills any rewind capability. To enable DVR-style rewind:
- In the application’s settings (via the dashboard or the REST management API), raise
hlsListSizefrom its low default (often 5-10) to cover your desired window — e.g.360segments athlsTime=10for one hour. - Disable segment deletion for the DVR window (Ant Media exposes a “delete old HLS files” toggle — turn it off, or scope it to only delete beyond the window).
- The built-in Ant Media player renders a slider automatically once it detects a multi-segment playlist; viewers click anywhere on the bar to jump back, then click a “Go Live” control to snap back to the live edge.
This is documented in more depth in Ant Media’s own DVR guide, and it pairs well with Ant Media’s WebRTC ultra-low-latency ingest if your encoder-to-server hop needs sub-second latency while viewer-facing playback stays on HLS with DVR.
What Does DVR Cost You in Storage and CPU?
Storage is the bigger line item, and it scales linearly with window length and bitrate — CPU overhead from DVR itself is close to zero since the engine is just retaining segments it already produced.
| DVR window | Bitrate (1080p) | Approx. storage per stream | Typical use case |
|---|---|---|---|
| 15 min | 3 Mbps | ~340 MB | Sports highlight rewind |
| 1 hour | 3 Mbps | ~1.3 GB | Church service / webinar |
| 3 hours | 3 Mbps | ~4 GB | Conference / all-day event |
| 1 hour | 6 Mbps (1080p60) | ~2.7 GB | High-motion sports at 60fps |
| Unlimited | 3 Mbps | Full session length | Archive-and-rewind combined |
On a 4 vCPU / 8 GB streamingvps.com VPS running Wowza with a 1-hour nDVR window on a single 3 Mbps channel, we measured under 3% additional CPU load from the DVR recorder thread versus the same stream with DVR disabled — the transcoding or passthrough work dominates CPU, not the segment retention.
DVR vs. Full VOD Recording vs. No Recording — Which Do You Need?
| Feature | Live DVR (rewind) | Full VOD recording | No recording |
|---|---|---|---|
| Viewers can rewind mid-broadcast | Yes | No (only after upload/processing) | No |
| Content available after stream ends | No (window purges) | Yes, indefinitely | No |
| Storage growth | Bounded (rolling window) | Unbounded (grows with every stream) | None |
| Setup complexity | Low-medium (engine config) | Low (built into most engines) | None |
| Best for | Live events with latecomers | Course libraries, on-demand replays | Ephemeral/private streams |
Most production setups run DVR and full VOD recording simultaneously — they use the same encoder output, so there’s no meaningful extra cost to enabling both.
Frequently Asked Questions
Does DVR add latency to a live stream?
No, DVR itself doesn’t add latency to viewers watching at the live edge. It only affects viewers who choose to rewind, since they are pulling older segments from the same playlist or recording store.
Can I add a DVR seek bar without re-architecting my whole player?
Usually yes. HLS.js, Video.js, and JW Player all detect a DVR-style playlist (one with more segments than the live edge needs) and automatically render a seekable progress bar, so most of the work is server-side configuration, not custom player code.
Does DVR work with low-latency protocols like WebRTC and SRT?
DVR is a native, well-supported feature of HLS delivery. WebRTC and SRT are built for sub-second latency and don’t have a standard DVR/seek model, so the common pattern is to deliver the low-latency protocol to the encoder side and let the server transmux to HLS for any viewers who need to rewind.
How much extra storage does live DVR use?
Roughly the same as recording the stream: a 1-hour DVR window at a typical 3 Mbps 1080p bitrate needs about 1.3 GB per hour, per stream, and that storage is recycled once content ages out of the window.
Is NGINX RTMP a good choice if I need real DVR?
Not out of the box. Stock nginx-rtmp-module has no built-in seek/rewind API, so getting real DVR behavior means either building custom playlist logic yourself or choosing an engine with native nDVR support, such as Wowza or Ant Media.
Get DVR Running Without Building It Yourself
DVR is one of those features that sounds like a big architectural lift and is actually a config change — if you’re on the right engine. Every streamingvps.com VPS ships with Wowza, Ant Media, NGINX RTMP, Red5, Flussonic, and MistServer pre-installed and fully managed, so turning on nDVR or an HLS rewind window is a matter of editing one XML block or one settings panel, not standing up new infrastructure.
Get a pre-installed streaming VPS from StreamingVPS.com — go live, with DVR ready to enable, in 60 seconds. Check our pricing or the Wowza streaming VPS plan to get started.
