Planning and data transmission protocols¶

The core of Perfect Streamer is reliable delivery of MPEG-TS streams between nodes across a public network with packet loss and delays. This section describes the transmission model, the transport protocols and how to plan a channel: choosing a protocol and calculating bandwidth, latency and ports. Detailed settings for individual fields are covered in the context description of the web interface (Web interface), and stream processing on a node is covered in the Streamer: implementation details section.

Transmission model: Stream, Sender, Receiver, Peer¶

The unit of work is a stream (Stream), a single MPEG-TS channel. For each stream, a transmitter server (Sender) and one or more receivers (Receiver) are configured; a transmitter–receiver pairing is referred to as a Peer.

Configuration comes down to lists of inputs (input) and outputs (output) for each stream:

on the transmitter, input is the MPEG-TS sources, output is transmission to the receivers;
on the receiver, input is receiving the stream from the transmitter.

Multiple inputs in the list provide source redundancy, multiple outputs provide simultaneous distribution of a single channel to many recipients and over different protocols.

For protocols where the receiver initiates the connection, a receiver behind NAT connects to the transmitter itself — no forwarding of incoming ports on its side is required.

Peer protocols for reliable transmission¶

Four Peer protocols are available for transmission between the transmitter and the receiver. They fall into two classes by the principle of loss compensation:

ARQ (Automatic Repeat reQuest) — lost packets are retransmitted at the receiver’s request. Requires a return channel and a buffer on the receiver; the recovery depth is configurable. PS1, SRT and RIST belong to this class.
FEC (Forward Error Correction) — redundant data is continuously added to the stream, allowing losses to be recovered without a return channel. Pro-MPEG / RTP+FEC belongs to this class.

PS1 (Perfect Stream)¶

A proprietary protocol based on UDP. It works on the ARQ principle with selective retransmission. It is distinguished by low resource consumption and carries high-bitrate streams, including full-size MPTS.

The receiver initiates the connection, so the transmitter requires authentication: receivers are registered as a Peer with a login and password or are authorized by IP. Latency is determined by the receiver’s buffer (the jitter-removal and retransmission window); the transmitter’s buffer must be larger than the receivers’ buffers. When the active source on the transmitter is changed, the receivers do not reconnect — the interruption is recovered by ordinary retransmission without a visible reconnection.

PS1 is a proprietary protocol and works only between Perfect Streamer nodes. It is especially efficient in a point-to-multipoint configuration: one transmitter and many receivers.

SRT¶

An open protocol based on UDP (UDT). It is widely used and compensates well for packet loss. It supports listener and caller modes, which provides compatibility with third-party SRT equipment and cloud services.

In listener mode on the transmitter, several receivers connect to a single stream; for authorization, receivers are registered as a Peer, and authorization by IP is available. The initiating party (caller) can be either on the receiver or on the transmitter. The bandwidth margin for retransmission is set as a percentage above the stream bitrate.

On dense receiving nodes with a large number of SRT inputs in caller mode, the built-in SRT receiver buffering (TSBPD) can be disabled: synchronization is then handled by the node jitter buffer (Synchronization), which appreciably reduces CPU load.

RIST¶

An open protocol based on RTP/RTCP. It works on the ARQ principle without ACK, using only NACK, which ensures high efficiency. It uses unicast and multicast.

The Simple and Main profiles are implemented: Simple occupies two consecutive UDP ports (the base port must be even), Main multiplexes the data into a single port. Multiple paths (peers) with weighted balancing are supported — for redundancy and aggregation. With multicast there can be many receivers, with authorization by IP.

Pro-MPEG / RTP+FEC (SMPTE 2022-1/2)¶

Delivery of MPEG-TS over RTP with forward error correction (FEC), without a return channel. The protocol is also known as Pro-MPEG COP3. PSS implements a two-dimensional FEC matrix (rows and columns, SMPTE 2022-2).

The stream of RTP packets is grouped into a matrix of a given size, and FEC packets are formed along its rows and columns. The smaller the matrix, the better the recovery, but the higher the constant overhead. FEC channels occupy two additional ports (port+2 and port+4), which must be taken into account when placing several streams on one host or in one multicast group.

The advantages are low fixed latency and compatibility with professional broadcast equipment. The disadvantages are constant additional traffic and weak recovery at high losses (above ~0.2%), so the protocol is intended for managed channels with low losses rather than the “heavy” public internet.

Choosing a transmission protocol¶

Protocol	Principle	Return channel	Latency	Compatibility
PS1	ARQ over UDP	required	configurable	only between Perfect Streamer nodes
SRT	ARQ over UDP (UDT)	required	configurable	open; third-party SRT equipment and cloud
RIST	ARQ (NACK) over RTP/RTCP	required	configurable	open; third-party RIST equipment; unicast and multicast
Pro-MPEG / RTP+FEC	FEC over RTP	not required	low, fixed	open (SMPTE 2022-1/2); professional broadcast equipment

Selection guidelines:

a channel between Perfect Streamer nodes, high bitrate or full-size MPTS, point-to-multipoint distribution — PS1;
compatibility with third-party equipment or cloud, flexible configuration of the retransmission margin — SRT;
an open RTP-based transport, multicast, balancing across multiple paths — RIST;
a managed channel with low losses, minimal latency without a return channel, professional broadcast equipment — Pro-MPEG / RTP+FEC.

Planning bandwidth, latency and ports¶

ARQ protocols (PS1, SRT, RIST). Losses are compensated by retransmission, so you need to provide for:

a return channel from the receiver to the transmitter;
a bandwidth margin above the nominal bitrate — bursts of loss cause bursts of retransmission traffic;
a buffer on the receiver for the channel latency. The larger the buffer, the deeper the loss recovery, but the higher the end-to-end latency; a guideline is several RTT values. Low-bitrate streams require a larger buffer in terms of time, so that enough packets fit within the recovery window.

FEC protocol (Pro-MPEG / RTP+FEC). Redundant packets are transmitted continuously, regardless of actual losses, so the overhead is fixed and depends on the size of the FEC matrix. No return channel is needed, latency is low and fixed, but recovery is limited — this transport is for channels with low losses.

Ports. Each listening point needs a unique UDP port within the host or group. Additionally, keep in mind that the RIST Simple profile occupies two consecutive ports (the even base port and the next one), and Pro-MPEG occupies the base port plus two FEC ports (port+2 and port+4). In a Meshwork network, a shared catalog of occupied addresses and ports helps avoid collisions (see Meshwork).

Stream encryption¶

All Peer protocols support AES encryption using a shared passphrase entered on both sides. For SRT, the key length is additionally selected (128, 192 or 256 bits). Encryption does not change the stream bitrate.

For Pro-MPEG, encryption is a non-standard extension, so when it is enabled, compatibility with third-party software and equipment is not guaranteed.

Other inputs and outputs¶

In addition to the Peer protocols, standard transports for receiving and transmitting are available:

Protocol	Input	Output	Note
UDP	yes	yes	unicast/multicast, SSM, interface selection; up to 7 TS packets per datagram
RTP	yes	yes	reordering of out-of-order packets
TCP	yes	—	client mode; reception where UDP is blocked
HLS / HTTP	yes	yes	on input, the rendition of the adaptive playlist is selected by a configurable index (the first one by default); input is SPTS only
RTSP	yes	—	IP cameras and RTSP servers; auto-remux to MPEG-TS; SPTS only
RTMP / RTMPS	yes	yes	publishing to third-party RTMP receivers; H.264 and HEVC; SPTS only
file / device	yes	yes	recording to a TS file and output to a device (including SDI); loop playback from a file
pipe (FIFO)	yes	yes	bridge to an external process via a named pipe
std (external application)	yes	yes	bridge to non-standard protocols via a console application

RTMP publishing and reception are described in RTMP publishing and reception; RTSP, HLS/HTTP input, files and devices, named pipes and external applications are described in Other inputs and outputs. Detailed settings for each transport are given in Web interface. OTT delivery (HLS, LL-HLS, DASH) is described separately in OTT and DVR.

Source redundancy and distribution¶

Redundancy. Several inputs can be specified for a stream; only one is ever active. When the active input fails, the stream automatically switches to the next one in the list, and upon recovery it can return to the priority source. This allows you to plan the primary and backup sources of a channel in advance; detailed settings for input switching are described in SPTS streams.

Distribution. Several outputs on a single stream allow a single channel to be distributed to many recipients at once and over different protocols simultaneously.

Input stream requirements¶

Compliance with ISO/IEC 13818-1, Single Program (SPTS) or Multi Program Transport Stream (MPTS).
The set of tracks is defined by the selected content type of the SPTS stream, see SPTS streams.
Scrambled (encrypted) streams are supported, see SPTS streams.
For synchronization, the stream must contain valid PCR marks.

Filtering, modification and bitrate modes of the input stream are described in SPTS streams, and the specifics of multiplexing in MPTS streams.