MXL and ST 2110 are not competing, so why does the confusion persist?

When Media Exchange Layer (MXL) entered broadcast industry conversations in earnest, it arrived alongside a question that has not gone away: is this the next step beyond SMPTE ST 2110, or something else entirely?

For many facilities evaluating software-defined infrastructure, the answer to that question carries real consequences. Misread the relationship between MXL and ST 2110, and planning assumptions, procurement timelines and integration strategies can go wrong before a single piece of hardware is ordered.

Across a recent roundtable on MXL and the Dynamic Media Facility model, the same clarification surfaced from nearly every respondent: MXL and ST 2110 are not competing technologies. They serve different functions, operate in different environments and are designed to coexist.

“MXL is not a replacement for SMPTE ST 2110 — it’s a complementary technology,” said Olivier Suard, vice president of marketing at Nevion. “Whereas SMPTE ST 2110 is a universal way to transport signals in real-time over an IP network, MXL is a way to transport signals — or more correctly, share data — in real-time between software applications or software media functions.”

That distinction is more than semantic.

ST 2110 was built to move media between physical devices across a network. MXL was built to move media between software processes running on shared compute infrastructure. The two technologies operate at different layers of a facility’s architecture and were designed to address different problems.

Where the confusion comes from

Part of the misreading is understandable. Both technologies deal with media transport. Both are associated with the broader shift toward IP-based and software-defined workflows. And both are being discussed simultaneously at a moment when the industry is actively rethinking what a broadcast facility looks like.

“Most organizations are mapping MXL onto their existing ST 2110 mental model,” said Paul Briscoe, chief architect at TAG Video Systems. “They’re treating it as another protocol layer rather than a transport architecture that removes constraints they’ve been working around for years.”

Advertisement

Briscoe said the more accurate framing is that MXL addresses what ST 2110 was never designed to handle: consistent operation across on-premises, cloud and hybrid environments, and operation without the precision timing requirements of ST 2110’s multicast UDP networks.

Russell Trafford-Jones, industry engagement manager at Techex, put it in operational terms. ST 2110 remains the right tool for moving media across a facility in real time, he said, but it adds unnecessary complexity when used for high-performance exchange between software processes on the same server.

“MXL is best understood as a parallel architecture solving a different problem, not a successor to 2110,” Trafford-Jones said. “MXL sits alongside 2110 as a process-to-process exchange layer — just a more natural fit for media moving between nearby software processes.”

A matter of where in the facility

Drew Martin, head of video product management at Riedel Communications, described the division of labor in practical terms. ST 2110 continues to serve as the standard for sending and receiving feeds and managing media distribution within and beyond the data center, he said, while MXL enables real-time communication between software applications inside it.

“As facilities continue moving toward more software-defined workflows, ST 2110 will remain central to media transport, with MXL acting as the live production fabric that supports efficient, real-time media exchange inside the data center,” Martin said.

John Mailhot, senior vice president of product management at Imagine Communications, described the relationship as one of complementary layers within the same facility. In his framing, ST 2110 handles transport between physical systems while MXL operates inside software-defined processing pools — moving media between applications rather than across network infrastructure.

“Existing SMPTE ST 2110 deployments continue to handle transport between physical systems,” Mailhot said. “As facilities implement general-purpose computing farms for software-based processing, ST 2110 delivers signals to the pool and retrieves them afterwards, while MXL operates inside the software-defined pool for application-to-application media exchange.”

Ken Smith, senior media design engineer at Diversified, offered a similar read, describing ST 2110 as “the deterministic transport framework for moving professional media across physical IP networks” and MXL as addressing the exchange of media “between software applications, containers and processing functions within compute networks.”

The cost of getting it wrong

Adam Marshall, chief product officer at Grass Valley, said the confusion matters beyond terminology. Organizations that treat MXL as a replacement for ST 2110 risk implementing it as a parallel isolated stack rather than as a complementary layer — which he said negates the efficiency gains MXL is designed to deliver.

“MXL is the right move when it lowers total system complexity and cost,” Marshall said. “But it becomes the wrong move if it is implemented as another isolated stack or treated as a simple lift and shift.”

For facility planners and engineers, the practical implication is that MXL does not require a decision about ST 2110. The two can and are expected to operate together. The question is not which one to adopt but where each belongs in the architecture.

Suard said ST 2110 is not going away, and neither is SDI in many environments.

Advertisement

“The real evolution going on is the move from dedicated hardware toward software,” he said. “SMPTE ST 2110 will continue to be relevant for a long time, just as SDI is still relevant.”

Trafford-Jones said the industry’s next challenge is not proving that MXL works, early interoperability tests and pilot deployments have moved past that question, but ensuring that the foundational understanding of what MXL is and is not gets established before it shapes larger infrastructure decisions.

“Nobody is ripping out a facility,” he said. “They are running pilots and interop demos to pressure-test latency, reliability, timing and operational fit in real production-like conditions. The pattern is simple: prove MXL behaves like a familiar live media connection, then use that confidence to open the door to software-defined architectures.”

For the organizations now evaluating where MXL fits in their technology roadmap, that framing, MXL as a layer that extends what ST 2110 already does rather than one that replaces it, is the starting point.