ST 2110

The broadcast industry spent the better part of a decade converging on ST 2110 and NMOS as the open standards for professional media over IP. The Pro AV industry - corporate, higher education, live events, hospitality, digital signage - has been having a parallel conversation, mostly in private, and mostly arriving at proprietary conclusions. SDVoE, Dante AV, NDI, AVoIP chipset ecosystems from various manufacturers: each solves the AV distribution problem, none of them solve it in the same way, and none of them interoperate with each other or with broadcast infrastructure. If you have ever tried to connect a corporate AV system to a broadcast facility, or route signal between a proprietary HDMI-over-IP encoder and an ST 2110 infrastructure, you will understand the problem immediately. ...

ST 2110 and AES67 both depend on IP multicast. A single uncompressed HD video stream can consume 3 Gbps. A facility running dozens of simultaneous video and audio flows, all as multicast, needs a mechanism for ensuring those streams only reach the switches and devices that actually need them. Without that mechanism, every multicast packet floods to every port on the network - which in a media facility would be catastrophic. ...

IS-05 handles making the connection between a sender and a receiver. Once that connection exists, a multi-channel audio flow is arriving at the receiver - but which channels end up on which outputs is a separate question, and IS-05 has nothing to say about it. That is the gap IS-08 fills. It is the NMOS specification for audio channel mapping: a standardised API for controlling how the audio channels within a received flow are routed to the physical or logical output pins of a device. ...

Building a spine-leaf ST 2110 network solves the transport problem. Signals can flow anywhere in the facility at the speed of light with predictable latency. What it does not solve is the control problem: how do operators actually route those signals, how does the system know what resources are available, and how does automation talk to the infrastructure in a consistent way regardless of which vendor made each device? That is what a media orchestration platform does. It is the software layer that sits above the network and provides a unified means of controlling everything connected to it. ...

When a broadcast facility moves to ST 2110, the network stops being background infrastructure and becomes a core part of the signal path. The choice of network topology has direct consequences for latency, redundancy, scalability, and how well PTP and multicast behave. Spine-leaf has become the dominant architecture for serious ST 2110 deployments, and understanding why - and what it asks of you in return - is worth the time. ...

Broadcast infrastructure has always been built around redundancy. Dual power supplies, redundant signal paths, failover routing - the principle is the same everywhere: no single point of failure should take a show off air. When broadcast moved to IP, the question became how to achieve the same resilience on a packet network, where the failure modes are fundamentally different from SDI. SMPTE ST 2022-7 is the answer the industry settled on. It defines a scheme called Seamless Protection Switching, and understanding it is worthwhile for any engineer working with AES67, ST 2110, or IP contribution systems at a level above basic connectivity. ...

Of all the things that can go wrong in an AoIP system, PTP problems are among the most frustrating to diagnose. The audio often still plays - just with intermittent glitches, drift, or lip sync issues that are hard to reproduce and harder to pin down. Understanding what PTP is doing, and why, makes a significant difference when you’re standing in a broadcast centre an hour before air wondering why your streams are misbehaving. ...

If you’ve spent any time working with ST 2110 or AES67 systems, you’ve almost certainly encountered SDP files. They show up everywhere - in NMOS sender manifests, in device configuration interfaces, in Wireshark captures, and in the logs of things that aren’t working the way you expected. They look deceptively simple. They’re plain text. But getting them wrong causes problems that can be frustrating to diagnose, especially when the issue is something subtle like a mismatched packet time or an incorrect clock reference. ...