OTT and DVR¶

The OTT subsystem delivers streams over HTTP-based protocols: HLS (over MPEG-TS), MPEG-DASH and Low-Latency HLS (over CMAF — fragmented MP4), as well as MPEG-TS over HTTP. HTTPS and HTTP/3 (QUIC) are supported. Delivery is enabled on the “OTT” tab of the stream editor (Configure stream) and is available to SPTS streams only; a multiplex program is extracted into an SPTS stream by the demultiplexer (Demultiplexer).

DVR is a persistent on-disk archive of a stream. It is written in parallel with OTT delivery — no separate recording service is required — and is played back through the same URLs as the live broadcast; only the query parameters differ (DVR: the stream archive).

Delivery modes¶

Progressive MPEG-TS delivery over HTTP is enabled by the “HTTP service” setting (value Live): continuous transmission of the source transport stream within a single HTTP response.

Segmented delivery is controlled by the “HLS service” setting (values as shown in the interface):

Peering / HLS: Plain segmentation. The mode is intended for transferring a stream between Perfect Streamer nodes: the delivering node serves HLS over MPEG-TS and the receiving node connects with an input of type HLS. WebVTT subtitles and DRM are not available in this mode, and DVR recording cannot be configured.
OTT / HLS: Segmentation optimized for fast player start-up in OTT delivery (CPU load is higher). HLS is served over MPEG-TS; GOP-aligned segmentation applies (Segmenter).
OTT / LL-HLS / DASH: Delivery over CMAF: the stream produces fMP4 segments on top of which MPEG-DASH and Low-Latency HLS are served. When the “Legacy MPEG-TS HLS chunks” setting is enabled (the default), conventional HLS over MPEG-TS is served in addition; disabling it saves disk space and CPU. MPEG-DASH and Low-Latency HLS are available in this mode only.

Low-Latency HLS splits the media playlist into partial segments (parts): the player starts playback without waiting for a complete segment; blocking playlist reload and the preload hint are applied. The part target duration is set by the “LL part target duration (ms)” setting (advanced setting; 500 ms by default, applied on the fly, and it must be less than the minimum chunk interval). For accurate low latency the DASH manifest carries a mapping of media time to UTC, and the CMAF segments carry producer reference timestamps.

Note

CMAF packaging carries AAC and AC-3 audio tracks only; tracks in other codecs are discarded and an alert is raised (Alerts (alerter)).

Segmenter¶

In the OTT modes the stream is analyzed against the PAT/PMT tables and the key frames, and segments are cut according to a fast player start-up criterion. Cutting is controlled by the “Chunk min interval (s)” and “Chunk max interval (s)” settings: the analysis starts at the minimum interval, and if no cut point is found the segment is force-closed at the maximum.

“GOP-aligned segments” (enabled by default; effective in the OTT / HLS mode) — the segmenter aligns segment boundaries with random access points and distinguishes an IDR frame from an ordinary I-frame. For closed-GOP sources every segment is guaranteed to start with SPS/PPS/IDR — a complete entry point; the “tail” of the previous GOP is cut off. This eliminates the black frame at the start of VOD sessions and brings delivery into conformance with the HLS requirements (RFC 8216). The GOP structure type of the source is visible in the analyzer metrics (In-depth analyses). Because of the alignment the actual segment duration may exceed the minimum interval — the target duration declared in the playlist reflects the actual maximum.

URLs and authorization¶

Delivery is served by the node streaming HTTP server (Streaming HTTP server). A URL is built according to the scheme:

http://host:port/hls/<stream>/<login>/<password>/index.m3u8
http://host:port/hls/<stream>/<login>           — token authorization
http://host:port/hls/<stream>/                  — IP authorization

/dash/, /llhls/ or /http/ is substituted for /hls/; for adaptive bundles — /hls/adaptive/ and the like (Adaptive bundles). <stream> is the stream identifier or the name set by the “URL stream name” setting. Unauthorized access is denied: client logins and permissions are configured in the web interface (Users / Logins).

Ready-made URL templates for the currently enabled delivery modes are shown in the stream statistics window — the “Delivery URLs” section with a copy button (Stream statistics). Active client sessions are visible on the “Clients” screen (Clients).

HTTP/3 (QUIC)¶

The streaming HTTP server can serve the OTT routes (HLS, DASH, LL-HLS, MPEG-TS over HTTP) over QUIC. HTTP/3 is enabled in the streaming HTTP server settings (Streaming HTTP server); the certificate used is the same as for HTTPS, but HTTPS itself does not have to be enabled — QUIC listens separately and reads the certificate files directly. It is exactly those files that are required: without the certificate and the key the HTTP/3 listener will not come up.

Browser clients switch to QUIC through the standard Alt-Svc advertisement: the advertisement is issued on an explicit client request — the ?h3 parameter on the master URL. If the QUIC connection cannot be established (UDP port closed, untrusted certificate), the client transparently stays on HTTPS — delivery is not interrupted. Administrative requests are served over TCP only. Low-Latency HLS and DASH over QUIC are delivered incrementally — parts are sent to the client as they become ready.

WebVTT subtitles¶

The “Teletext subtitles to WebVTT” setting (enabled by default, effective in the OTT modes) converts the DVB Teletext / DVB Subtitling subtitles of the input stream into WebVTT tracks: a subtitle track is added to the HLS master playlist and a text adaptation set to the DASH manifest. The presence of subtitles in the source is shown in the media information in the statistics window. Subtitles are archived to DVR in parallel with the media segments and are available during archive playback; they are not encrypted by DRM. The “Log subtitle messages” setting (advanced setting) is provided for diagnostics.

Adaptive bundles¶

An adaptive bundle combines several OTT streams of the same channel at different bitrates under a single HLS master playlist or DASH manifest — the player switches between the variants on its own according to the available bandwidth.

A bundle is created as a stream of type “Adaptive” (New stream, bundle editor — Adaptive bundle). The members are SPTS streams with an OTT mode enabled: OTT / HLS for adaptive HLS over MPEG-TS, OTT / LL-HLS / DASH for adaptive DASH and Low-Latency HLS. The bitrate may be set manually for each member; the value 0 means the measured bitrate is used.

The bundle master URLs are built according to the schemes /hls/adaptive/, /dash/adaptive/, /llhls/adaptive/ with the same authorization variants. Access granted to a client for an adaptive bundle automatically extends to every stream it contains.

Content protection (DRM)¶

OTT delivery of a stream can be encrypted. Encryption is performed once, at the moment a segment is produced: live delivery and the DVR archive receive the same encrypted data; the archive is stored on disk in encrypted form. The settings are collected in the “Content protection” section of the “OTT” tab; applying any of them restarts OTT delivery of the stream.

Modes (the “DRM” field, values as shown in the interface):

HLS AES-128: Full-segment encryption of the TS segments; decryption is performed by any standard HLS player. Requires “HLS service” = OTT / HLS.
CENC cenc (DASH), CENC cbcs (DASH): Per-frame encryption according to MPEG Common Encryption (ISO/IEC 23001-7) — the cenc scheme (AES-CTR) or cbcs (pattern AES-CBC, the Apple FairPlay ecosystem). They require the OTT / LL-HLS / DASH mode with TS chunk delivery disabled; delivery is over MPEG-DASH only.

Any protection mode requires the “HTTP service” to be off — progressive delivery bypasses encryption. An incompatible combination of settings is rejected by the server with a statement of the reason.

Keys and delivery:

“Content key (32 hex)” is the encryption key (for static AES-128 and for CENC). “Key ID (CENC KID)” is the CENC key identifier; when the field is empty the identifier is derived deterministically from the stream identifier.
“Key delivery” (AES-128, values as shown in the interface): Built-in (PSS serves the key) — the server itself serves the key over a session URL with the same authorization as the segments; External key server — the key tag in the playlist points to the “Key URI (EXT-X-KEY)” and built-in delivery is disabled. For CENC the server does not issue keys to players — key delivery is performed by the DRM infrastructure (license servers).
Key rotation (AES-128 only): “Key source” = Derived (rotating), “Rotation secret” (at least 16 characters) and “Key window (minutes)”. The key of each window is computed from the secret by a one-way function; the DVR archive plays back across any number of rotations — the window number is recovered from the recording time of the segment.

Warning

Changing the “key identity” of a stream — the content key, the secret or the rotation settings — renders a previously recorded encrypted archive unreadable; the web interface asks for confirmation of such changes. Keys are stored in the server configuration in clear text — restrict access to the configuration files and to the backups.

DVR: the stream archive¶

Recording is enabled on the “OTT” tab, the “DVR” section (visible in the OTT modes):

“DVR storage”: The storage the archive is written to (DVR storages). The value “None” means recording is disabled.
“Retention (hours)”: The archive depth of the stream, from 1 hour to 90 days. Older segments are removed by the regular cleanup.
“Protected floor (hours)”: The lower protection threshold: the cleanup never removes recordings younger than this value, even when disk space runs short.

Recording starts automatically as soon as the stream enters the running state. Detaching from the storage stops recording (the files remain on disk, archive playback ceases); when the storage is changed recording starts anew and the files are not migrated. Destructive changes are confirmed by the web interface with the “Confirm DVR changes” dialog.

DVR storages¶

Storages are configured on the “DVR storages” screen (DVR storages). For each of them the directory path (unchangeable after creation), the disk usage limit in percent and — in the advanced settings — the cleanup interval, the pressure grace and pressure cut, the emergency free space and the hysteresis are specified. One storage per disk is recommended: several storages on a shared disk compete for free space. Removing a storage from the configuration does not delete the files from disk.

Archive cleanup operates at several levels:

by depth — segments older than the “Retention (hours)” value of each stream;
by space — when the disk usage limit is exceeded persistently, the oldest segments are removed proportionally across all streams, but never those younger than the protected floor;
emergency — when free space becomes critically low, recording is stopped until free space is restored;
cleanup of orphaned files inside the archives of recorded streams is performed automatically; archive directories left behind by deleted streams are removed manually only — with the “Wipe orphaned archives” button on the “DVR monitor” screen (DVR monitor).

The state of the storages and of the recorded streams — fill level, archive size, write and read latencies, active cleanup tasks — is displayed on the same “DVR monitor” screen. The archive of an individual stream can be deleted irrevocably with the “Wipe DVR archive” button in the stream statistics window; recording continues meanwhile.

Archive playback (VOD)¶

The archive is played back through the same URLs as the live HLS / DASH broadcast — only the query parameters differ:

t=<time>: The start of the VOD window (Unix time, seconds). t=0 — from the beginning of the archive. The presence of the t parameter enables VOD mode.
d=<seconds>: The duration of the VOD window. Without the parameter (or with d=0) — up to the current moment. Effective only together with t.
epg=<time>: VOD by the programme guide: the server finds the EPG event active at the specified moment and takes its start and duration as the window boundaries. This requires the stream to be bound to an EPG source — the “EPG source” and “EPG channel” fields on the “Stream” tab (Stream modification, EIT generator); the t and d parameters are then ignored. For a programme catalogue it is enough for the interface to supply the event time — the exact boundaries are computed by the server.

Playback specifics:

The window boundaries are normalized: a request earlier than the start of the archive is pulled up to the first available segment; a window lying entirely outside the archive returns an empty but valid playlist.
The VOD HLS playlist is closed (carries the end-list indication); the DASH manifest is static. Recording gaps in DASH are represented as separate periods — players seek across the boundary without any special settings.
If a client reaches the right-hand boundary of the window, the missing segments are served from the live memory of the stream — without redirects or repeated authorization.
An open VOD session protects its window from the regular cleanup until the session is closed; the emergency cleanup and the protected floor take priority.
WebVTT subtitles are played back from the archive as well (WebVTT subtitles).
Adaptive bundles support the same VOD parameters. Only the variants with an attached DVR storage make it into the DASH manifest; the HLS master playlist includes every variant, but the variants without an archive respond to an archive request with an error and the player skips them.