Digital video recording: from live source to stored media
Digital video recording retains media from a live source for later playback, with source acquisition, storage completion and library presentation forming distinct stages.
A digital video recorder, or DVR, turns arriving television media into a stored presentation that can be watched later. The programme listing supplies the intent and description; the media source supplies what is actually recorded.
The retained file may contain compressed streams from the source or media prepared by the chosen recording route. Recording does not inherently mean decoding every picture and encoding it again.
Emby’s DVR settings connect recording paths, padding, buffering and optional later processing.
From a request to retained media
A simplified recording path has several stages:
The timer identifies the intended channel and interval. Acquisition needs a compatible available source. The recorder then receives and writes usable media, preserving the container and stream information required to read it later.
The file becomes a library item through another association with metadata, images and the recording path. A visible library entry does not by itself establish that every requested second was captured.
These are different results: a planned recording, an open source, advancing media, advancing stored bytes and a readable completed artifact.
Storage follows the retained payload
For an original constant-payload exercise, let the recorded stream use ten Mbit/s for sixty minutes:
10,000,000 bits/s × 3,600 s ÷ 8 = 4,500,000,000 bytes
= 4.5 GB
Here GB means a billion bytes. Container overhead, extra retained streams and filesystem allocation are excluded.
Adding two minutes before and five after extends capture to sixty-seven minutes. Under the same deliberately constant payload, the result becomes 5.025 GB.
The rate describes what is written, not necessarily the channel’s complete RF multiplex or the smaller stream an app receives later. A full-multiplex source can carry other services that the recorder discards before writing; a playback conversion can produce another bitrate after recording.
Variable bitrate requires integrating the actual rate over time. A file size divided by an assumed rate gives only an estimate of captured duration.
Stopping and completing are different conditions
When the requested interval ends, acquisition stops. The recording route can still need to finish a container, flush writes and make its metadata consistent.
A stream-oriented container and a container requiring finalized indexing can expose different growing-file behavior. Container seeking describes how those structures affect navigation.
The application’s successful status is a workflow result. A readable file is a media result. Durable storage is another property of the write/flush and storage path. Neither filename nor timer creation proves all three.
An incomplete recording can remain useful even after a late start, source gap or early stop. The stored result needs its actual coverage considered rather than simply being classified by whether a file exists.
Playback is a later compatibility decision
Emby presents recordings through the media playback system. An app can receive the stored streams directly, in another container or after transcoding according to its capabilities.
A recording that was inexpensive to capture can therefore require substantial processing to play on a particular client. Conversely, transcoding during playback does not change which earlier programme intervals were saved.
See Also
- What is live TV?
- Recording timers and acquisition deadlines
- Incomplete recordings and missing programme intervals
- Chase playback while a recording grows