MXL in 2026: what the marketing says, where reality stands, and what comes next

If you walked the halls at NAB or IBC this year, you could not miss it: MXL, the Media eXchange Layer. It was recognised in this year’s IBC Innovation Awards. Vendors call it the missing piece of the software-defined facility.

I think MXL matters. But the gap between the stand graphics and what you can put on air today is real, and if you are planning an infrastructure renewal in the next two to three years, you need to see both clearly.

So let’s split it in three: what the marketing says, where reality stands, and what the future looks like.

What the marketing says

The pitch is simple and attractive. MXL is described as the SDI of software: one common way for software functions from different vendors to hand media to each other, so you can build a production chain from best-of-breed apps instead of one vendor’s closed platform.

The claims you will hear most:

No more lock-in. An open-source project under the Linux Foundation, driven by the EBU and NABA, so no single vendor owns the interface.
Lower latency and less overhead. Media is shared through memory instead of being packetised, sent and unpacked again between every step. Vendors quote sub-millisecond hand-offs.
Deploy anywhere. The same software functions on-premise, in a private cloud or in a public cloud.
Production-ready. Version 1.0.0 was published in March 2026, and a growing list of vendors show “MXL support”.

None of this is false. But each claim comes with a condition that rarely makes it onto the stand.

Where reality stands

The core is solid, and it is narrow. MXL 1.0 does one thing well: it lets software functions on the same server exchange uncompressed video (V210), audio (32-bit float) and ancillary data through shared memory, with every frame timestamped against PTP. Inside one host, that is fast, efficient and genuinely open. That is a real achievement in about 15 months of work.

Beyond one server, it is still maturing. Exchanging media between hosts relies on RDMA-class networking, and that part is less mature: early tests are promising, but nobody should present it as a finished, field-proven layer yet. MXL is also not designed for wide-area or contribution links. SRT, RIST and ST 2110 keep doing that job.

MXL is the cabling, not the facility. It does not define how functions are discovered, connected, controlled, scheduled or secured. Those pieces sit in other layers: NMOS-based tooling, Kubernetes, or a vendor’s own platform. The EBU and AMWA set up a joint task force (JT-DMF) precisely because timing models and orchestration still need work. Several vendors say the same thing in their own words: the limits today are less in MXL itself than in everything around it.

“Supports MXL” can mean three different things. A lab prototype, an internal use where the vendor exchanges media between its own components but still exposes classic interfaces to you, or a real, externally accessible MXL interface that another vendor’s app can connect to. At the start of 2026 an industry survey found no major broadcast vendor shipping a fully MXL-native commercial product. By IBC that picture had moved, with native integrations and multi-vendor demos on several stands, but most of what you see is still the first two categories.

Demos are static; production is not. Many demos use fixed connections between a handful of functions: a replay, a multiviewer, a graphics overlay. The real promise of a dynamic facility is spinning functions up and down and re-routing them during a live show. That part is largely not demonstrated yet.

And the timing is awkward for buyers. Many broadcasters have only just finished, or are still paying for, their move to ST 2110. Understandably, appetite to rebuild again is low. You can see vendors adjusting: the message has shifted from “replace” to “add”.

What the future looks like

Here I am fairly confident about the direction, and deliberately cautious about the dates.

Hybrid for the next two years. ST 2110 (and SDI at the edges) keeps carrying signals into and between facilities. MXL takes over inside the compute layer, one function at a time. MXL does not replace ST 2110; they answer different questions.

Same-host first, clusters later. The sensible first deployments run several functions on one powerful server: a contained workflow with no RDMA in sight. Multi-server clusters follow once inter-host exchange and orchestration have proven themselves. Vendor roadmaps point to partial commercialisation now and full multi-vendor production clusters from 2027 onwards.

The format will widen. Version 1 is uncompressed only. Compressed formats and variable frame rates are on the roadmap, which matters for anyone working with constrained compute or cloud egress costs.

The real battle moves up a layer. Once MXL is the common plumbing, the difference between solutions will be in orchestration, control, monitoring and security. That is where lock-in can quietly return, so that is where buyers should keep asking questions.

What I would do with this today

Don’t make MXL a hard requirement in a tender for the next 12 months, but do make it a scored, roadmap requirement. Ask for a date and a reference, not a promise.
Ask every vendor which of the three “supports MXL” categories they mean, and ask to see it working outside a trade-show demo.
Design the compute layer to be MXL-ready: current server platforms, enough memory bandwidth, and an RDMA-capable network where you plan clusters. That costs little extra now and avoids a second renewal later.
Protect your ST 2110 investment. Plan MXL as an addition inside the processing layer, not as a reason to rip out what works.
Start with one contained workflow (a replay chain, a graphics or multiviewer cluster) and learn from it before you scale.

In short

MXL is the most promising step towards truly interoperable software production I have seen, and the 1.0 core is real. But today it is a fast, open connection between software on one server, not yet the dynamic, multi-vendor facility on the brochure. Plan for it, design for it, test it on something small, and let the ecosystem around it mature before you bet a facility on it.

Planning an infrastructure renewal and wondering where MXL fits? I’m happy to think it through with you.

Further reading