ST 2110 replaced SDI. MXL is built to complete the transition

The hard part is supposed to be behind you. Your facility made the move to IP. You learned PTP. You survived the first few multicast nightmares. You built something that works.

For engineers, it works, until you try to run it in the cloud. Or onboard a new software tool that wasn’t designed for 8,000 packets per frame. Or explain to your IT team why broadcast timing requirements are fundamentally incompatible with the network infrastructure that runs everything else in your organisation.

For executives, the gap looks different. The move to IP was supposed to deliver cloud-native economics, software-defined flexibility, and a real shift from capex to opex. Instead, most facilities are still running dedicated broadcast engineering teams to manage infrastructure complexity that IT can’t touch. The promise of IP was operational freedom. What most facilities got was IP with an asterisk.

ST 2110 is production-ready. That’s not the debate anymore. But production-ready and friction-free are two different things, and the friction is where broadcast operations are losing time, money, and engineering headcount in 2026.

ST 2110 is reliable. The complexity is the problem.

SMPTE ST 2110 was designed to replicate the precision of SDI over IP networks. It does that well. But that precision comes at a cost: nanosecond-level timing requirements, PTP synchronisation that needs constant monitoring, and a packet density that makes software integration genuinely hard.

For large facilities with dedicated broadcast engineering teams, that complexity is manageable. But the industry isn’t standing still. The pressure to run hybrid on-premise/cloud workflows, integrate software-defined tools, and reduce reliance on specialised infrastructure is coming from every direction: commercial, operational, and competitive.

ST 2110 wasn’t built for that world. It was built for the world we were moving into when SDI was still the alternative.

What comes next: MXL and the software-native production environment.

In early 2026, the Linux Foundation, in collaboration with the EBU and NABA, published the MXL v1.0.0 Release Candidate, freezing the API and giving vendors a stable base to begin building commercial implementations. MXL is part of the EBU’s Dynamic Media Facility (DMF) initiative, and it’s designed to address the gap that ST 2110 was never built to close. Where ST 2110 is optimised for precision transport over managed IP networks, MXL is designed for software-native production environments: distributed compute, containerised workloads, and cloud-based operations where synchronous SDI-style timing models simply don’t apply.

The architectural intent is significant. Rather than managing thousands of packets per frame with nanosecond-precision timing requirements, MXL is designed to treat media transfer as memory-to-memory operations, the same model used by modern software and cloud platforms. If that promise holds through interoperability testing and commercial adoption, the implications are considerable:

• Cloud-native workflows without format conversion. ST 2110 and cloud infrastructure don’t naturally speak the same language. MXL is designed to work across any IP network, on-premise, cloud, or hybrid, without protocol conversion, meaning the same workflow could run anywhere.
• Broader software integration. ST 2110’s timing requirements create a real barrier for software developers. MXL’s open-source, API-stable design is intended to make media accessible in the same way any other data is accessible over IP. This could significantly expand the ecosystem of tools that integrate with broadcast infrastructure.
• Reduced operational overhead. PTP synchronisation is one of the most common sources of subtle, hard-to-diagnose issues in ST 2110 environments. MXL’s memory-to-memory model is designed to eliminate PTP as a dependency, reducing both the complexity burden on engineering teams and the failure surface it creates.
• A long-standing interoperability gap, addressed. MXL is explicitly designed to fill the gap between media applications in software-defined environments — something the industry has needed since the shift to IP began.

The right ST 2110 question for 2026.

MXL is designed to complement ST 2110, not replace it. The two are intended to coexist, ST 2110 handling the precision transport workflows it was built for, MXL handling the software-defined and cloud-based layers where ST 2110’s model creates friction.

Interoperability testing is underway and commercial implementations are on the horizon. The broadcast organisations that will be best positioned aren’t necessarily the ones moving fastest. My advice? Start understanding where MXL fits into your infrastructure roadmap before the first commercial products land.

Want to understand how MXL fits into the future of your production infrastructure? Download our white paper for a deeper look at what Media Exchange Layer is designed to deliver, and what it means for the next phase of broadcast IP.

Download the MXL White Paper → https://tagvs.com/guides-and-whitepapers/mxl-dmf-white-paper/