DVR Window

The DVR window is how far back from the live edge a viewer can seek in a live stream. It is not an archive and not video on demand. It is a span defined against the current clock, and that span slides forward as the broadcast continues. Its real definition is whatever the packager still lists in its manifest. In HLS that is a sliding-window media playlist. The server keeps trimming it from the front (RFC 8216, section 6.2.2). In DASH the same span is called the time shift buffer. It extends from now minus MPD@timeShiftBufferDepth to now (DASH-IF Interoperability Guidelines, Time shift buffer).

A reader can stop here with the correct picture. The window is a promise: any segment a loaded playlist still names must be available for immediate download. Otherwise playback errors can occur (RFC 8216, section 6.2.1). So the window is not a player feature. It is a statement about how much live content the delivery chain must keep instantly retrievable. Widening the window buys rewind, but it costs storage and cache footprint. Narrowing the window saves both, but it takes rewind away. It does not move the live edge. It does not change stream latency. It only changes how far back the timeline reaches.

How it works

New media is appended at the live edge, and the oldest media falls off the other end. So the manifest is the window.

In HLS the server may limit segment availability by removing Media Segments from the playlist. If it does, the playlist must carry an EXT-X-MEDIA-SEQUENCE tag. The tag's value must be incremented by one for every segment removed. Segments must be removed in the order they appear. Otherwise client playback can malfunction (RFC 8216, section 6.2.2). A live playlist has no EXT-X-ENDLIST tag. While that tag is absent, the server must publish a new version of the playlist containing at least one new segment. It must do so no earlier than half a target duration after the previous version. It must do so no later than 1.5 target durations after the previous version (RFC 8216, section 6.2.1). That publish cadence bounds how long the manifest may be cached, not the window length.

In DASH the window is the time shift buffer. Its start is now minus MPD@timeShiftBufferDepth. If that attribute is absent, its start is the effective availability start time of the presentation. Clients may present segments that overlap the buffer in full or in part. Clients must not present samples from segments that fall entirely outside it. MPD updates remove segment references and periods that have fallen out of the buffer. An MPD of a dynamic presentation must not carry unnecessary segment references (DASH-IF, Removing content from the MPD).

The window and the segment length together fix the object count. The count is window duration divided by the target duration, per rendition.

• A six-second target duration and a two-hour window is 1,200 segments per rendition (7200 / 6). Five ABR renditions make 6,000 objects for one channel, before audio and subtitle tracks.
• HLS pays for the window in the manifest. The server creates a media playlist containing a URI for each segment it wishes to make available (RFC 8216, section 6.2.1). So the playlist file itself grows with the window. It is re-fetched by every player every few seconds.
• A DASH MPD need not grow. Template and timeline addressing describe segments without listing each URL. Expired segment references must be removed on update. So the MPD stays small even for a long window.
• RFC 8216 sets segment duration as less than or equal to a constant target duration. So segment counts derived this way are a planning figure, not an exact one. DASH places no equivalent single-target rule on the presentation.

Why it matters for a CDN

The window is the working set the edge has to serve. Footprint is arithmetic: window seconds times the summed bitrate of all renditions, per channel. Two hours of a channel carrying 12 Mbps across all renditions is roughly 10.8 GB resident. A hundred channels is a terabyte of live content. That content has to stay reachable while it churns completely every two hours.

Here is the same sum for one channel:

# Example: CDN cache sizing for a DVR window
# 1 channel, 5 bitrates, 6s segments, 2h window
# Segments: (7200s / 6s) * 5 = 6000 segments
# Average segment size at mixed bitrates: ~2MB
# Cache needed: 6000 * 2MB = ~12GB per channel

The load inside the window is very uneven. Almost all requests land on the newest few segments, which are hot everywhere. The rest of the window is requested only by the minority of viewers who joined late or seeked back. Those requests are the ones that miss and go to origin. So a long window lowers cache hit ratio, even when total bytes served barely change. How viewers address that older content matters as much as its age. AWS advises using consistent playback windows across player sessions for time-shifted viewing. AWS advises against generating a unique start or end time for each viewer. Consistent windows yield better caching at the CDN and avoid request throttling (AWS Elemental MediaPackage, Time-shifted viewing). Per-viewer window parameters turn one cacheable manifest into one manifest per session.

Once media leaves the window, it can be evicted from cache. It can also be deleted at the packager when nothing is archiving it. Wowza, for example, purges recorded data that falls outside the window from its DVR store. The manifest is the opposite case: it is the hottest and shortest-lived object of the stream. It is where DVR windows usually break.

What CDNs do

The window is configured on the packager or streaming platform, not in CDN transport. But platforms that also deliver expose it directly. Each has its own ceiling.

• Cloudflare Stream makes it opt-in. Adding dvrEnabled=true to the player embed or HLS manifest URL turns on DVR mode. Viewers can then rewind, resume and fast-forward a live broadcast. Cloudflare documents several constraints. Manifests are limited to a maximum of 7,200 segments. Performance may be degraded for DVR-enabled broadcasts longer than three hours. DVR mode relies on version 8 of the HLS manifest specification, where Stream otherwise uses version 6. DVR mode is not available for DASH manifests.
• AWS Elemental MediaPackage separates eligibility from the request. The startover window on the endpoint defines which live content can be viewed on demand. It can be up to 24 hours long. MediaPackage also supports time-shifted viewing for content up to 336 hours (14 days) old. Players then request a slice of that window with start and end parameters.
• Wowza Streaming Engine nDVR offers a window duration option with a minimum supported value of 60 seconds. Wowza describes it as a floating window that always ends at the current live point. Recorded data that falls outside it is purged from the DVR store. Its documentation states you can record up to 30 hours of content for DVR playback. The same note warns that longer durations may bring performance and playback problems.

Watch out for

• Manifest TTL longer than the publish interval. A cached playlist can outlive its refresh cadence. Then it hands clients references to segments the server has already dropped. A server may plan to remove a segment after delivering it. RFC 8216 tells that server to send an Expires header reflecting the planned time-to-live (section 6.2.2). An edge that ignores that is the usual cause of DVR stalls.
• Evicting on removal from the manifest. When the server removes a segment URI from the playlist, that segment must remain available to clients for a period: the duration of the segment plus the duration of the longest playlist file the server distributed containing it (RFC 8216, section 6.2.2). Purging at the moment of removal interrupts playback already in progress.
• Shrinking a live window too far. A live playlist has no EXT-X-ENDLIST tag. A server must not remove a segment from such a playlist if doing so would leave a playlist duration less than three times the target duration (RFC 8216, section 6.2.2). Three target durations is the floor for a live HLS window. That floor holds whatever the product setting says.
• Assuming DASH seeking reaches the whole buffer. Presentation delay moves the end point of the time shift buffer into the past. Clients are required to constrain seeking to that effective time shift buffer (DASH-IF, Presentation delay). The seekable range is therefore shorter than timeShiftBufferDepth. This is a client-side constraint, not a server refusal.
• Leaving MPD@timeShiftBufferDepth unset. The buffer then starts at the effective availability start time. For a long-running channel, the window is then effectively unbounded, and so is the storage it requires.
• Treating an out-of-window request as an ordinary cache miss. It is a product-visible failure. MediaPackage fails the playback request when the start parameter is outside the startover window. So the player gets an error rather than a slow response.
• Reading a vendor ceiling as a protocol limit. Cloudflare's 7,200-segment manifest cap, MediaPackage's 24-hour startover window and Wowza's 30-hour recording are per-product figures. None of them are properties of HLS or DASH.
• Confusing start-over with a DVR window. Start-over means joining a programme from its beginning. It needs reach back to the programme boundary, not a fixed rolling span. MediaPackage models it as a separate eligibility window precisely because the two do not size the same way.

Best practice

• Size the window from the viewer requirement first. Then compute the bill: window seconds times summed rendition bitrate times channel count, at both edge and origin.
• Count objects, not only hours. A long window with short segments multiplies manifest length and object count for the same duration. Low-latency profiles such as LL-HLS encourage short segments. Cloudflare's segment cap shows where that multiplication ends.
• Cap manifest TTL at roughly one target duration, not at any value derived from the window length. Align it with the Expires header the server sends.
• Keep a segment cached until the RFC 8216 grace period after it left the manifest has elapsed. Do not stop caching it the moment it left the manifest.
• Hold window parameters identical across player sessions. Then time-shifted manifests remain a small shared set of cacheable objects.
• Split the products. Use a short rolling rewind window for live content. Add a separate catch-up or start-over asset for anything longer. That split is cheaper and more cacheable than one very deep live window.