SRT Stream Density and Transport for Broadcast Contribution

How it works

SRT fundamentals

SRT operates over UDP and implements selective retransmission (ARQ via NACK), adaptive jitter buffers, and packet re-ordering to recover lost packets while keeping end-to-end latency bounded. Unlike TCP, which guarantees delivery at the cost of unpredictable delay, SRT lets operators define a latency budget and maximizes recovery within that window. On well-configured links, this permits sub-second latencies even across lossy public Internet paths.

The protocol’s core design targets a specific trade-off: the retransmit window and jitter buffer determine how much time is available to request and receive replacement packets. A wider window improves recovery probability but increases glass-to-glass latency. A narrower window reduces latency but raises the risk of unrecovered frames reaching the decoder. This tunability is what makes SRT practical for live contribution, where latency requirements vary from tight multi-camera synchronization (100–200 ms) to more relaxed single-feed delivery (500–1,000 ms).

The SRT reference implementation is maintained on GitHub under the Haivision organization, with development coordinated through the SRT Alliance.

Encryption and session management

SRT supports AES payload encryption in 128-bit and 256-bit modes, providing end-to-end confidentiality for contribution feeds carrying premium sports, news, or rights-sensitive content. The encryption operates at the payload level, meaning the SRT control headers remain accessible for network-level diagnostics while the media content is protected.

Session establishment uses a handshake exchange that supports stream IDs and can avoid static open firewall ports by initiating connections outbound. This is valuable for contribution from remote venues with restrictive firewall policies or where NAT traversal is required.

Encryption and per-stream crypto processing add CPU load proportional to both stream count and per-stream bitrate. At low stream counts this overhead is negligible, but at aggregation-scale densities—hundreds or thousands of concurrent encrypted streams—the crypto workload becomes a dominant resource consumer unless offloaded to dedicated ASIC or FPGA hardware.

Reliability and timing controls

The key SRT parameters that operators tune per-link include:

• Retransmit window (ms): defines the time span during which lost packets can be re-requested.

• Maximum retransmit attempts: caps how many times a given packet is re-requested before being declared lost.

• Jitter buffer size (ms): absorbs network timing variations; larger buffers tolerate more jitter but add latency.

• Round-trip time (RTT) estimation: SRT continuously measures RTT and uses it to calibrate retransmit timing.

Practical deployments set these parameters based on measured link characteristics. A contribution path with 40 ms RTT and 0.5% packet loss requires a materially different configuration than a cellular bonded link with 120 ms RTT and 3% loss. The general principle holds: raising jitter buffer and retransmit windows improves delivery reliability under loss at the direct cost of increased latency.

Gateways, roles, and topologies

SRT supports three connection modes for establishing sessions:

• Caller/Listener: one side listens on a known address and port; the other initiates the connection. This is the most common mode for contribution into a fixed headend.

• Rendezvous: both sides initiate simultaneously, useful for symmetric NAT traversal where neither side can easily listen.

Common deployment topologies include:

• Point-to-point contribution: a single encoder at a camera site connects to a single receiver at the headend.

• Many-to-one aggregation: an SRT gateway aggregates dozens to hundreds of inbound streams from distributed venues or camera positions.

• Cloud ingress: SRT streams terminate at cloud instances for CDN handoff or platform delivery.

Aggregation nodes have the highest resource demands because they terminate many simultaneous SRT sessions, each requiring independent ARQ state, jitter buffering, and—when enabled—AES decryption. This is where stream density per node becomes a critical design and procurement metric.

Why it matters in broadcast

Predictable low latency over best-effort networks

SRT enables contribution workflows over commodity Internet and cellular links that previously required dedicated satellite transponders or MPLS circuits. For REMI (Remote Integration Model) and remote production, this means multi-camera feeds can traverse public networks while maintaining the sub-second latencies needed for production switching and talkback synchronization. The protocol’s ability to adapt to changing network conditions in real time makes it viable on paths where jitter and loss are variable and unpredictable.

Security and content protection

AES encryption and stream-level access controls protect contribution feeds end-to-end, addressing operator and rights-holder requirements for premium content. Unlike unencrypted RTP or MPEG-TS over UDP, SRT ensures that even if packets are intercepted on a public network path, the media payload remains confidential. This is a non-negotiable requirement for live sports, pay-per-view events, and news feeds with embargoed content.

Operational cost and flexibility

By enabling reliable transport over the public Internet, SRT reduces reliance on fixed leased circuits and satellite capacity for many contribution scenarios. This shifts procurement decisions: operators must now evaluate the trade-offs between cloud-elastic SRT gateways (pay-per-use, horizontally scalable) and high-density on-premises appliances (fixed cost, highest streams-per-watt for sustained workloads). The choice depends on whether the workflow is always-on or event-driven, and whether the aggregate stream count justifies dedicated hardware.

Technical specifications and trade-offs

When evaluating SRT transport infrastructure, several dimensions determine suitability for a given contribution architecture:

• Streams per node: the number of concurrent SRT connections a single gateway or appliance supports. This is the primary density metric.

• Aggregate encrypted throughput: total SRT payload throughput (measured in Gb/s) per chassis or instance, with encryption enabled.

• Latency budget: the configurable end-to-end latency target and its mapping to jitter buffer size and retransmit window. Typical production targets range from 100 ms to 1,000 ms.

• CPU vs. hardware offload: whether AES encryption/decryption, ARQ state management, and jitter buffering are performed in software on general-purpose CPUs or offloaded to dedicated ASIC/FPGA modules. This directly affects density and power efficiency.

• Watts per stream: power consumption per active stream at scale—a procurement metric that determines operational cost in 24/7 deployments.

• Interoperability: support for caller/listener/rendezvous modes, ST 2022-7 hitless switching, TS-over-UDP/RTP input/output, and orchestration APIs such as NMOS.

Comparison of representative alternatives

The following table compares representative deployment approaches across the dimensions most commonly specified in procurement. Values are indicative categories; actual figures depend on vendor, model, and configuration.

Approach	Typical deployment role	Streams per node	Aggregate throughput	Offload model	Notes
Hardware-accelerated appliance (high-density)	Core aggregation, 24/7 contribution	Hundreds to 1,500+ per chassis (2 RU)	Tens of Gb/s to 70+ Gb/s per chassis (2 RU)	ASIC/FPGA crypto and packet processing	Highest density, lowest watts per stream for always-on use
Software gateway (VM/container)	Elastic cloud ingest, pop-up events	Dozens to low hundreds per instance	Hundreds of Mb/s to a few Gb/s per instance	CPU (x86/ARM); DPDK optional	Scales horizontally; cost shifts to vCPU and network egress
Cloud managed transport (PaaS)	Region-to-region transport, CDN ingress	Per-flow limits; many flows via many instances	Per-flow (e.g., 400 Mb/s to 2.5 Gb/s), aggregated by region	Provider hardware + software stack	Elastic, integrates with cloud services; suited for variable or short-lived peaks
Alternate protocols (RIST / Zixi / proprietary)	Latency-sensitive enterprise links, redundancy	Varies; RIST comparable to SRT for simple use cases	Varies by product	Mix of software and hardware	Choice often driven by ecosystem, SLA needs, and features such as bonding or FEC strategies

Trade-off summary:

• Choose software or cloud gateways when elasticity, pay-as-you-go pricing, and multi-region integration are priorities.

• Choose hardware-accelerated appliances when sustained high stream density, low watts-per-stream, and deterministic performance under load are required.

• For mixed requirements, hybrid architectures combine on-premises aggregation with cloud-based egress or overflow capacity.

Related approaches and standards

RIST (Reliable Internet Stream Transport) is an open-specification alternative to SRT that emphasizes multi-vendor interoperability through defined profiles (Simple, Main, Advanced). RIST uses similar ARQ-based recovery and is often compared to SRT for enterprise WAN links and scenarios where TLS-based authentication is preferred. The RIST specification is maintained by the Video Services Forum.

RTP/RTCP and MPEG-TS over UDP remain widely deployed legacy transports. They are used where network conditions are controlled—such as over MPLS or private WAN—and where minimal protocol overhead is required. These transports lack built-in encryption and reliability mechanisms, making them unsuitable for contribution over unmanaged networks without additional protection layers.

ST 2022-7 and ST 2110 are professional media-over-IP standards. ST 2022-7 provides hitless switching between redundant RTP streams for network-level resilience. ST 2110 defines uncompressed IP media transport for facility-grade infrastructure. SRT is frequently used at contribution edges to bridge non-guaranteed public networks into ST 2110 production environments or aggregated headends.

FEC strategies vs. ARQ: Forward Error Correction adds redundant data to the stream so receivers can reconstruct lost packets without retransmission. FEC reduces retransmit dependency and can lower latency on lossy links, at the cost of increased bandwidth consumption. Many production deployments combine FEC with SRT’s ARQ logic to balance latency and recovery probability, particularly on high-loss cellular or satellite-IP paths.

How Appear addresses this

Appear’s X Platform family (X5, X10, X20) provides hardware-accelerated SRT processing inside a high-density media processing chassis for contribution, remote production, interfacility connectivity, and SRT gateway use cases. Module-level IP gateway cards (such as the IPx100 and IPx110) provide dual 10G/1G interfaces, transport stream processing, AES crypto, and accelerated SRT transport.

Appear publishes per-chassis SRT capacity figures on its product pages; the X20 product page documents capacity of up to 72 Gb/s of SRT traffic and high concurrent connection counts in a 2 RU form factor. These figures reflect offloading encryption and packet processing to dedicated hardware, delivering higher density and lower power consumption per stream compared with software-only approaches. For exact, current per-model specifications—including supported SRT modes, module options, and verified platform integrations—consult the Appear product pages directly.

FAQ

What latency can SRT achieve for live contribution?
Sub-second latencies are achievable on well-provisioned links. Practical production targets are commonly 100–500 ms, depending on round-trip time, jitter buffer settings, and retransmit policy.

Does SRT provide encryption?
Yes. SRT supports AES payload encryption in 128-bit and 256-bit modes for end-to-end confidentiality. Enabling encryption increases CPU or hardware crypto load proportionally to stream count and bitrate.

How does SRT handle packet loss?
SRT uses selective retransmit (ARQ) with configurable retransmit windows and jitter buffering to recover lost packets. The mechanism trades latency against the probability of successful recovery—wider windows recover more packets but add delay.

When should I use hardware-accelerated SRT versus software gateways?
Use hardware acceleration where sustained high stream counts, high aggregate encrypted throughput, or low watts-per-stream are required for always-on operation. Use software gateways for elastic, short-term, or cloud-native ingestion where horizontal scaling and pay-per-use economics are preferred.

Can SRT traverse NAT and firewalls?
Yes. SRT’s caller/listener and rendezvous modes facilitate NAT traversal. However, firewall and NAT rules must still be validated for the chosen mode, particularly in enterprise or venue environments with restrictive policies.

How does SRT compare to RIST?
Both provide reliability and low latency over IP using ARQ-based recovery. RIST emphasizes an open specification with defined profiles and multi-vendor interoperability; SRT is an open-source protocol with a large ecosystem and popular reference implementations. The choice depends on vendor support and workflow requirements.

Is SRT suitable for multi-camera REMI production?
Yes. SRT is widely used for remote production workflows. Latency profiles and per-stream reliability must be tuned for each camera feed, and aggregation points must be sized for the total number of camera feeds and return channels.

What metrics should procurement request in an RFP for SRT gateways?
Request streams per RU, maximum aggregate encrypted throughput (Gb/s), supported AES modes, supported SRT connection modes (caller/listener/rendezvous), latency and jitter buffer configuration ranges (ms), watts per stream, redundancy options (including ST 2022-7 support), and management API support (e.g., NMOS).

Can SRT be used for ingest to public platforms such as YouTube?
Yes. Some hardware and software encoders and gateways are verified by platforms for SRT ingest. Verify the target platform’s SRT requirements, recommended bitrates, and any specific handshake or stream ID conventions before deployment.

Should I pair FEC with SRT?
Pairing FEC with SRT can reduce retransmit dependency and improve performance on very lossy links by allowing the receiver to reconstruct some lost packets without waiting for retransmission. The optimal mix depends on available bandwidth overhead and latency targets.

How do I estimate CPU needs for a software SRT gateway?
Estimate based on concurrent encrypted stream count, per-stream bitrate, aggregate packet rate (packets per second), and whether DPDK or other accelerated network libraries are used. Vendors typically provide reference stream counts per CPU core or per instance type for their software implementations.

Are there open-source SRT implementations?
Yes. The SRT protocol and reference library are available on GitHub under the Haivision organization. The SRT Alliance coordinates ongoing development and ecosystem growth across encoder, decoder, and gateway vendors.