Planning and data transmission protocols¶
The core of Perfect Streamer is the 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: choose a protocol and calculate bandwidth, latency and ports. Detailed settings of individual fields are covered in the context description of the web interface (Web interface), and stream processing on a node 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 pair is called 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, NAT on the receiver’s side is no obstacle: the receiver connects to the transmitter itself, and no incoming ports need to be forwarded on the receiver.
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 way they compensate for losses:
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 COP3/RTP+FEC (SMPTE 2022-1/2) belongs to this class.
PS1 (Perfect Stream)¶
A proprietary protocol based on UDP. It works on the ARQ principle with selective retransmission. It needs few resources and carries high-bitrate streams, including a 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 authorised 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 changes, the receivers do not reconnect: the interruption is recovered by ordinary retransmission.
PS1 is a proprietary protocol and works only between Perfect Streamer nodes. It is best suited to 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 authorisation, receivers are registered as a Peer, and authorisation 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: synchronisation is then handled by the node’s jitter buffer (Synchronisation), which noticeably reduces CPU load.
RIST¶
An open protocol based on RTP/RTCP. It works on the ARQ principle without ACK, using only NACK. 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 authorisation by IP.
Pro-MPEG FEC¶
Delivery of MPEG-TS over RTP with forward error correction (FEC), without a return channel. 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 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, a retransmission margin set as a percentage above the bitrate — 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 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). 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, so this transport suits 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, the shared catalogue of occupied addresses and ports helps avoid collisions (see Meshwork).
Stream encryption¶
AES encryption is enabled by a shared passphrase that is set on both sides of the connection; the phrases must match. An empty phrase means operation without encryption. Encryption does not change the stream bitrate.
Support and the permitted phrase length differ by protocol:
Protocol |
Passphrase length |
Notes |
|---|---|---|
PS1 |
10–64 bytes |
— |
SRT |
10–79 bytes |
The key length is also selected: 128, 192 or 256 bits. A phrase outside the permitted length stops the input or output with an explicit error message. |
RIST |
not checked; the first 127 bytes are used |
Only in the Main profile. In the Simple profile the passphrase has no effect. |
Pro-MPEG |
10–64 bytes |
A non-standard extension: when it is enabled, compatibility with third-party software and equipment is not guaranteed. |
The phrase length is counted in bytes, not in characters: a Cyrillic letter takes two bytes.
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 variant of the adaptive playlist is selected by a configurable index (the first one by default); the input is for 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 MPEG-TS output to a device (for example, ASI); 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 distribute one channel to many recipients 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 synchronisation, the stream must contain valid PCR stamps.
Filtering, modification and bitrate modes of the input stream are described in SPTS streams, and the specifics of the multiplex in MPTS streams.
