DVR, Clips, and VOD: What Happens After the Live Edge
A live stream, at the edge, is a ring buffer. MistServer keeps a bounded window of segments on disk, old ones fall off the back, and when the stream ends the buffer eventually stops mattering. Everything that outlives the broadcast (the seekable archive, the highlight clip, the replay a viewer opens next week) has to be copied out of that buffer before it disappears.
Short streams make that easy to get roughly right. Long ones do not. This post follows one always-on channel through three months of recording, a plan change and a highlight clip.
A channel that never stops is one recording
Section titled “A channel that never stops is one recording”Picture a 24/7 channel, such as a venue camera that nobody turns off. It goes live on the first of the month and stays live for 90 days.
On FrameWorks that is one recording. A session produces one DVR artifact with no per-artifact length cap, so a channel that streams for 90 days straight is one artifact. If the stream drops and comes back an hour later, that is a new session and a new recording.
We got there by separating three clocks that look related but are not:
- The live DVR window is how far back a viewer can scrub while the stream is up. It is sized by plan and kept short so live playlists stay small.
- The session is the recording itself, as long as the ingest stays live.
- Retention is how long the archive survives after the stream ends, counted from the moment the session finishes. An active recording is invisible to retention: a channel on day 89 cannot lose day 1 to an expiry timer.
Underneath, every recorded segment is tracked with its position in stream time and where it is stored. Playlists are generated from that record when something needs one, so there are no manifest files in object storage that can drift out of step with the media they describe.
Replaying three months without downloading three months
Section titled “Replaying three months without downloading three months”Nobody wants to open a 90-day file. So replay works through chapters: bounded slices of the recording, each finalized into its own ordinary VOD asset. Chapters can match the length of the live window or follow fixed UTC intervals such as hourly or daily, so an application that wants “yesterday afternoon” converts that to a UTC range and lists the chapters in it. Each chapter keeps wall-clock timing, so a player can show the real time of day for any position.
A chapter becomes playable as soon as it is finalized, and is later uploaded to object storage, after which the temporary per-segment copies are removed. If a chapter cannot be built because its source segments were lost, it is marked failed rather than published as a shorter file that pretends to be complete.
Because chapters are ordinary VOD, they follow the same playback path, the same access policy and the same rules across clusters as any uploaded video. A remote cluster never asks for “the 90-day archive”; it asks for a chapter. If that chapter is already in object storage, the viewer gets a signed download from storage. If it is not uploaded yet but the node that recorded it still has the complete file, it is served from there. If neither is true yet, the request is refused with a retryable answer, and a later attempt succeeds once the upload finishes.
What a plan change does to an archive in progress
Section titled “What a plan change does to an archive in progress”On day 40, the channel’s owner changes plan. The obvious question is what happens to the recording that has been running for 40 days.
Nothing, until it ends. The retention that applies to a recording is resolved when the recording starts and stored with it. A downgrade halfway through never quietly shortens an archive that is already recording, and the plan in force when the stream finally stops is never looked up again to recompute it. The new plan applies from the next session.
Re-resolving retention at the end would let a plan change reach back and shorten weeks of footage someone was counting on, so we chose to resolve it once, at the start. If you want a particular archive kept longer, you can set a retention override on that finalized asset afterwards, within your plan’s cap.
The same rule applies to chapter settings: changing how a stream cuts chapters takes effect from the next broadcast, and a recording in progress keeps the setting it started with.
Clips come from the same place
Section titled “Clips come from the same place”On day 63 something worth sharing happens. A clip can be cut from the live buffer, from the rolling DVR window, or from a chapter that has already been finalized. It goes through the same processing path as chapters and produces the same kind of VOD asset. A clip that fails is marked failed and shows up that way in the dashboard, instead of a spinner that never resolves.
What it costs
Section titled “What it costs”A long recording is only as durable as its path to object storage. Edges evict local segments under disk pressure, oldest first, because the durable copy lives in object storage. Every cleanup step deletes only after that durable copy is confirmed, so a crash in the middle of cleanup leaves extra data behind, never missing data.
The live window is also not the archive. A viewer who joins on day 90 can scrub back only as far as the live window allows; everything older is reached through chapters.
Docs: DVR chapters, clips, recordings, storage and retention, and the operator’s view in DVR operations.