Cloud DVR: Live Rewind, Catch-Up & Retention | Callaba
More live video workflow notes and product updates.
Cloud DVR turns a live channel into a time-addressable media window. Viewers may pause, rewind, restart a programme, or return after it ends, but those experiences depend on more than recording the feed. The service must preserve aligned media, expose a coherent playback timeline, enforce rights and retention, and keep older objects reachable through the same authorization and delivery path.
A cloud DVR is a moving media window
Where Callaba fits in a cloud DVR architecture
Callaba Recording can capture a supported live input continuously or in timed segments, report runtime progress, and apply its documented retention behavior. The normal write path begins on the instance's internal disk; compatible connected storage can instead be mounted into the media workflow as a POSIX path where the deployment supports it. Completed assets then enter Callaba File Manager for inventory, preview, download, reformatting, transcoding, copy, or removal. These are useful recording and file-lifecycle building blocks. Callaba does not currently document a turnkey per-viewer cloud DVR service that automatically creates start-over or catch-up manifests, manages programme rights, and maintains a rolling seek window.
| Job | Callaba action | Separate system boundary |
|---|---|---|
| Capture the channel | Create a Recording from a verified live input; choose a documented output, continuous or time-split mode, and an approved local or connected mounted path | Programme schedule, rights markers, and timeline normalization |
| Prove recording progress | Inspect input bitrate, frame cadence, encode speed, and output progress | Viewer manifest freshness and seek behavior |
| Manage completed media | Inspect the managed asset in File Manager; create the required derivative or copy it to a configured destination only after verification | Rolling-window indexing, CDN invalidation, entitlement, and deletion across every delivery copy |
Start with one channel and a short non-production retention window. Confirm continuous capture on the selected local or mounted path, inspect files around a segment boundary in File Manager, create one required derivative, and delete the test asset under the approved policy. Add viewer rewind only after the recording evidence is stable.
Start-over, catch-up, and archive are not interchangeable
| Experience | Viewer job | Required media range |
|---|---|---|
| Live rewind | Move backward within the current channel window | A rolling interval behind the live edge |
| Start-over | Return to the beginning of a programme already in progress | Programme start through the advancing live edge |
| Catch-up | Play a recent programme after broadcast | A scheduled programme range retained for a defined period |
| Permanent VOD | Open a durable catalog asset | A finalized asset and metadata independent of the live rolling window |
The video-on-demand guide owns durable catalog delivery, and the IPTV guide owns the broader service model. Cloud DVR is the live-window system between those concepts.
Timeline integrity is the first engineering requirement
The window needs stable media timestamps, segment boundaries, discontinuity handling, programme date-time, and a channel clock that survives encoder or packager restarts. If the programme guide says a show began at 20:00 but the media timeline jumps or drifts, “restart programme” may begin in the previous show or fail at an unavailable segment.
Store enough metadata to map programme time, media time, object identity, and discontinuities. Do not rebuild this mapping only from filenames during an incident. Keep a known-good boundary sample whenever the source, encoder profile, or packager version changes.
The retention window must exist at every layer
A packager may know about an older segment while origin cleanup has removed it, or the origin may retain it while the playback service omits it. CDN caches can preserve objects after rights expire or evict them before the promised window ends. Define one authoritative retention policy and derive packager, origin, index, CDN, backup, and deletion behavior from it.
AWS describes time-shifted viewing as playback from earlier than “now” within a configured start-over window. That implementation is one reference, not a portable limit or a Callaba capability claim. The useful lesson is that “now,” the eligible window, and the requested manifest range must be explicit.
Estimate storage from the complete rendition set
A first-order estimate is:
retained bytes ≈ aggregate delivered bitrate × retained seconds ÷ 8 × protected copies
Aggregate bitrate includes every retained video rendition, audio language, subtitle or timed-metadata object where applicable—not the highest video bitrate alone. Add filesystem or object overhead, replication, temporary packaging data, retry margin, and any archive copy. Measure real output for a representative day before fixing capacity.
Budget request cost and index size as well as bytes. Shorter segments create more objects and timeline entries. Longer segments reduce object count but make seeks, boundary recovery, and low-latency behavior coarser.
Rights can be shorter than technical retention
A service may be technically capable of retaining a channel for seven days while one programme permits only two hours of catch-up, another forbids restart, and a regional feed has different restrictions. Model rights by programme, territory, subscription, device, and time where required. The playback service must intersect the technical window with the viewer's current entitlement.
Deletion is part of the product contract. Track the primary object, replicas, CDN state, backups, derived clips, thumbnails, and search index. A database flag saying “expired” is not proof that the media is no longer retrievable.
Example: live playback works, but rewinding 20 minutes returns 404
The player holds the live edge, yet a seek within the advertised one-hour window requests a missing segment. The first comparison is the manifest's oldest promised time against the origin object's expiry and the CDN response. If the manifest references an object already removed at origin, the root cause is a retention-coordination failure—not viewer bandwidth. Preserve the requested range, object key, deletion event, cache status, and programme clock at that boundary.
Player behavior defines whether the feature feels trustworthy
The viewer needs a clear live indicator, the available start and end, predictable seek behavior, and an easy return to live. When a paused position expires from a moving window, define whether the player jumps to the oldest available point, returns live, or presents an error. Test captions, alternate audio, ad boundaries, and discontinuities across the seek.
Authorization must be re-evaluated where policy requires it. A viewer who started while entitled may cross a token expiry or programme rights boundary during a long pause. Coordinate token refresh with manifest and segment access so recovery does not look like random buffering.
Commission one full lifecycle
- Enter live. Confirm the live edge, programme identity, audio, captions, and rendition ladder.
- Pause and resume. Hold inside the window, then verify a continuous timeline and current entitlement.
- Restart the programme. Compare the requested start with schedule and media timestamps.
- Cross a discontinuity. Restart an upstream component and confirm that playback survives the recorded boundary.
- Reach the oldest point. Seek to just inside and just outside the allowed window.
- Expire the asset. Verify manifest removal, object deletion, CDN behavior, index cleanup, and audit evidence.
Monitor both the live edge and the oldest promised media
Most live monitors watch only the newest playlist and segments. A DVR service also needs a probe near the oldest advertised point and at programme boundaries. Track ingest continuity, segment/index agreement, oldest available time, manifest generation, origin/CDN retrieval, authorization, seek start time, playback errors, deletion lag, and storage growth.
The live recording product page describes the capture module. The File Manager guide covers the completed asset's managed lifecycle and an optional copy to a configured storage destination. Neither proves the viewer's rolling manifest or rights behavior.
Cloud DVR FAQ
Is cloud DVR just a long HLS playlist?
No. The playlist or manifest is one view of retained media. The service also needs timeline metadata, storage, authorization, programme rights, seek behavior, monitoring, and deletion.
How large should the rewind window be?
Choose it from the viewer promise, content rights, storage and request cost, CDN behavior, and operational evidence. A longer technical window is not useful when rights or deletion cannot support it.
Can a continuous MP4 recording provide live rewind?
It can be an archive input, but live rewind normally needs media and an index that can be addressed safely while the channel continues. Test the exact packaging and playback workflow rather than equating file growth with DVR readiness.
What should a DVR monitor request?
Probe the live edge, a recent rewind point, the oldest advertised interval, and a programme boundary through the real viewer authorization and CDN path. Each location exposes a different failure.