Posts

Broadcast engineering has always had an operations dimension. Keeping a transmission chain on air, maintaining a routing system, managing the configuration of hundreds of devices across a live facility - these are operational problems that require discipline, process, and good documentation. What has changed is the nature of the infrastructure being operated. SDI routers had firmware. IP routing systems have software, APIs, configuration files, container images, and dependencies. An NMOS registry is a running process. A stream monitor is a web application. A routing automation system is a codebase. The tools that the software industry developed for managing this kind of complexity are called DevOps, and they are becoming relevant to broadcast engineering whether the industry is ready for them or not. ...

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

Broadcast IP infrastructure increasingly relies on software-defined components - NMOS registries, stream monitors, timing tools, test utilities. Getting these running on a server traditionally means installing dependencies, resolving version conflicts, and documenting the exact steps so someone can reproduce the environment six months later. Docker changes that. It packages an application and everything it needs into a single portable unit that runs the same way regardless of what is already installed on the host. ...

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

If you spend any time working with Linux-based audio systems - streaming servers, audio consoles with embedded Linux systems, remote monitoring tools, or Raspberry Pi-based devices - you will eventually need to connect to them over SSH. Getting comfortable with key-based authentication makes that process faster, more secure, and less friction than typing a password every time. This is not a deep dive into cryptography. It is a practical reference for the commands you will actually use. ...

Spine-leaf has become the dominant topology for IP media networks in broadcast facilities, outside broadcast trucks, and stadium infrastructure. It is predictable, scalable, and well-suited to the low-latency, high-bandwidth demands of uncompressed media. But a spine-leaf fabric is, by design, a closed system. The border router is what connects it to everything else. Spine-Leaf in Brief In a spine-leaf topology, every leaf switch connects to every spine switch. There are no direct connections between leaf switches, and no direct connections between spine switches. Traffic between any two endpoints always takes the same number of hops - leaf to spine to leaf - which gives you consistent, predictable latency across the fabric. ...

Anyone who manages a fleet of Comrex contribution codecs will know the problem. You have ACCESS MultiRack units in a broadcast centre, BRIC-Link devices at remote sites, ACCESS Portable NX units in the field - and keeping track of which ones are online, which are connected, and which have silently gone offline is a constant background task. Checking them individually through Switchboard is fine for one or two units. At scale it becomes friction. ...

Broadcast audio engineering has always involved a degree of systems thinking. Routing matrices, gain structures, signal flow - these are disciplines built around understanding how components interact and what happens when something changes. Software-defined workflows extend that thinking into a new domain, and with it comes a new category of things that can go wrong: a script that worked last week stops working, a configuration change breaks something, a colleague overwrites your work. ...