The State of MXL, One Year After Launch

Why this question is suddenly everywhere

IBC2026 opens in Amsterdam this week, and the Media eXchange Layer is on more stands than almost any other topic in the show’s technology halls. AWS, Grass Valley, NVIDIA, Riedel, TVU Networks, Techex, and other vendors are running MXL demonstrations. A Joint Taskforce between the EBU and AMWA is holding dedicated sessions on the Dynamic Media Facility. Qvest is presenting what it describes as the industry’s largest multi-vendor DMF showcase to date.

That is a lot of momentum for a short timeline. MXL only became a formal Linux Foundation project in April 2025, and its first alpha SDK shipped about two months after that. That is not a long runway for a broadcast standard to travel from concept to trade-show centrepiece, and the pace has produced two very different reactions. One camp treats MXL as close to inevitable: an open, vendor-neutral foundation that could eventually do for software-defined production what SDI did for a previous generation. The other camp, having just finished, or still being in the middle of, an expensive ST 2110 migration, is asking a more grounded question: does this actually work yet, and does it make the last upgrade obsolete?

Both questions deserve a straight answer.

What MXL actually does

MXL is the media exchange layer inside the EBU’s Dynamic Media Facility (DMF) reference architecture. DMF describes a full stack for software-defined broadcast: generic compute and storage at the bottom, a media exchange layer above that, and vendor-specific media functions and control applications on top. MXL is the open-source implementation of that middle layer, developed as a Linux Foundation project with contributors including the EBU, CBC/Radio-Canada, the BBC, Grass Valley, Riedel, Lawo, AWS, NVIDIA, Intel, and Matrox.

The problem MXL solves is specific. In a software-defined facility, broadcast functions run as containerised microservices, potentially dozens of them, on commodity IT infrastructure. If each microservice exchanges video the way applications have historically exchanged video across a network (packetising it, transmitting it, unpacketising it on arrival), every hop between functions on the same server costs CPU cycles and adds latency, even though the data never needed to leave the machine in the first place.

MXL’s answer is to skip that network stack entirely for the internal case. Media functions on the same host, or on hosts connected by a fast enough fabric, share memory directly. One application writes a frame into a shared ring buffer once; any other application that needs it reads it from that same location. There is no packetisation, no duplication, and, on a single host, no network transit at all. AWS put it plainly in its April 2026 post on the MXL ecosystem: “the frame doesn’t move; the applications come to it.”

Technically, MXL organises media into Flows and Grains, concepts borrowed directly from the NMOS IS-04 data model, and indexes timing to the PTP epoch so that grains arriving through different paths can still be aligned. It uses a reader/writer model rather than a sender/receiver model, which supports both synchronous and asynchronous consumption of the same data. That asynchronous property is what enables so-called “faster than live” processing, where a function capable of running faster than real time no longer has to wait for a live feed to catch up to it. Early implementations reported by NewscastStudio in December 2025 showed sub-millisecond transfer latency for shared-memory exchange, against roughly 20 milliseconds per device hop under a conventional ST 2110 pipeline, though those figures describe specific lab conditions rather than a general production benchmark.

What MXL deliberately leaves out matters just as much. It does not define orchestration, workflow control, or business logic; those responsibilities stay with higher-level frameworks, whether a vendor’s own platform, Kubernetes-native tooling, AMWA NMOS, or a broadcaster’s own control plane. And today it does not define media movement across a wide area network. The current specification is built around a single host or a tightly coupled compute cluster connected by RDMA-class fabrics, not general-purpose networking. Extending shared memory exchange across sites is active work rather than a solved problem: BBC R&D has been testing RDMA over OpenStack in Salford and London, describing the early results as “promising” in a May 2026 update.

How mature is MXL, actually? A timeline

• November 2024: A six-vendor “Tiger Team” (Matrox, Grass Valley, Lawo, Riedel, Intel, and NVIDIA) is convened by the EBU after IBC 2024 to define the media exchange problem.

• April 2025: The work is formalized as a Linux Foundation project.

• June 2025: The first alpha SDK is released.

• December 2025: A public 1.0 SDK release follows, with a Rust implementation and early integrations with frameworks such as GStreamer arriving in the months after.

• January 2026: SVG Europe’s survey of the vendor ecosystem finds that no major broadcast vendor is yet shipping a fully MXL-native commercial product. What exists falls into three categories: lab prototypes shown at trade shows, hybrid implementations where vendors use MXL internally while still exposing conventional interfaces externally, and infrastructure alignment work by compute and networking vendors preparing for NUMA-aware memory sharing and RDMA support.

• March 2026: The EBU’s Technical Steering Committee publishes the MXL specification and reference implementation version 1.0.0, moving it from Release Candidate to a stable, production-use designation.

• April 2026: At NAB Show, more than a dozen companies demonstrate MXL in some form, mostly containerised media functions interoperating across multiple hosts. AWS publishes a widely discussed post arguing MXL is “the foundation” for software-defined live production, but that three more pieces (wide-area connectivity, plug-and-play device discovery, and content authenticity) still need to be built around it.

• August 2026: Two contrasting pieces of coverage appear within weeks of each other. One reports that broadcasters are resisting rapid MXL adoption given how recently, and expensively, many completed ST 2110 migrations, with vendors including Imagine Communications and Riedel shifting their messaging from “replacement” to “additive integration.” The other, an SVG Europe op-ed from Netgear Enterprise’s Richard Jonker, warns that the industry is “building the top floor before the foundation is set,” arguing that momentum and readiness are being conflated and that deterministic timing, RDMA-capable networking, and security still need to be solved at the infrastructure layer.

• September 2026: IBC2026 opens with MXL and DMF demonstrations across the show floor, a dedicated EBU/AMWA Joint Taskforce session, and multi-vendor interoperability showcases from suppliers including Techex and Qvest.

Read as a whole, that timeline supports a specific answer rather than a simple yes or no.

Is MXL production-ready today?

The specification is. As of March 2026, MXL 1.0.0 is a finished, EBU-endorsed document with a working open-source reference implementation. Vendors building to it are building to a fixed target, which is a large part of why activity has accelerated through 2026.

The commercial ecosystem is not, at least not broadly. The most detailed industry survey available, from January 2026, describes MXL deployments in three buckets: prototypes and interoperability demos, internal hybrid use inside existing platforms, and preparatory infrastructure work. Coverage through August 2026 echoes the same picture rather than contradicting it. Vendor roadmaps described in that reporting point to partial commercialisation through the rest of 2026, with MXL-compatible interfaces appearing alongside existing ST 2110 and SRT workflows, and full multi-vendor MXL production clusters more realistically arriving in 2027 and beyond. If a vendor tells you their product is MXL-native today, the fair follow-up question is which of those three buckets that claim actually describes.

Your infrastructure’s readiness is a separate question from the specification’s readiness. The August 2026 SVG Europe critique makes a point worth taking seriously regardless of where you land on MXL generally: a shared-memory exchange layer only performs as advertised if the layers underneath it, including NUMA-aware memory allocation, RDMA-capable networking, reliable PTP distribution, and a security model designed in from the start rather than added later, are already solid. Broadcasters who moved to ST 2110 already learned this lesson once. MXL does not remove the requirement. It adds to it.

Adoption appetite is genuinely mixed. Reporting from August 2026 describes broadcasters who completed large ST 2110 migrations in the past few years as reluctant to treat MXL as an urgent next step, particularly while vendors are still working out how to position it as additive rather than as a verdict on infrastructure that was expensive to build the first time.

Taken together: MXL is production-ready as a specification and genuinely promising as a direction. It is not yet a production-ready commercial ecosystem that a broadcast engineering team can drop into a live facility end to end. Expect that gap to close through 2026 and 2027, unevenly and function by function, rather than all at once.

Does MXL replace ST 2110?

No, and this is where a lot of conference-hallway conversation gets ahead of the actual architecture.

ST 2110 and MXL solve different problems at different layers. ST 2110 is a real-time IP transport standard: it moves essence across a network, between devices, between rooms, and between facilities, using IP switches, multicast, and PTP timing. MXL is a media exchange mechanism for software applications already running on the same compute, whether that is one server or a tightly coupled RDMA-connected cluster. It was never designed to replace network transport, and the sources closest to the specification say so directly. Nevion’s technical glossary puts it plainly: “No, MXL complements ST 2110. It is designed for efficient intra-system media exchange between software applications, while ST 2110 remains relevant for IP transport across network infrastructure.”

The clearest way to see the boundary is to trace where each one operates in a real workflow. ST 2110, JPEG XS-compressed contribution, or SRT still carries video from the venue to the facility and between facilities. Once that video lands inside a software-defined processing cluster, MXL can take over moving it efficiently between the microservices that touch it there: a switcher, a graphics engine, a replay function, a multiviewer. When processing finishes, a transport protocol picks the signal back up to move it onward. MXL sits inside the boundary that ST 2110 defines; it does not dissolve that boundary.

It is also worth being precise about what MXL does not touch. It is not designed for ground-to-cloud transport, which remains the job of SRT and RIST exactly as it is today. That matters directly for contribution workflows: an MXL rollout inside a broadcaster’s processing environment has no bearing on how that broadcaster gets a signal from a stadium into that environment in the first place.

None of this makes the broader DMF vision modest. AWS has floated the comparison that MXL “has the potential to become what SDI was for a previous generation,” a universal layer every vendor implements. That may prove directionally right over a long enough horizon, but it describes what the full stack around MXL could become once wide-area connectivity, device discovery, and orchestration are built on top of it, not what the exchange layer replaces today. Even that same source frames it as a multi-year, ecosystem-dependent outcome. The August 2026 SVG Europe rebuttal is worth keeping close by: momentum toward that future is not evidence the future has arrived.

What this means for your infrastructure roadmap

Do not treat this as a reason to delay planned ST 2110 or SRT investments. Nothing about MXL’s current state changes the transport requirements for contribution or facility-to-facility distribution. Make those decisions on their own merits.

Do not treat “MXL-compliant” as a single, verifiable claim. Given where the ecosystem actually sits, a vendor’s MXL claim could describe anything from a controlled lab demo to genuine use inside a shipping platform. In procurement conversations, ask specifically which of the three adoption categories, lab prototype, internal hybrid use, or an externally exposed MXL interface, the claim refers to, and ask to see it running outside a trade-show booth.

If you want to experiment, start with a contained, single-function workflow. Replay, multiviewing, clipping, and graphics overlay are the use cases showing up repeatedly in early demonstrations because they are self-contained enough to test without redesigning an entire facility around them. That is consistent with how EBU-aligned broadcasters, including the BBC and CBC, are approaching their own pilot work.

Audit the foundation before you audit the application layer. Before any MXL pilot, confirm the infrastructure prerequisites the August 2026 SVG Europe piece raises: NUMA-aware memory allocation, RDMA-capable networking, dependable PTP distribution, and a security model for the control and management planes designed in from the start. A shared-memory exchange layer inherits every weakness in the infrastructure underneath it.

Where Appear stands

Appear has been part of the MXL conversation since 2025. At IBC2025, Appear’s CTO, Andy Rayner, said that “our VX platform is built for this world from day one, and all our software solutions will be MXL-compliant.” SVG Europe’s survey of the DMF vendor ecosystem lists Appear among the suppliers “integrating MXL architectural principles” into their platforms, alongside Grass Valley, Matrox, Lawo, and Riedel. Appear’s VP of Technology & Innovation, Ian Wagdin, has also walked through the architecture with trade press, including an SVG Europe interview on how DMF and MXL enable software-defined video, and wrote Appear’s own explainer, “Why Media Exchange is the missing link in software-defined live production,” which covers the underlying mechanics in more depth than this piece does.

None of that changes Appear’s position on contribution. As set out in Hybrid isn’t the future. It’s broadcast’s operating model, Appear treats MXL and DMF as emerging standards that will increase workload portability as they mature, weighed against the same three variables as any other infrastructure decision: performance, cost and adaptability. X Platform’s hardware-accelerated SRT and ST 2110 support continue doing the job MXL was never designed to do, which is getting a deterministic, low-latency signal from venue to facility in the first place. MXL’s relevance begins after that signal has landed, in the software-defined processing layer where VX operates. Building toward an open standard as it matures, rather than committing a facility to it before the ecosystem is ready, is the more defensible position for most broadcast engineering teams right now — not only for Appear.

Common questions

Will adopting MXL make my recent ST 2110 investment obsolete?
No. ST 2110 and MXL operate at different layers, and MXL was designed to work alongside ST 2110 at the periphery of a software-defined facility, not to replace it. Broadcasters who have already completed an ST 2110 migration are not starting over.

Does MXL affect SRT-based contribution?
No. MXL is scoped to media exchange between software applications on the same host or compute cluster. It is not designed for ground-to-cloud or facility-to-facility transport, which remains SRT and RIST territory.

When will MXL be ready for full production use across a facility?
The specification reached a stable, production-use designation in March 2026. The commercial ecosystem is expected to reach partial commercialisation through the rest of 2026, with broader multi-vendor production deployment more realistically arriving in 2027 and beyond, based on the roadmaps vendors have described publicly.

What should I ask a vendor who claims their product is MXL-compliant?
Ask whether the claim describes a lab prototype, an internal implementation not exposed to customers, or a genuinely externally accessible MXL interface, and ask to see it running outside a trade-show demo.

The bottom line

MXL’s specification is production-ready. Its commercial ecosystem is not, not broadly, not yet. And it is not replacing ST 2110, because it was never designed to do ST 2110’s job. The realistic path for the next one to two years is a hybrid one: ST 2110 and SRT continue carrying video into and between facilities, and MXL gradually takes over efficiency-critical exchange between software functions inside the processing layer, function by function, as the ecosystem catches up to the specification that now exists.