SRT, Zixi, and the Evolution of Reliable IP Video Transport

The story of reliable IP video transport is really a story about one problem: UDP is fast but lossy, and video is unforgiving of loss. The broadcast industry spent the better part of two decades building proprietary solutions before converging — at least partially — on open standards. Understanding the lineage from early ARQ systems through Zixi and SRT explains why the landscape looks the way it does today, and which protocol belongs on which link.

The Problem: Why Standard UDP Isn’t Enough

IP video transport has always faced a fundamental conflict. TCP is reliable (it retransmits lost packets) but adds latency through head-of-line blocking and slow-start that makes it unsuitable for live video at low latency. Raw UDP is fast and low-latency but provides no recovery mechanism — a single lost packet in an MPEG-2 TS or compressed bitstream can cascade into minutes of visible artifacts or total loss of sync.

The broadcast industry needed something between these extremes: low-latency, reliable delivery over unreliable IP paths. The core technique that emerged was ARQ — Automatic Repeat reQuest — where the receiver detects missing packets and asks the sender to retransmit them, with enough buffering to hide the round-trip delay.

Fujitsu ARQ: The Proprietary Precursor

Long before SRT or Zixi, Fujitsu implemented a proprietary ARQ mechanism inside their broadcast encoder and decoder product lines (including systems like the IP-9500 series and related broadcast video over IP equipment). This gave facilities an early path to contribution-grade reliability over managed IP networks.

How it worked:

Fujitsu’s ARQ used a selective-repeat approach — the receiver tracked received packet sequence numbers, identified gaps, and sent negative acknowledgements (NACKs) back to the transmitter, which then retransmitted only the missing packets. The retransmitted packets arrived within the playout buffer window, and the receiver reconstructed the stream invisibly.

Strengths:

Genuine reliability on real IP paths with moderate packet loss
Integrated directly into the encoder/decoder, no third-party software required
Worked within managed, private WAN environments where RTT was predictable

Weaknesses:

Closed ecosystem — both ends required Fujitsu hardware. No interoperability with other vendors.
Fixed buffer and latency parameters, limited tuning
No encryption beyond whatever the network provided
No support for public internet or high-jitter paths
As Fujitsu exited or reduced its broadcast division presence, equipment became difficult to source and support

The Fujitsu approach illustrated both the promise and the limitation of proprietary ARQ: excellent when you own both endpoints, entirely useless the moment you need to interconnect with a different vendor. The industry needed something vendor-neutral.

Zixi: Professional Broadcast Protocol from the Ground Up

Zixi® is a registered trademark of Zixi LLC. Badge used for editorial identification only.

Origins

Zixi was founded circa 2009–2010, based initially in the northeastern United States. The company set out to build a professional-grade, software-defined video transport protocol specifically for broadcast contribution and distribution over the public internet — not managed WAN, not dark fiber, not satellite, but the actual open internet with all its unpredictability.

The timing was important. By 2009, HD contribution over IP was increasingly economically attractive, but the public internet was notoriously unreliable for broadcast use. Zixi’s founders came from the broadcast and networking worlds and understood that a purpose-built protocol, not a generic data transport, was needed.

Protocol architecture

Zixi operates over UDP with a custom reliability layer. Unlike pure ARQ-only approaches, Zixi combines:

ARQ (Automatic Repeat reQuest): Receiver sends retransmit requests for detected packet gaps. Retransmits are prioritized based on remaining time in the playout buffer.
FEC (Forward Error Correction): Proactive redundancy — additional repair packets sent alongside the primary stream. FEC recovers losses without requiring a round trip, which is critical when RTT is high.
Adaptive bitrate selection: Zixi Broadcaster can monitor network conditions and trigger encoder bitrate adjustments or MODCOD-like step-downs.

The Zixi ecosystem

Zixi’s model was never just a protocol — it was a platform:

Zixi Feeder (encoder/originator side): Lightweight software installed on an encoder, transcoder, or playout server. Packages the transport stream or contribution signal and sends it via the Zixi protocol.

Zixi Broadcaster: The routing and processing hub. Receives Zixi feeds, can transcode, re-multiplex, add/remove services, and rebroadcast to multiple destinations. This is the core of any Zixi deployment.

Zixi Receiver: Decoder/player side. Reconstructs the stream from received Zixi packets, handles ARQ and FEC recovery, and delivers a clean transport stream or decoded signal to downstream systems.

ZEN Master: Zixi’s multi-cloud management platform, launched to provide a unified control plane for routing, monitoring, and managing Zixi streams across on-premises, cloud, and CDN delivery paths.

Zixi’s licensing model

Zixi typically operates on a per-device or per-stream license basis. The exact terms vary by vendor partnership — some equipment manufacturers (IRDs, encoders) bundle Zixi licenses; others require separate purchase. Cloud and software deployments are usually metered by concurrent streams or throughput.

This licensing model has real-world implications:

For large-scale distribution with many concurrent streams, licensing costs can become significant
Some vendors have built Zixi support into their hardware as a standard feature; others charge for it as an option
The professional-grade support and SLA that come with licensed Zixi is often worth the cost for mission-critical contribution

Strengths

Mature, proven platform with years of large-scale broadcast deployments
Combines ARQ and FEC for best-of-both recovery
ZEN Master gives operational visibility across complex multi-site networks
Strong vendor ecosystem: widely supported in professional encoders, IRDs, and transcoders
Dedicated support with SLAs — important for live sports and news
Handles high-jitter, high-loss paths better than ARQ-only approaches

Weaknesses

Proprietary and licensed — both endpoints must run Zixi software or hardware
Licensing costs add up, especially for many concurrent streams
Not interoperable with SRT or other open protocols without a transcoding/gateway step
Vendor lock-in: migrating away from Zixi requires replacing endpoints

SRT: The Open-Source Revolution

SRT® is an open-source protocol developed by Haivision. Haivision® and the SRT Alliance® are registered trademarks. Badges used for editorial identification only.

Origins at Haivision

SRT (Secure Reliable Transport) was developed internally at Haivision — a professional broadcast equipment manufacturer based in Montreal — beginning around 2012–2013. Haivision built it as the transport layer for their encoder and decoder products, primarily to solve the same contribution-over-internet problem that Zixi had addressed: how to get broadcast-quality video reliably across the public internet at low latency.

SRT is built on UDT (UDP-based Data Transfer Protocol), an open-source protocol originally developed for high-speed data transfer across wide-area networks. Haivision modified and extended UDT with broadcast-specific features: live video semantics, encryption, and NAT traversal.

Open-sourcing: April 2017

The defining moment for SRT was April 2017 when Haivision announced it was open-sourcing the protocol at NAB Show (National Association of Broadcasters convention, Las Vegas). The code was released under the LGPL v2.1 license, meaning any vendor could implement it freely in both open-source and commercial products.

Simultaneously, Haivision launched the SRT Alliance with Wowza Media Systems as a founding member. The Alliance’s mission was to promote adoption and ensure interoperability across implementations. By 2020, the SRT Alliance had grown to over 500 member companies.

In 2020, the SRT specification was submitted to IETF for standardization, further cementing its open nature.

How SRT works

SRT’s reliability mechanism is selective-repeat ARQ:

The sender transmits packets over UDP with sequence numbers
The receiver tracks which packets arrived and sends periodic acknowledgements (ACKs) and negative acknowledgements (NAKs) for gaps
The sender retransmits NAK’d packets from a buffer
The receiver holds a playout buffer large enough to absorb the retransmit round trip

Configurable latency is the key tuning parameter. SRT latency (the SRTO_RCVLATENCY / SRTO_LATENCY socket option) sets the depth of the receiver playout buffer in milliseconds. A rule of thumb is:

SRT Latency ≥ 3 × round-trip time (RTT)

For a cross-continental link with 80ms RTT, you’d typically set latency to 250–500ms. For intra-city links (8ms RTT), latency can be as low as 40–80ms. This is far lower than the TCP delay for equivalent reliability.

Security is a first-class feature. SRT uses AES-128 or AES-256 for payload encryption with DTLS-based key exchange. Every SRT stream can be encrypted independently.

Connection modes:

Caller/Listener: One end initiates (Caller), the other waits (Listener). Most common for contribution.
Rendezvous: Both ends initiate simultaneously — useful for NAT traversal when neither side has a public IP.

Ecosystem and adoption

The open-source release triggered rapid adoption:

ffmpeg: Full SRT send/receive support
OBS Studio: Native SRT output
VLC: SRT playback
Major encoder/decoder manufacturers: Haivision (native), Matrox, Telestream, Ateme, Harmonic, and dozens of others
Cloud platforms: AWS Elemental, Azure Media Services, and many CDNs added SRT ingest endpoints
Free SRT implementations: srtla (SRT Link Aggregation), various open-source gateways

This ecosystem breadth is SRT’s greatest strength — it changed IP contribution from a proprietary-endpoint problem into a commodity.

Strengths

Open-source and free — no licensing fees for the protocol itself
Massive interoperability across vendors and platforms
Strong security (AES-256) built in from the start
Low latency: sub-100ms on LAN, 200–500ms practical for WAN contribution
NAT traversal via Rendezvous mode
Active development community (GitHub: Haivision/srt)
Increasingly treated as a de facto industry standard for contribution

Weaknesses

ARQ-only, no FEC — on very high-loss paths (>5%), SRT will struggle without additional forward error correction at another layer
Recovery is dependent on RTT; very high-latency paths (satellite, >300ms) push required buffer to 1 second or more
No built-in management plane — monitoring, routing, and orchestration require additional tooling
Interoperability varies: implementations nominally SRT-compatible can have subtle differences in behavior under stress
No hub-and-spoke routing model built in (unlike Zixi Broadcaster)

RIST: The Open-Standard Alternative

RIST (Reliable Internet Stream Transport) is the broadcast industry’s committee-designed answer to the proprietary fragmentation that SRT solved on the open-source side. Where SRT originated at a single vendor (Haivision) and was open-sourced later, RIST was designed from the start by a cross-vendor working group — the RIST Forum, now the Video Services Forum (VSF) — specifically for reliable video transport over the public internet. It is also an ANSI/SCTE standard (SCTE 210).

Three Profiles

RIST is defined in three progressively richer profiles:

Simple Profile (VSF TR-06-1 / SCTE 210 Part 1): Basic ARQ using RTCP NACK (RFC 4585) over standard RTP/UDP. No encryption, minimal complexity, maximum interoperability. Any device that speaks RFC 4585 RTCP NACK can participate at this level.

Main Profile (VSF TR-06-2 / SCTE 210 Part 2): Adds AES-128/256 encryption, GRE tunneling (to multiplex multiple streams over one UDP port), bonding across multiple network paths (similar to SMPTE 2022-7 seamless switching logic), and enhanced RTCP-based control messaging. This is the most commonly deployed profile in professional contribution.

Advanced Profile (VSF TR-06-3): Adds further features including FEC. Less widely implemented as of 2024.

How RIST ARQ Works

RIST Simple Profile uses the same fundamental ARQ concept as SRT:

Sender transmits RTP packets over UDP with sequence numbers
Receiver detects gaps and sends RTCP NACK requests for missing packets
Sender retransmits from a buffer
Receiver’s playout buffer absorbs the retransmit round trip

The configurable latency buffer concept is identical: set it to at least 3× your round-trip time. For a trans-Atlantic link at 120ms RTT, a 400–600ms buffer is typical.

RIST vs SRT: Where They Differ

	RIST	SRT
Design origin	Committee standard (VSF/SCTE)	Haivision, then open-sourced
Transport framing	Standard RTP/RTCP	Custom protocol (over UDT)
Encryption	Main Profile: AES-128/256	Built-in AES-128/256
Multi-path bonding	Main Profile: yes	Not native (requires external tools)
Ecosystem size (2024)	Growing, especially in CDN/cloud	Very large, de facto standard
Interoperability	High (uses standard RTCP NACK)	High (open-source library widely adopted)

The RTP framing advantage: RIST’s use of standard RTP/RTCP means it can interoperate with devices that already speak RTP without requiring a new protocol library — an important consideration in mixed-vendor broadcast infrastructure. SRT’s custom framing means every endpoint must run an SRT library.

The ecosystem gap: Despite RIST’s standards pedigree, SRT has broader real-world adoption today. More encoders, decoders, cloud platforms, and software tools have SRT support. RIST is gaining ground particularly in situations where standards compliance is contractually required or where multi-path bonding is needed without third-party tools.

RIST in Practice

RIST is well-supported in professional broadcast equipment from vendors including Harmonic, Haivision (yes — they support both), Appear, Cobalt Digital, and others. Cloud playout and CDN ingest endpoints are increasingly offering RIST alongside SRT. For new infrastructure where you have flexibility on both ends, RIST Main Profile and SRT are functionally very similar in practice; the choice often comes down to existing vendor ecosystem and whether built-in multi-path bonding is needed.

SMPTE 2022-1/2 COP: Broadcast FEC Over IP

SMPTE 2022-1 and 2022-2 define Forward Error Correction for real-time video/audio transport over IP, standardized in 2007. These standards describe a 2D XOR parity FEC scheme — originally designed for managed broadcast IP networks, satellite contribution, and studio infrastructure where no return channel exists for ARQ. Understanding why they work brilliantly for those use cases — and fail on the internet — requires understanding how the FEC matrix works.

How the FEC Matrix Works

The fundamental unit is a 2D grid of L columns and D rows:

Packet grid (L=5, D=4 example):

  Col 1   Col 2   Col 3   Col 4   Col 5
[ P1    ] [ P2  ] [ P3  ] [ P4  ] [ P5  ]  ← Row 1
[ P6    ] [ P7  ] [ P8  ] [ P9  ] [ P10 ]  ← Row 2
[ P11   ] [ P12 ] [ P13 ] [ P14 ] [ P15 ]  ← Row 3
[ P16   ] [ P17 ] [ P18 ] [ P19 ] [ P20 ]  ← Row 4
─────────────────────────────────────────
[ FEC_C1] [FEC_C2][FEC_C3][FEC_C4][FEC_C5] ← Column FEC (XOR of each column)
[ FEC_R1] [FEC_R2][FEC_R3][FEC_R4]          ← Row FEC (XOR of each row) [2022-2 only]

Each FEC packet is the XOR of its corresponding column (or row). If any one packet in a column is lost, the column FEC packet can reconstruct it. This is sent as a separate RTP stream alongside the primary video RTP stream.

SMPTE 2022-1 (Column Only Protection / COP): Only column FEC packets are sent. A single loss anywhere in a column is recoverable. L column FEC packets are generated per L×D data packets.
SMPTE 2022-2 (Row + Column Protection): Both row and column FEC packets are sent, providing a second layer of redundancy. A packet lost in both a row and a column can still potentially be recovered if the other cells in those rows/columns are intact.

Bandwidth Overhead

The FEC overhead is deterministic and constant, calculated from the L×D parameters:

Configuration	Data packets	FEC packets (2022-1)	Overhead	FEC packets (2022-2)	Overhead
L=5, D=5	25	5 col	20%	5 col + 5 row = 10	40%
L=8, D=8	64	8 col	12.5%	8 col + 8 row = 16	25%
L=10, D=10	100	10 col	10%	10 col + 10 row = 20	20%
L=20, D=20	400	20 col	5%	20 col + 20 row = 40	10%

FEC Overhead on a Real Stream

Consider a 10 Mb/s HD contribution stream through a 2022-2 deployment with L=8, D=8 (a common mid-range choice):

Primary video stream:     10.00 Mb/s
Column FEC stream:         1.25 Mb/s  (8 FEC packets per 64 data = 12.5%)
Row FEC stream:            1.25 Mb/s  (8 FEC packets per 64 data = 12.5%)
──────────────────────────────────────
Total bandwidth required:  12.50 Mb/s  (25% overhead)

This overhead is paid on every packet, regardless of whether any packets were actually lost. Even if the path is crystal clear with 0% packet loss, the FEC overhead is still 25%.

Compare that to ARQ on the same 10 Mb/s stream at 1% packet loss:

Primary video stream:     10.00 Mb/s
ARQ retransmits (~1%):     0.10 Mb/s  (only what's lost)
──────────────────────────────────────
Total bandwidth required:  10.10 Mb/s  (~1% overhead, adaptive)

ARQ overhead scales with actual loss. FEC overhead is static.

Why SMPTE 2022-1/2 Is Not Ideal for Internet Streaming

1. Internet loss is bursty, not random. SMPTE 2022 FEC is designed for random independent packet loss — the statistical model where no two consecutive losses correlate. XOR parity can only recover one lost packet per row or column. Internet congestion loss is different: a single congestion event drops 5–20 consecutive packets (a burst). If that burst spans multiple adjacent columns in the FEC matrix, each column loses one packet — fine. But if the burst is longer than D packets, packets in the same column are lost, and the XOR FEC cannot recover them (you need two losses to cancel each other, not reconstruct). Burst loss breaks the mathematical assumption the FEC matrix was built on.

2. Constant overhead can trigger more congestion. If the internet path is near capacity, adding 20–25% FEC overhead can push it over the threshold, increasing congestion, which increases loss, which the FEC now can’t handle because the burst exceeds the matrix size. On a managed broadcast network with guaranteed bandwidth, this doesn’t happen. On the internet it absolutely can.

3. FEC latency from matrix completion. The receiver must accumulate an entire FEC matrix — L×D data packets plus all FEC packets — before it can output the corrected stream for that block. At 10 Mb/s with 188-byte TS packets (6,648 packets/second), an 8×8 matrix (64 data packets) fills in ~9.6ms. Adding the column FEC arrival window, total FEC-induced latency is typically 20–50ms — small, but it’s unavoidable and non-adaptive.

4. No feedback loop. SMPTE 2022-1/2 has no mechanism to detect that the path is degraded and adapt. If loss exceeds what the FEC matrix can correct, packets are simply dropped silently. ARQ-based protocols at least report the loss to the application layer.

Where SMPTE 2022-1/2 Belongs

Despite these internet limitations, SMPTE 2022-1/2 remains the right choice for:

Satellite contribution and distribution — no return channel exists for ARQ, so proactive FEC is the only option
Managed broadcast IP networks (studio-to-studio over dedicated WAN) — where bandwidth is guaranteed and loss is statistically random
One-way multicast distribution — same return-channel constraint as satellite
High-loss paths where latency budget doesn’t allow ARQ — if RTT is 500ms and the buffer can’t absorb the retransmit round trip, FEC may be the better tool

For internet contribution with available return channel (any two-way IP path), prefer SRT, RIST, or Zixi — all of which adapt dynamically to actual path conditions.

Side-by-Side Comparison

Feature	Fujitsu ARQ	Zixi	SRT	RIST	SMPTE 2022-1/2
Recovery method	ARQ (selective repeat)	ARQ + FEC	ARQ (selective repeat)	ARQ (RTCP NACK)	FEC only (no ARQ)
Encryption	None	AES-128/256	AES-128/256	AES-128/256 (Main+)	None (separate layer)
Licensing	Proprietary, closed	Licensed (per stream)	Open-source (LGPL)	Open standard (VSF/SCTE)	Open standard (SMPTE)
Cost	Hardware purchase	Licensing fees	Free	Free	Free
Vendor interop	None	Zixi partners only	Very broad	Good (standard RTP)	Broad (managed net)
NAT traversal	Limited	Yes	Yes (Rendezvous)	Main Profile: yes	No
Multi-path bonding	No	Yes (Broadcaster)	No (native)	Main Profile: yes	No
Latency (LAN)	~100-300ms	~50-200ms	~20-100ms	~20-100ms	~20-50ms (FEC matrix)
Latency (WAN)	~300ms-1s	~200ms-1s	~200ms-800ms	~200ms-800ms	Fixed (matrix-based)
Bandwidth overhead	Low (ARQ)	Low-medium (ARQ+FEC)	Low (ARQ)	Low (ARQ)	10-50% constant
High-loss resilience	Moderate	Good (FEC+ARQ)	Moderate	Moderate	Good (managed nets only)
Burst-loss resilience	Moderate	Good	Moderate	Moderate	Poor (internet paths)
Management plane	None	ZEN Master	Third-party	Third-party	None
Best for	Legacy only	Hostile paths, managed	Internet contribution	Internet contribution	Satellite, managed IP, multicast
Status	Legacy, discontinued	Active, evolving	Active, widely deployed	Growing adoption	Widely deployed (broadcast)

Choosing the Right Protocol

Use SRT when:

You need broad interoperability — connecting encoders from one vendor to decoders/platforms from another
Cost matters: licensing fees are a real constraint
The path has moderate packet loss (<3-5%) and predictable RTT
You’re working with cloud platforms (AWS Elemental, Azure, CDNs) that speak SRT natively
You need open-source software tools (ffmpeg, OBS) on either end

Use RIST when:

Standards compliance is a contractual or procurement requirement (VSF TR-06, SCTE 210)
You need native multi-path bonding without third-party tools (RIST Main Profile)
You’re building infrastructure where RTP interoperability with non-SRT devices matters
You want the flexibility of committee-backed standardization over vendor-origin open-source
The receiver ecosystem already supports RTCP NACK natively

Use Zixi when:

You need ARQ + FEC for resilience on genuinely hostile paths (lossy last-mile, spotty 4G/5G bonding)
You need a managed routing/hub infrastructure (Zixi Broadcaster + ZEN Master)
Your customer or partner already has Zixi infrastructure and you need to connect into it
SLA support from the protocol vendor is a requirement for the service

Use SMPTE 2022-1/2 when:

The path is one-way with no return channel: satellite uplink/downlink, multicast, cable forward path
You’re on a managed broadcast IP network with guaranteed bandwidth and statistically independent (non-bursty) loss
The downstream device requires standard broadcast FEC framing (many IRDs and satellite receivers expect it)
You cannot use ARQ because latency budget does not allow a retransmit round trip

Avoid SMPTE 2022-1/2 for internet streaming because:

Internet loss is bursty, not random — burst events exceed what XOR parity can correct per row/column
Static bandwidth overhead (10-50%) cannot adapt to changing path conditions
ARQ-based protocols (SRT, RIST, Zixi) are strictly more bandwidth-efficient on any two-way path
Overhead itself can induce congestion on paths near capacity

Avoid Fujitsu ARQ (legacy considerations only):

Do not design any new deployment around this technology — no migration path exists
For existing systems still running Fujitsu transport: plan migration to SRT or Zixi

The Bigger Picture: Protocol Convergence

The emergence of SRT as a broadly adopted open standard has reshaped the market. What was once a world of incompatible proprietary ARQ solutions (Fujitsu, Zixi, Haivision’s own pre-SRT implementation, plus others like Nevion’s NMX protocol, Appear’s transport layer) is increasingly a world where SRT handles most point-to-point contribution needs for free.

Zixi has responded by doubling down on what SRT cannot offer: the full ZEN Master management plane, the FEC layer for hostile paths, and the professional-grade support model. These remain real advantages for major live event broadcasters and sports networks with complex multi-site infrastructure.

The likely long-term outcome is a tiered market: SRT as the commodity baseline for most contribution (just as HTTP became the baseline for web delivery), and proprietary managed platforms like Zixi for the highest-reliability tier.

SRT, Zixi, and the Evolution of Reliable IP Video Transport

The Problem: Why Standard UDP Isn’t Enough

Fujitsu ARQ: The Proprietary Precursor

Zixi: Professional Broadcast Protocol from the Ground Up

Origins

Protocol architecture

The Zixi ecosystem

Zixi’s licensing model

Strengths

Weaknesses

SRT: The Open-Source Revolution

Origins at Haivision

Open-sourcing: April 2017

How SRT works

Ecosystem and adoption

Strengths

Weaknesses

RIST: The Open-Standard Alternative

Three Profiles

How RIST ARQ Works

RIST vs SRT: Where They Differ

RIST in Practice

SMPTE 2022-1/2 COP: Broadcast FEC Over IP

How the FEC Matrix Works

Bandwidth Overhead

FEC Overhead on a Real Stream

Why SMPTE 2022-1/2 Is Not Ideal for Internet Streaming

Where SMPTE 2022-1/2 Belongs

Side-by-Side Comparison

Choosing the Right Protocol

The Bigger Picture: Protocol Convergence

Further Reading

Related guides

DVB-S, DVB-S2, and DVB-S2X: A Broadcast Engineer's Guide

HLS, DASH, and Modern CDN Video Delivery: A Technical Guide

MPEG Transport Streams: A Technical Reference