By Andrew Starks, Director of Product Marketing

When most people hear “broadcast,” they think of world-class production: multi-camera live events, national news, championship sports, and studios where reliability, precision, and quality are non-negotiable. This is the world where SMPTE ST 2110 thrives. It gives broadcasters a deterministic, uncompressed, low-latency transport with per-stream control and tight timing that supports mission-critical workflows. In the major hubs of broadcast operations around the world, ST 2110 is working exactly as it was designed to.

The reality inside broadcast organizations today is broader than that elite core. Beyond the flagship studios and remote production trucks are smaller facilities across the country and the globe: local news bureaus, regional studios, field production units, even mobile OB operations. These environments often don’t justify the cost, engineering overhead, or operational discipline that come with full ST 2110 deployments. Instead, they default to more accessible technologies, such as NDI, for local production and SDI for simple point-to-point feeds. However, neither speaks the same control plane language that ST 2110 uses, and both require gateways and converters when they have to integrate with core broadcast infrastructure.

In conversations with network engineers from very large public broadcasters, the disconnect was framed very directly. Their core ST 2110 facilities are working well. The engineering discipline is there, the systems are designed correctly, and the teams know how to operate them.

Once you step outside those flagship environments, the story changes. Regional studios, smaller bureaus, temporary production spaces, and event-driven workflows are often built on NDI or traditional SDI because they are easier to operate. Those systems do not share the same NMOS control plane as ST 2110 and they do not use the same transport As a result, every connection back into the main facility requires gateways, translation, and operational complexity.

This is where IPMX enters the conversation. IPMX was originally developed for Pro AV, where ease of deployment, interoperability, and flexibility were critical. What is becoming clear now is that those same characteristics are highly relevant inside broadcast organizations as well.

IPMX builds on the same media foundations as ST 2110 and AES67, but it was designed to be practical outside highly engineered facilities. Unlike NDI or SDI islands, IPMX requires NMOS for discovery, registration, and connection management, while tightening down NMOS behavior and interoperability requirements so that multi-vendor systems behave more predictably. That consistency is attractive to broadcasters who already rely on NMOS in their core plants and would prefer not to maintain entirely separate operational models elsewhere.

For these broadcasters, the appeal is that IPMX lets them extend a compatible, standards-based IP architecture into places where ST 2110 is too heavy and NDI or SDI are too disconnected. IPMX creates infrastructure that is much closer to the ST 2110 ecosystem, without demanding the same level of engineering overhead.

One of the biggest practical differences between ST 2110 and IPMX is flexibility around timing. ST 2110 depends on a well-designed PTP timing domain to get precise sync across multiple media streams; that works in a purpose-built studio because there you typically have grandmaster clocks and network gear that fully support PTP. In regional facilities or event-driven setups, deploying and maintaining PTP domains can be costly and operationally heavy. It means switches that support boundary or transparent clocks, careful monitoring, and disciplined housekeeping. For smaller budgets and ad hoc deployments, that complexity is a real barrier. IPMX recognizes that reality by supporting both PTP-based sync when appropriate and asynchronous operation when PTP isn’t available or necessary. In those cases you still get interoperable media transport and control, without the engineering overhead that a PTP domain demands.

IPMX also aligns with the open standards ecosystem that broadcasters have already invested in. It uses ST 2110 and AES67 for media transport, and NMOS for discovery, registration, and connection management. One of the practical differences is that IPMX tightens down NMOS behavior, which makes multi-vendor systems more predictable out of the box.

It also incorporates specifications such as IS-11, which provides a mechanism for stream compatibility management. IS-11 was originally designed around capabilities metadata, including EDID-driven constraints and sender/receiver format negotiation. In live production workflows, that same mechanism becomes a useful way to set and enforce “house” constraints across endpoints, reducing the amount of manual coordination that is common in traditional ST 2110 and NMOS deployments.

For compressed media, JPEG-XS is widely available and well supported inside IPMX profiles, giving broadcasters a pragmatic option when bandwidth or physical network capacity limits move workflows away from uncompressed transport. That makes IPMX useful not just in small studios and headends, but also for temporary event feeds or remote coverage where a 25GbE ST 2110 build-out isn’t viable.

Taken together, this is less about adding a checklist of features and more about lowering the friction of deploying interoperable IP media networks outside of flagship broadcast plants. It gives broadcasters a way to extend standards-based infrastructure into the wide range of facilities and events they support without treating the rest of the world as either a proprietary island or a conversion problem.

At Macnica, we are focused on turning this architectural shift into something practical. The ME10 SoC was built to support both ST 2110 and IPMX workflows, including asynchronous operation, PTP-based deployments, and the relevant IPMX media profiles. On top of that, the M2S SDK provides a production-ready media and control stack so manufacturers do not have to assemble NMOS, stream management, and timing behavior from scratch.

The goal is straightforward. If a company wants to build an IPMX endpoint, gateway, or embedded module that interoperates cleanly in both broadcast and Pro AV environments, they should be able to do so without spending years solving infrastructure problems that the industry has already agreed on - that is the layer we are investing in.

If you are a manufacturer, software developer, broadcast engineer, or systems architect curious about how IPMX can fit into your strategy, whether you are modernizing remote facilities or building new IP media infrastructure, we would welcome the chance to talk about what we are seeing in the field and how these open standards can move more of your operations onto a common, interoperable foundation.