Why This Matters
If you build streaming products that talk to broadcasters, productions, or audio-visual integrators, the conversation eventually reaches a place where your contribution protocol stops and the customer's facility network begins. A sports broadcaster pushing a feed to your platform may have an SMPTE ST 2110 production fabric upstream of the encoder that hands you the Real Time Messaging Protocol or SRT stream. A house of worship live-streaming team almost certainly uses NDI between its switcher and its computer. A Tier 1 broadcaster pushing global feeds to dozens of affiliates very probably uses Zixi inside a private WAN even when their public-internet contribution is on SRT.
This article is for the product manager, founder, or engineer who has heard "we run NDI internally," "we ingest off ST 2110," or "the network team only allows Zixi" in a customer call and wants to know what each one actually is, what it competes with, and where the boundary sits between these "studio" protocols and the open-internet contribution protocols the Fora Soft Learn hub spends most of its time on. You will leave with a mental model that lets you nod intelligently in a broadcast-architecture review, ask the right one or two follow-up questions, and know when to suggest your team adds a connector instead of trying to bridge the gap with off-the-shelf software.
Three Protocols, Three Different Jobs
The single most useful thing to keep straight is that these three protocols do not compete with one another. They occupy three different layers of a broadcast operation, and a fully-equipped facility uses all three at the same time. Mixing them up in conversation is the surest way to lose the customer's broadcast engineer in the first ten minutes of a scoping call.
Zixi is a wide-area-network contribution protocol — a public-internet or private-network protocol that moves a compressed video stream from a remote source (a camera bag in a stadium, a fly-pack in a hotel ballroom, a satellite truck) to a master control room. Its competitors are SRT and RIST, not NDI or ST 2110.
NDI is a local-area-network production protocol — a studio-network protocol that moves video between software and hardware inside a single building or campus. Its competitors are SDI (Serial Digital Interface, the coaxial-cable standard NDI replaces) and ST 2110, not Zixi.
ST 2110 is a facility-grade IP transport — an engineered managed-network protocol that replaces SDI inside the most demanding broadcast facilities, with strict timing, uncompressed essence, and a separate control plane. Its competitors are SDI (the cable it replaces) and NDI (the lighter-weight IP alternative), not Zixi.
That mapping is the entire reason this article exists. A streaming engineer who knows where Zixi, NDI, and ST 2110 sit relative to each other can navigate a broadcast-architecture conversation. One who does not will struggle to interpret answers like "we are an ST 2110 facility with NDI islands and Zixi-based remote contribution."
Figure 1. Where Zixi, NDI and SMPTE ST 2110 each sit in a broadcast operation. The three protocols cooperate, they do not compete.
NDI — The Studio LAN Protocol
NDI, short for Network Device Interface, is the protocol that almost every live production using off-the-shelf software touches at some point. The picture that flows from OBS Studio to vMix to the streaming output, the picture that arrives from a Pan-Tilt-Zoom (the camera type that moves remotely, abbreviated PTZ) camera on a Gigabit Ethernet jack, the picture that travels between Adobe Premiere and a hardware multi-viewer — all of those journeys are usually NDI.
What NDI Is
NDI is an IP-based video and audio transport protocol designed to move multiple simultaneous live streams across a standard Gigabit Ethernet local-area network. It was announced by NewTek in September 2015 and shipped in the first products in early 2016. NewTek was acquired by the Norwegian Vizrt Group in 2019, and NDI is now developed and licensed by the Vizrt Group's NDI subsidiary. The NDI SDK is offered under a royalty-free proprietary licence — vendors integrate it without paying a per-unit fee, which is the single biggest reason adoption is as wide as it is.
The protocol carries a video stream, multiple channels of audio, an alpha channel, embedded bidirectional Extensible Markup Language metadata, Pan-Tilt-Zoom control commands, "tally" signalling (the on-air light that tells a camera operator their camera is live), and keyboard-video-mouse forwarding — all over a single network connection per stream. Discovery is zero-configuration: NDI senders announce themselves on the local network with multicast Domain Name System (the protocol Apple calls Bonjour), and any NDI receiver on the same subnet can pick them up without manual configuration.
The default delivery transport is Transmission Control Protocol on a dynamically selected port between sender and receiver. Newer releases also support User Datagram Protocol with forward error correction, multi-stream Transmission Control Protocol, and a reliable User Datagram Protocol variant built on the same family of ideas as QUIC. The protocol's design assumption is a well-engineered switched LAN — not a public-internet path.
NDI Full Bandwidth Versus NDI HX
NDI ships in two main formats. Full bandwidth NDI uses an intra-frame proprietary codec called SpeedHQ — a discrete-cosine-transform-based design in the same family as digital cinema's DNxHD or Apple's ProRes, designed to be visually lossless and to decode quickly on commodity central processing units. A Full NDI feed of 1080p at 60 frames per second runs roughly 100 to 125 megabits per second; 2160p (Ultra-High-Definition) at 60 frames per second runs roughly 200 megabits per second. Glass-to-glass latency is sub-two-frames — at 60 frames per second that is under 33 milliseconds, low enough that a presenter on an NDI return feed sees themselves and a remote guest with no perceptible lag.
NDI HX (the "high-efficiency" variants) trade some quality and a few additional frames of latency for a much smaller bandwidth bill. NDI HX and NDI HX2 use long-Group-of-Pictures H.264 encoding. NDI HX3, released in 2023, supports both an H.265 / High-Efficiency-Video-Coding mode and a more efficient H.264 4:2:0 mode. An NDI HX3 H.265 stream at 1080p60 runs about 50 megabits per second, at 4Kp60 about 84 megabits per second, with glass-to-glass latency under 100 milliseconds and a Group-of-Pictures of 20 frames.
The arithmetic, out loud. Imagine a four-camera live production sending Full NDI feeds across a 10 gigabit Ethernet switch. Each feed is 125 megabits per second; four feeds is 4 times 125 equals 500 megabits per second of unicast traffic, well within the headroom of a single 10 gigabit link. The same four feeds in 4K at 200 megabits per second each is 4 times 200 equals 800 megabits per second — still inside one 10 gigabit link, but now leaving less margin for the dozen graphics, multi-viewer, and record-server feeds that ride the same fabric. That headroom calculation is exactly why studio LANs run 10 gigabit or faster even when the public-internet uplink is only 100 megabits per second.
NDI 6 And NDI 6.3 — What Changed In 2024 - 2026
NDI 6 shipped on 3 April 2024 and added three things production teams had asked for since the High-Dynamic-Range home-television transition. First, native High Dynamic Range — both Perceptual Quantizer (the High-Dynamic-Range transfer function used by Dolby Vision and HDR10) and Hybrid Log-Gamma (the broadcast High-Dynamic-Range transfer function used by the BBC and NHK). Second, 10-bit and beyond colour, up to 16 bits per channel, which lets cinema-grade source material survive an NDI hop without quantization noise. Third, the embedded NDI Bridge utility in hardware devices — NDI Bridge is the tool that tunnels NDI across the public internet between two facilities, and putting it inside hardware encoders makes remote production setups much simpler.
NDI 6.3, shown at the Integrated Systems Europe 2026 show in February and the National Association of Broadcasters Show in April 2026, focused on operability rather than new features. It added real-time monitoring of multiple NDI sources from one dashboard (packet loss, jitter, signal-health diagnostics), refinements to discovery and control, and High-bandwidth Digital Content Protection (the cinema-and-television copy-protection standard, abbreviated HDCP) support for secure Audio-Visual workflows in collaboration with the integrator ProITAV.
Where NDI Fits A Streaming Engineer's World
You will meet NDI as an inbound source in a streaming product when the customer is doing the production with software like vMix or OBS Studio, or when the customer is a corporate audio-visual integrator pushing live signal between rooms. You will meet NDI Bridge when the customer wants a hub-and-spoke production with one master studio and two or three remote contributors, and the remote contributors are running NDI inside their own buildings. You will not meet NDI as an over-the-internet contribution protocol from a stranger's camera bag — that traffic goes through SRT, RIST, WHIP, or Zixi instead, because NDI was not designed for hostile-internet paths.
Zixi — The Proprietary Broadcast Contribution Protocol
Zixi sits in the same slot as SRT and RIST: a User-Datagram-Protocol-based contribution protocol that moves compressed video reliably across lossy network paths. The difference is that Zixi is proprietary, requires a software development kit licence to use, and is wrapped in a vendor-managed control plane that competing open protocols do not match.
What Zixi Is
Zixi is a software-defined video transport stack from Zixi Inc., a company founded in 2006 and headquartered in Waltham, Massachusetts. The company was acquired by the private-equity firm Clearhaven Partners on 13 June 2024, with financial terms not disclosed. The Zixi transport protocol, sometimes called the "Zixi Transport Stream Protocol," runs over User Datagram Protocol and combines four reliability mechanisms inside one wire format: adaptive Forward Error Correction (the technique that adds redundant data so the receiver can repair losses without asking for retransmission, abbreviated FEC), Automatic Repeat reQuest (the technique that asks the sender to resend lost packets, abbreviated ARQ), network bonding across multiple links, and patented "hitless failover" between two parallel paths.
The Zixi system has four moving parts. The Zixi Feeder is the lightweight sender that encapsulates a compressed stream and pushes it onto the wire. The Zixi Receiver is the equivalent on the destination side. The Zixi Broadcaster is the server that aggregates feeds, decapsulates and re-encapsulates them, and acts as a multi-protocol gateway between Zixi and roughly sixteen other protocols (SRT, RIST, Real-Time Messaging Protocol, NDI, HTTP Live Streaming, Dynamic Adaptive Streaming over HTTP, WebRTC, and more). ZEN Master is the cloud-hosted control plane — a single dashboard where operators see every Zixi-integrated device, configure feeds, and monitor health, advertised by Zixi as the orchestration layer for the "Zixi Enabled Network" alliance.
The default ports are User-Datagram-Protocol 2088 for inbound feeder traffic and Broadcaster ingress, User-Datagram-Protocol 2077 for outbound Receiver pulls, and Transmission-Control-Protocol 4444 for the Broadcaster's web management interface. Encryption is built in: User-Datagram-Protocol, file, and Real-Time-Messaging-Protocol inputs can be encrypted using Advanced Encryption Standard with 128-, 192-, or 256-bit keys.
How Zixi Compares To SRT And RIST
Mechanically, Zixi solves the same problem SRT and RIST solve: deliver a compressed video stream reliably across a path that drops one to ten percent of packets, at a configurable latency budget between 200 milliseconds and several seconds. All three protocols use a User-Datagram-Protocol carrier, Automatic-Repeat-reQuest retransmission inside a latency window, and a sender-side congestion-avoidance mechanism. The differences sit elsewhere.
| Criterion | Zixi | SRT | RIST |
|---|---|---|---|
| Specification | Proprietary, SDK-licensed | Open (Haivision reference); IETF draft expired | Open VSF TR-06-1, TR-06-2, TR-06-3 |
| First release | 2006 | 2017 (open-sourced) | 2018 (TR-06-1 published) |
| Wire format | Proprietary | Custom over UDP | RTP / RTCP per RFC 3550 / RFC 4585 |
| Reliability | Adaptive FEC + ARQ + bonding + hitless failover | ARQ + optional FEC | NACK ARQ + bonding via SMPTE 2022-7 |
| Encryption | AES-128 / 192 / 256 | AES-128 / 192 / 256 | DTLS or PSK (Main / Advanced profile) |
| Hitless failover | Yes (patented) | Via SRT path-bonding (SRTLA, less mature) | Yes (SMPTE 2022-7 layered) |
| Control plane | ZEN Master (vendor cloud) | None standardised | None standardised |
| Ecosystem | 1400+ customers, 400+ partners (vendor figures) | Very wide — virtually every encoder | Smaller but growing |
| Licensing | Commercial; SDK fee | Free (MPL-2.0 reference) | Free (VSF specs) |
| Why it wins | Mature, hitless, single-vendor support contract | Universal ecosystem, free | Open spec for tenders, broadcast-grade |
The independent industry view, as Streaming Media Magazine and Rethink Research have observed, is that many broadcasters now run a mix: SRT or RIST for new contribution paths, Zixi for legacy paths and for the multi-protocol broker role, and a quiet pricing renegotiation every couple of years.
Where Zixi Fits A Streaming Engineer's World
If your platform ingests from broadcasters, you will eventually be asked to ingest from a Zixi Broadcaster. The customer rarely wants you to build a Zixi sender — they want you to consume one of the Broadcaster's outbound protocols, which in practice means accepting SRT or RIST from the Broadcaster's egress side. Treating Zixi as "an upstream system whose output is SRT" is the right mental model. The exception is hardware partners and live-production vendors who want to ship a "Zixi-native" integration; that path requires a commercial Software Development Kit licence from Zixi, and the conversation goes through sales rather than engineering.
SMPTE ST 2110 — The Engineered Replacement For SDI
Inside the most demanding broadcast facilities — the ones that produce live sport, network news, and the kind of premium content where a single dropped frame is a notable incident — Serial Digital Interface is being replaced by Internet Protocol. The standard governing that replacement is SMPTE ST 2110, and it is unlike anything else in this article in three important ways: it is published by a formal standards body, it carries uncompressed video as its design centre, and it requires a managed network engineered specifically for it.
What ST 2110 Is
SMPTE ST 2110, formally titled "Professional Media Over Managed IP Networks," is a multi-part suite of standards published by the Society of Motion Picture and Television Engineers. The first six parts published together on 27 November 2017; subsequent parts and revisions have followed at a pace of one or two per year. The suite's central design idea is to take an SDI stream — which bundles video, audio, and ancillary data into one coaxial-cable signal — and unbundle each essence into its own Real-time Transport Protocol stream on an IP network. Video, audio, captions, and timecode each travel on a separate multicast group, and downstream equipment subscribes only to the essences it needs.
The suite is organized into family numbers. The ST 2110-1x family covers the system layer (timing, definitions). The ST 2110-2x family covers video. The ST 2110-3x family covers audio. The ST 2110-4x family covers ancillary data and text. Here are the parts a streaming engineer needs to recognize by name:
- ST 2110-10:2022 — System timing and definitions. The "what time does it think it is" foundation.
- ST 2110-20:2022 — Uncompressed active video, built on the Internet Engineering Task Force's RFC 4175 Real-time Transport Protocol payload for raw video.
- ST 2110-21:2017 — Traffic shaping and delivery timing for video. Defines the Narrow, Narrow Linear, and Wide sender types that constrain how packets are paced onto the wire.
- ST 2110-22:2019 — Constant Bit Rate Compressed Video. In practice this is JPEG Extra-Small compression (ISO/IEC 21122), the visually-lossless light-compression option that brings bandwidth down to roughly one-tenth of uncompressed.
- ST 2110-30:2017 — Pulse-Code-Modulation audio, profiled as Audio Engineering Society 67.
- ST 2110-31:2022 — AES3 transparent audio transport, for non-Pulse-Code-Modulation payloads such as Dolby E.
- ST 2110-40:2023 — Ancillary data — closed captions, timecode, and the Society of Motion Picture and Television Engineers ANC packets SDI used to carry.
The freely-readable PDFs of each part live on pub.smpte.org; the catalogue-grade copies on the SMPTE site itself are paywalled.
Why Uncompressed, And What It Costs
The defining choice of ST 2110-20 is to carry raw, uncompressed pixels. There is no codec. There is no Group-of-Pictures structure. There is no quantization step. The receiver gets the same bits the camera produced, with zero generational loss. That is what broadcast facilities want for the same reason recording studios mix on uncompressed Pulse-Code-Modulation audio: the format is transparent, and you can degrade it later when you publish, instead of degrading it now and never being able to recover.
The price is bandwidth. Uncompressed 1080p at 59.94 frames per second is roughly 2.1 to 3 gigabits per second on the wire, depending on whether the sender carries vertical-blanking pixels. Uncompressed 2160p (Ultra-High-Definition) at 59.94 frames per second is roughly 8 to 12 gigabits per second. A modest broadcast control room with 30 cameras, 10 graphics feeds, 8 multi-viewers, and 12 replay servers can easily push 100 to 300 gigabits per second of total ST 2110 traffic across the fabric. Network engineering for that load is a different discipline from network engineering for an office building.
The arithmetic, out loud. A 50-camera ST 2110 production at 1080p59.94 with 30 input feeds at 3 gigabits per second is 30 times 3 equals 90 gigabits per second of camera input traffic. Add 10 graphics output feeds and 8 multi-viewer feeds at roughly 3 gigabits per second each — that is 18 times 3 equals 54 gigabits per second of additional internal traffic. Total fabric load is 90 plus 54 equals 144 gigabits per second sustained — comfortably inside a single 200-gigabit-per-second Ethernet spine, but well outside what a 10-gigabit office switch can sustain. This is why a real ST 2110 facility uses 25, 100, or 200 gigabit Ethernet switches throughout.
ST 2110-22 with JPEG Extra-Small compression is the safety-valve part. JPEG Extra-Small compresses by roughly six to twenty times with imperceptible quality loss and one-millisecond encode-decode latency. A 3 gigabit-per-second uncompressed feed becomes a 300 megabit-per-second JPEG Extra-Small feed under -22 — that is the only practical way to move ST 2110 over wide-area-network links shorter than a transcontinental fibre, and it is the path used for ST 2110-over-WAN gateways.
The Network Itself — PTP, Multicast, And NMOS
Three pieces of infrastructure are what separate an ST 2110 network from a regular IP network. None of them is optional.
Precision Time Protocol (IEEE 1588-2019), abbreviated PTP, is the synchronization protocol that gives every device on the network a shared sub-microsecond view of time. ST 2110 is designed so that two video receivers tuned to the same source see the same pixels at the same moment within a few hundred nanoseconds. That requires every switch on the path to act as a Precision Time Protocol boundary clock, processing the protocol's announcement and synchronization messages in hardware. SMPTE Standard 2059-2 profiles Precision Time Protocol for broadcast use.
Multicast routing, typically via Internet Group Management Protocol version 3 and Protocol-Independent Multicast Source-Specific Multicast, is how a single sender reaches many receivers without copying packets at the source. A camera output is a multicast group; any device that wants the picture joins the group. That model works only on switches that handle multicast properly at line rate — most office switches do not.
AMWA NMOS (Networked Media Open Specifications, from the Advanced Media Workflow Association) is the control-plane layer. ST 2110 itself defines only how essence packets travel; NMOS defines how devices discover each other, how operators "connect" a source to a destination, and how tally and metadata flow. The NMOS specifications a streaming engineer should recognise by name are IS-04 (Discovery and Registration), IS-05 (Device Connection Management), IS-07 (Event and Tally), IS-08 (Audio Channel Mapping), IS-09 (System Parameters), and IS-10 (Authorization). The full set is published openly at specs.amwa.tv/nmos.
The interoperability programme that certifies devices for use on these networks is JT-NM Tested, run jointly by the European Broadcasting Union, the Society of Motion Picture and Television Engineers, the Video Services Forum, and the Advanced Media Workflow Association. Two catalogues exist — one for ST 2110, ST 2059 and ST 2022-7 conformance, one for AMWA NMOS and JT-NM Technical Recommendation 1001-1 conformance. Both ran active programmes at the National Association of Broadcasters Show in April 2026.
Figure 2. A simplified SMPTE ST 2110 facility fabric. Notice the separate Precision Time Protocol distribution and the AMWA NMOS control plane — both are mandatory, neither is part of ST 2110 itself.
ST 2110 In Production — Olympics-Scale Examples
Two Olympic Games sit on either side of the production-maturity line. The Paris 2024 Summer Games were the first Olympics where the host broadcaster, Olympic Broadcasting Services, offered ST 2110 contribution as a path option to rightsholders, and where France Télévisions produced 4K Ultra-High-Definition High-Dynamic-Range coverage on a fully ST 2110 plant — a migration that began in 2021. The Milano-Cortina 2026 Winter Games went further: NBC executed a trans-Atlantic remote-integration (Remote Integration Model, abbreviated REMI) production with 810 cameras in Italy feeding back to Stamford, Connecticut, on an end-to-end ST 2110 fabric with JPEG Extra-Small encapsulation across the wide-area-network legs. Sports Video Group's coverage notes that the production used Artificial-Intelligence replay tools, cinematic live workflows, and first-person-view drones — all running on the ST 2110 fabric, all gated by the Precision Time Protocol timing.
The lesson for streaming engineers is operational, not technical. ST 2110 is the network protocol the most demanding live productions actually use in 2026. Anything you build that ingests from one of those productions sits downstream of an ST 2110 plant, takes a compressed feed across an SRT, RIST, or Zixi link, and then becomes the engineering team's responsibility from there. Knowing this lets you ask the right setup question: "Is the encoder output we receive an SRT stream off your ST 2110 fabric, or are you running an HTTP-Live-Streaming origin downstream of the encoder?" The answer changes how you wire the rest of the integration.
Comparison: When Each Protocol Wins
The boundary between the three is sharp enough to draw in a single table.
| Question | Answer |
|---|---|
| Studio LAN, low-cost integration, off-the-shelf software (OBS, vMix) | NDI |
| Studio LAN, broadcast-grade facility, uncompressed essence, formal standards | SMPTE ST 2110 |
| Wide-area-network contribution between facilities or over public internet, vendor-managed | Zixi |
| Wide-area-network contribution between facilities or over public internet, open standard | SRT or RIST |
| Remote production with one master studio and remote contributors running NDI locally | NDI Bridge over a private wide-area-network |
| Ultra-High-Definition 4K Olympic-scale production with sub-frame latency budget | ST 2110 with JPEG Extra-Small on wide-area-network legs |
| Hub-and-spoke gateway between many input and output protocols | Zixi Broadcaster or open-source equivalent |
| Sub-millisecond timing accuracy across dozens of devices on one fabric | ST 2110 with Precision Time Protocol — nothing else qualifies |
Figure 3. The handoffs between the studio, facility, contribution and delivery domains. Each boundary is a conversion point — the place where one protocol becomes another.
Common Mistake: Treating ST 2110 As "IP Streaming"
The single most expensive misunderstanding a streaming engineer can carry into a broadcast conversation is the assumption that "video over IP" means the same thing on both sides of the line. It does not. The "IP" in SMPTE ST 2110 is engineered Layer 3 transport on a private fabric with sub-microsecond timing and multicast routing. The "IP" in HTTP Live Streaming or WebRTC is whatever public-internet path the user's traffic happens to take through a content delivery network. Both run on Internet Protocol; they share almost nothing else.
A common error is to assume an ST 2110 stream can be "tunneled" across the public internet by simply forwarding the multicast packets. It cannot. ST 2110-20's bitrate is far above any commodity uplink, its Precision Time Protocol synchronization breaks the moment the packets traverse a router that does not act as a boundary clock, and its packet pacing under -21 does not survive a buffering link. ST 2110 over wide-area-network is a specialised topic — solved by ST 2110-22 (JPEG Extra-Small compression) plus RIST Advanced Profile encapsulation, or by purpose-built bridges from vendors such as AJA, Artel and Net Insight — and not something a generic streaming engineer attempts ad-hoc.
The same mistake in the other direction is to assume NDI is "broadcast-grade enough" for a network operations centre. NDI's SpeedHQ codec is visually lossless for most production work, but it is intra-frame compressed; ST 2110-20 is uncompressed. For the live news network where the chief engineer can recite the frame number on which a 2014 botched dissolve happened, "visually lossless" is not the same word as "lossless." Match the protocol to the customer's tolerance.
Where Fora Soft Fits In
We have shipped production-grade WebRTC, HTTP-Live-Streaming, and Real-Time Messaging Protocol contribution stacks for video-streaming, OTT/Internet-television, e-learning, telemedicine, video-surveillance, and augmented-reality / virtual-reality projects, and we routinely integrate with customer-side encoders that feed off ST 2110, NDI, or Zixi fabrics upstream of our ingest. The most useful pattern we have seen is to treat the studio-domain protocol as the customer's responsibility, take a clean wide-area-network handoff on SRT or WHIP, and then own the cloud-to-viewer half ourselves. That boundary keeps the integration crisp, lets the customer's broadcast engineers keep their NMOS and Precision Time Protocol stack untouched, and gives us a contractually clean place to monitor quality-of-experience.
What To Read Next
- SRT: the professional standard for public-internet contribution
- RIST: the broadcast-grade alternative
- Picking an ingest protocol in 2026: a decision tree
Talk To Us · See Our Work · Download
Talk to a streaming engineer about integrating with a broadcaster's ST 2110, NDI, or Zixi fabric. See our case studies in OTT, e-learning, and telemedicine where studio-grade contribution feeds met cloud-grade delivery. Download the Studio-Protocols Cheat Sheet (PDF) — a one-page printable reference summarising Zixi, NDI and ST 2110 with the latency, bandwidth, transport, and 2026 spec references.
References
- SMPTE ST 2110-10:2022 — System Timing and Definitions. Society of Motion Picture and Television Engineers, March 2022.
- SMPTE ST 2110-20:2022 — Uncompressed Active Video. Society of Motion Picture and Television Engineers, 2022.
- SMPTE ST 2110-21:2017 — Traffic Shaping and Delivery Timing. Society of Motion Picture and Television Engineers, November 2017. Tier 1 — official standard. Supports the Narrow / Narrow Linear / Wide sender-type model.
- SMPTE ST 2110-22:2019 — Constant Bit Rate Compressed Video. Society of Motion Picture and Television Engineers, 2019. Tier 1 — official standard. Supports the JPEG Extra-Small profile as the lightly-compressed option for ST 2110 over wide-area-network.
- SMPTE ST 2110-30:2017 — PCM Digital Audio. Society of Motion Picture and Television Engineers, November 2017. Tier 1 — official standard. Supports the Audio Engineering Society 67 profile for audio essence.
- SMPTE ST 2110-31:2022 — AES3 Transparent Transport. Society of Motion Picture and Television Engineers, 2022.
- SMPTE ST 2110-40:2023 — Ancillary Data. Society of Motion Picture and Television Engineers, 2023.
- IETF RFC 4175 — RTP Payload Format for Uncompressed Video. N. Gharai et al., September 2005.
- IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne et al., July 2003.
- IEEE 1588-2019 — Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. Institute of Electrical and Electronics Engineers, 2019. Tier 1 — official standard. The Precision Time Protocol baseline; ST 2110-10 profiles it via SMPTE ST 2059-2.
- AMWA NMOS Specification Portal. Advanced Media Workflow Association, accessed 2026-05-21.
- NDI Documentation — White Paper on NDI Protocols. Vizrt NDI, accessed 2026-05-21.
- NDI 6 Launch Announcement. NewscastStudio, 7 April 2024.
- NDI 6.3 Core Update — AV Network Coverage. AV Network, April 2026.
- Zixi Transport Stream Protocol Documentation. Zixi, accessed 2026-05-21.
- Clearhaven Partners Acquires Zixi. Zixi press release, 13 June 2024.
- JT-NM Tested Programme — KitPlus Overview. KitPlus, accessed 2026-05-21.
- France Télévisions ST 2110 — Olympics 2024 Roundtable. European Broadcasting Union, accessed 2026-05-21.
- NBC Milano-Cortina 2026 IBC Operations. Sports Video Group, 23 February 2026.
