What is DVR in live streaming?
DVR (Digital Video Recording) on a live stream is the ability for a viewer to scrub backwards into content that has already been broadcast. Pause the stream at 3:14 PM, come back at 3:20, and press play — the stream resumes from 3:14, not from the current live edge.
From the player's perspective, a DVR-enabled live stream has a seekable range that grows over time. From the server's perspective, the media playlist has to keep referencing old segments instead of aging them out of the window.
How it works under the hood
A classic live HLS playlist is a sliding window:
#EXT-X-MEDIA-SEQUENCE:245
(segments 245 .. 252)
Only the most recent ~8 segments are listed. As new segments arrive, old ones drop off the top and are eventually deleted. Players can't seek back past what's in the playlist.
For DVR:
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-MEDIA-SEQUENCE:0
(segments 0 .. 252)
PLAYLIST-TYPE:EVENTtells the player this is a live stream that grows; old segments are not pruned.MEDIA-SEQUENCE:0stays at zero — the player can seek back to the very start of the event.
For LLHLS the mechanics are identical, but the playlist keeps a large sliding window sized to the desired DVR duration (e.g. 3,600 seconds / 6-second segments = 600 entries).
What the player does
DVR-aware players honor the EVENT type and expose a seek bar that reflects the full seekable range. Any player capable of reading #EXTINF durations and #EXT-X-MEDIA-SEQUENCE can seek within the advertised range.
Players to reach for:
- OvenPlayer — built for low-latency streaming; full DVR UI.
- hls.js — works with DVR if you configure
liveDurationInfinity: false. - video.js with HLS support.
- Safari native — handles
EVENTtype natively.
Players that only understand classic live HLS (infinite seek disabled by default) will sometimes pin the playhead to the live edge even when the server offers DVR. That's a player-configuration issue, not a server one.
Cost trade-offs
DVR isn't free. Cost scales with:
- Window duration × number of renditions × segment size. A 6-hour DVR window over 3 renditions at ~3 Mbps average produces ~24 GB of content that must be addressable.
- Memory. Live packagers keep DVR segments indexed in memory per rendition. Large DVR + many renditions = significant RAM per stream.
- Playlist size. 6h / 6s = 3,600 entries in the playlist. Clients fetch this every few seconds; playlist size matters.
Hakari's plans have different maximum DVR windows — pick the smallest window that gives your viewers what they need.
DVR + recording — related but separate
DVR lets viewers seek during a live stream. Recording produces a permanent VOD asset after the stream ends.
You can enable both on the same stream:
- DVR on → viewers can scrub back during the live event.
- Recording on → a permanent VOD playlist lives in S3 after the stream ends.
The two features don't interact at the cost level — DVR serves from the live path, recording is a separate S3 upload pipeline.
DVR on Hakari
Toggle DVR on a stream at create time and set the window in seconds. The stream detail page shows the current DVR duration under Recording & DVR.
What you get:
- Playback URL (
/app/<streamKey>/index.m3u8) delivers a DVR-enabled LLHLS playlist. - Seek range grows as the stream progresses, capped at the configured DVR duration.
- Older-than-window content rolls off (viewers can't seek past it).
- Session boundaries (encoder disconnect + resume) are handled with
#EXT-X-DISCONTINUITY+ fresh init segments — DVR seeks across them cleanly. - Combined with signed playback, every playlist + segment fetch validates against
?policy=&signature=.
When to turn DVR off
- Ultra-low-latency one-shot events (auctions, betting) where seekback changes the UX contract.
- Streams where you strictly don't want viewers to review history.
- High-rendition high-duration streams where the RAM cost isn't worth it to you.
When to turn it on
- Long-form content where viewers arrive mid-stream (conferences, sports).
- Events where key moments matter and viewers want to rewatch without waiting for the VOD.
- Any time the UX "oh wait, what did they say?" would make sense.