AES67

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. ...

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. ...