SRT Density

How It Works

SRT density is not a single specification but an emergent property of several interacting subsystems. The sections below break down each resource dimension that contributes to — or constrains — the number of concurrent SRT sessions an endpoint can sustain.

Session and Connection Modes

SRT defines three connection modes: caller (active open), listener (passive/server), and rendezvous (mutual connect). Each mode imposes different requirements on NAT traversal behaviour and session state management at the endpoint. A listener endpoint, for example, must maintain open sockets and accept inbound connections, which means it carries per-session state for every connected caller. Rendezvous mode requires both sides to initiate simultaneously, which simplifies NAT traversal but doubles the handshake state during connection setup. As documented in the SRT protocol specification, these topological choices influence the number of concurrent sessions an endpoint can manage, particularly in environments with constrained NAT table sizes or firewall session limits.

Protocol Processing and Per-Stream CPU Cost

Every SRT stream runs over UDP, requiring dedicated socket handling, packet parsing, and timestamp/sequence management for each connection. Three CPU-intensive operations dominate per-stream cost:

• Packetisation and UDP I/O. Each stream requires its own UDP socket (or a share of a multiplexed socket), with per-packet header processing and scheduling.
• ARQ / selective retransmit. SRT uses automatic repeat request within a configurable latency window to recover lost packets. ARQ is inherently stateful: the sender must buffer transmitted packets for potential retransmission, and the receiver must track gaps and issue NAK requests. CPU and memory consumption scale with round-trip time and the number of outstanding packets. As explained in vendor overviews, this selective retransmit mechanism is central to SRT’s reliability over lossy networks.
• Forward error correction (FEC) and multiplexing. When optional FEC is enabled, additional parity packets are generated and transmitted, increasing both bandwidth headroom and buffer requirements. Stream multiplexing — carrying multiple logical streams over a single UDP flow — can reduce socket-count overhead but shifts cost to the multiplexing/demultiplexing logic.

Encryption and Security Overhead

SRT supports built-in AES encryption in 128-bit and 256-bit key lengths. Per-stream encryption adds measurable CPU cost: each packet must be encrypted on the sender side and decrypted on the receiver side. On general-purpose CPUs without hardware acceleration, AES processing can become the primary bottleneck limiting density. Platforms that incorporate dedicated crypto offload engines or leverage CPU instruction-set extensions (such as AES-NI) can sustain multi-gigabit encrypted SRT throughput without linear CPU scaling. For high-density deployments, the presence or absence of hardware crypto acceleration is often the single largest determinant of achievable stream count.

Jitter Buffers, Latency Settings, and Memory

SRT’s latency window setting controls the playout buffer — the duration for which the receiver retains packets to allow ARQ recovery and reordering before declaring them lost. Larger windows provide more aggressive packet recovery at the expense of higher glass-to-glass delay and increased memory consumption per stream. Practical designs typically set latency windows ranging from a few tens of milliseconds on well-provisioned private links to several hundred milliseconds on congested public internet paths.

From a density perspective, memory allocation per stream scales directly with the latency window multiplied by the stream bitrate. A 200 ms buffer on a 20 Mb/s stream requires roughly 500 KB of buffer memory; across hundreds of streams, this becomes a material system resource.

Network I/O, Switch Capacity, and Bonding

Aggregate SRT traffic is ultimately constrained by the raw throughput of network interfaces and internal switching fabrics. High-density gateways group many stream endpoints onto 10G, 25G, or 100G links and use internal switch modules to route flows between processing cards. Density planning must account for:

• Maximum simultaneous throughput in Gb/s
• Packet rate capacity in packets per second (pps), which is particularly relevant for high-frame-rate or many-small-packet workloads
• Headroom for FEC packets and ARQ retransmits, which can add 5–30% overhead depending on link conditions

Some platforms support multi-link bonding or link replication to increase both resilience and aggregate throughput, effectively raising the density ceiling for a single logical endpoint.

Why It Matters in Broadcast

SRT density directly affects the economics, reliability, and scalability of live broadcast infrastructure.

Consolidation and rack-space economy. Higher SRT density reduces the number of chassis or rack units needed at network operations centres and ingest sites. Fewer boxes mean lower power consumption, reduced cooling requirements, and simpler cabling — all of which translate to measurable operational savings.

Scale for REMI and multi-camera contribution. Modern remote-production workflows frequently require tens to hundreds of concurrent camera feeds from venues, satellite downlinks, and remote reporters. Density determines whether a single gateway can host an entire event’s contribution traffic or whether multiple gateways — with the associated management overhead — are needed.

Predictable operational limits. Knowing the density ceiling of a platform lets engineering teams size 1+1 redundancy correctly, provision for peak events, and identify the threshold at which additional chassis, crypto offload modules, or higher-speed network interfaces become necessary.

Cost of transport. Gateways that efficiently compress, accelerate, and aggregate SRT streams can materially reduce bandwidth and cloud egress costs compared to one-stream-per-host software approaches, where each instance carries its own overhead.

Technical Specifications and Trade-offs

Key Dimensions That Determine SRT Density

Dimension	Description
Streams per CPU core	Varies by codec passthrough vs. transcode, crypto use, and ARQ/FEC load; lightweight MPEG-TS de/packetisation is far cheaper than full decode/encode
Encryption throughput	AES offload enables multi-gigabit per-module performance without linear CPU scaling
Max aggregate SRT throughput	Chassis-level specification, e.g., total Gb/s of SRT traffic across all modules
Packet rate (pps) capacity	Critical for high-frame-rate or many-small-packet stream profiles
Buffer / latency budget	Trade-off between recovery capability and end-to-end delay; larger buffers consume more memory per stream
NAT traversal and concurrent sessions	Listener vs. caller mode affects NAT table and time-wait resource consumption

Comparison of Broadcast Transport Alternatives

The table below summarises architectural trade-offs among the three most common reliable transport protocols used in broadcast contribution. Numbers are representative ranges; final sizing requires vendor-specific benchmarks.

Dimension	SRT (SRT Alliance, open-source)	Zixi (proprietary)	RIST (open standard)
Error recovery	ARQ + optional FEC; latency-window-based selective retransmit	Proprietary ARQ + adaptive FEC; commercial congestion control	ARQ with profiles and optional FEC; multi-vendor interoperability focus
Encryption	AES-128/256 built-in; CPU or hardware offload required at scale	AES/DTLS options; integrated into commercial appliance stacks	Implementation-dependent; interoperability emphasised
Typical latency	Tens to low hundreds of ms (configurable by ARQ window and RTT)	Similar ranges; commercial tuning can reduce perceived jitter	Designed for low-latency recovery; similar operational ranges
Vendor ecosystem	Broad open-source tools and SRT Alliance adoption	Large commercial ecosystem and managed service integration	Growing open-spec ecosystem with SMPTE/RIST Forum activity
Density considerations	Scales well with hardware crypto and NIC offload; software-only endpoints have lower per-host densities	High-density commercial appliances available; licensing may influence cost model	Multi-vendor interoperability allows packing into heterogeneous estates; density depends on implementation

Related Approaches and Standards

SMPTE ST 2022-7 provides hitless protection through seamless packet replication across diverse network links. It is frequently used alongside ARQ/FEC schemes like SRT to increase availability for critical contribution paths.

SMPTE ST 2110 defines uncompressed IP media transport within private, low-jitter LANs — a fundamentally different design point from SRT’s focus on reliable delivery over lossy public networks.

WHIP / WebRTC and QUIC enable low-latency browser-based ingest and contribution. They serve direct-to-web and ultra-low-latency use cases but offer a different set of transport guarantees than SRT.

RTMP / RTMPS remains in use for some content delivery endpoints despite higher latency and less robust packet-loss recovery compared to modern ARQ-based protocols.

How Appear Addresses This

Appear’s X Platform is a modular product family spanning the X5, X10, and X20 chassis, designed for high-density media processing and transport. The X20, a 2RU chassis intended for large-scale deployments, supports aggregate capacity up to 72 Gb/s of SRT traffic in certain configurations, with module-based scaling to increase concurrent connection counts per chassis.

At the module level, the IPx100/IPx110 IP gateway module provides hardware-accelerated SRT processing, media firewalling, and interface options including dual 10G/1G IP with support for SRT, ST 2022-7, and FEC. Hardware crypto offload on these modules enables higher stream counts without the CPU scaling penalties of software-only AES.

Appear has published SRT milestone documentation describing hardware-accelerated SRT deployments for contribution and REMI workflows, along with third-party verification for SRT delivery to major platforms.

FAQ

What does “SRT density” measure?
The number of concurrent SRT sessions or the aggregate SRT throughput a platform can sustain, expressed as streams per card, streams per chassis, or Gb/s of SRT traffic.

Which factors most strongly limit SRT density?
CPU capacity for ARQ and packet handling, crypto processing for AES, memory for jitter buffers, packet-rate capacity of the NIC and switch fabric, and chassis slot or I/O aggregation limits.

How does AES encryption affect density?
Encryption increases per-packet CPU load. Hardware crypto offload or dedicated crypto engines allow substantially higher density than software-only AES on general-purpose CPUs.

Does SRT add bandwidth overhead?
Yes. ARQ retransmits and optional FEC packets increase bandwidth use beyond the nominal stream bitrate and must be accounted for in aggregate throughput planning, as noted in vendor and community protocol overviews.

Is stream multiplexing useful for density?
Multiplexing multiple logical streams over a single UDP flow reduces socket and port state overhead but increases multiplexing/demultiplexing CPU work. It is most useful where many low-bitrate streams share the same network path.

How should I size a gateway for a large sporting event with many cameras?
Size by peak concurrent streams, peak aggregate bitrate including FEC and retransmit headroom, and the desired latency window. Include 1+1 redundancy and plan for worst-case packet loss scenarios that increase retransmit rates.

How does SRT compare to RIST and Zixi for density?
Architecturally the three protocols are similar in recovery and latency characteristics. Practical density differences depend on vendor implementations, hardware offload capabilities, and licensing models. SRT benefits from broad open-source tooling and SRT Alliance adoption.

Can cloud instances host high-density SRT endpoints?
Yes, with appropriate instance sizes, NIC capacity, and — if required — hardware crypto or virtualised acceleration. Cloud egress cost and packet rate limits should be considered in sizing.

Does a larger jitter buffer always improve stream quality?
Larger buffers increase recovery capability but add end-to-end delay. The best practice is to choose the minimum buffer that achieves acceptable packet recovery for the expected network conditions.

How do network RTT and latency settings interact with density?
Higher RTTs increase the number of outstanding packets and the memory/state required for ARQ, raising per-stream resource consumption and effectively lowering per-host stream density.

Should I prefer a single large chassis or many small boxes for density?
Single large chassis often yield better rack-space, power, and management efficiency for very high densities. Many smaller boxes provide geographical distribution and failure-domain separation. The right choice depends on operational constraints and resilience requirements.

What monitoring metrics are essential for managing SRT density?
Concurrent sessions, aggregate bitrate, packet loss rate, retransmit rate, jitter-buffer occupancy, CPU utilisation, crypto engine load, and NIC packet rate (pps).