Live stream¶
media.live.streams
A live stream in Sapsan is a named stream that combines media ingest, processing, and delivery to consumers. Media arrives and is processed as new frames become available. The stream has a configuration and a current state. A single name can include:
- Video — multiple renditions.
- Audio — tracks in different languages.
- Subtitles — text tracks.
These all remain tracks of the same stream.
On an individual server, a live stream manages a running media pipeline. In central, the same stream is represented as a cluster object: its functions can run on several servers simultaneously.
Stream on one server¶
A local stream instance is a pipeline manager. It connects processing components, passes settings to them, and manages their lifecycle. The pipeline composition depends on the configuration and this server's role in serving the stream.
| Component | Responsibility |
|---|---|
| Input | Receives media from a source or accepts a publication. Manages the connection, reconnections, and backup source selection. |
| Transcoder | Decodes and encodes media according to the stream settings, producing the required codecs and quality ladder. |
| Processing | Performs configured processing: subtitle extraction, thumbnail generation, and metadata and event processing. Tasks such as speech recognition can work on an already recorded archive. |
| Segmenter | Assembles segments and partial segments, maintaining a live window for segment-based delivery. |
| DVR recording | Passes prepared segments to the archive subsystem and monitors the recording state. |
| Pushes | Send media to configured destinations. Each destination has its own connection and reconnection state. |
| Relays and subscribers | Receive stream frames or segments for protocol-specific delivery to viewers and other servers. |
Data flows into several branches: the same processing output can be sent to the archive, pushes, and viewer delivery simultaneously. Each additional viewer does not require separate ingest and transcoding. Segment-based delivery reads prepared segments, while continuous transmission protocols receive a stream of frames or transport packets.
The manager accepts configuration changes, updates components, and collects their state. Input reconnection, push recovery, and transcoder restart are part of the local pipeline lifecycle. Changing parameters or recovering a component can interrupt the corresponding part of processing.
Learn more about the components:
Cluster stream in central¶
Central stores the stream's overall configuration: which source to ingest and which functions to perform. The operator changes it through the central API. The layouter determines which streamers serve the stream and in which roles. Central generates and delivers the configuration for each server's part of the work.
A single cluster stream thus has several local representations. The ingest server runs the ingest and processing pipeline. On the DVR streamer, the same stream receives prepared media for recording. On an edge, it serves viewers, using a cache when needed. Each server performs the functions assigned by its configuration.
| Level | What it describes |
|---|---|
| Cluster stream | The overall configuration and stream name, which persist when its placement changes. |
| Assignment | Which streamer performs a specific role: ingest, archive recording, or delivery. |
| Local instance | The pipeline running on a server with the configuration delivered to it. |
Distribution allows several servers to perform different functions for a single stream simultaneously. For example, ingest and transcoding can run on a server with suitable hardware, the archive can be recorded on dedicated storage, and edges near viewers can handle delivery. Available roles and assignment rules are described in stream placement.
Distribution example¶
The news stream has transcoding and archive recording enabled. It uses the following servers:
- Server A — ingest: receives the source and produces the quality ladder.
- Server B — recording: receives prepared media from A and records the archive.
- Servers C and D — delivery: receive live media from A, read the archive from B, and serve viewers. With the archive cache enabled, repeated requests can be served locally.
The operator manages one stream, news. Different parts of its processing and delivery run on the servers. Adding an edge does not require creating a separate operator-managed stream with a different name.
Changes and failures¶
When placement changes, central delivers updated configurations to the affected streamers. The cluster stream's name and overall configuration persist; the set of local instances and the functions they perform can change.
Local recovery and cluster reassignment address different tasks. A streamer reconnects its own input or switches to a configured backup. The layouter decides whether to move work to another server based on cluster state and placement rules.
If the connection to central is lost, an already running streamer continues using the last applied configuration. Delivering new settings and reassigning work require an operational control plane. The states of individual components and servers should be considered together: successful delivery from one edge alone does not confirm that archive recording continues on the DVR streamer.