Table of Contents Show
Put this on the 2027 list
No, you do not need to redesign your facility around MXL this week. That is the useful starting point for anybody outside the relatively small circle currently building software-defined live-production platforms. MXL is infrastructure technology, aimed primarily at developers of media functions and the architects joining those functions into systems. So, show this to your TD.
It is, however, something worth having heard of before 2027. The reason is less about what MXL changes for an artist today and more about where software-defined media infrastructure is heading. The EBU’s Dynamic Media Facility work envisages media functions running on common compute infrastructure instead of every processing operation arriving as its own hardware island. Once multiple vendors’ software shares the same compute environment, exchanging live uncompressed media between those processes becomes a rather fundamental piece of plumbing. MXL is an attempt to make that plumbing common rather than proprietary.
MXL is not MXF
First, a small service to future meeting-room sanity: MXL is not MXF with a typo. This is how we stumbled upon MXL ourselves.
MXF is a file container that maybe will be used throughout acquisition, postproduction, mastering and delivery. (You know this already!)
MXL is not a media file format and does not add another thing for editorial to import, relink or transcode. It is an open-source software development kit for exchanging video, audio and associated data between software media functions.
The MXL repository describes it as a “shared-media exchange layer for on-premises or cloud compute”. The implementation is written in C++, exposes a C API and provides Rust bindings. The documented media payloads include V210 video, Float32 audio and ANC data.
That also defines who should care first. Pipeline developers, broadcast platform architects, systems engineers and vendors building software media functions are much closer to the immediate problem than an editor or colourist. Artists may eventually benefit from systems built around MXL without knowingly interacting with MXL itself.
The problem is between the applications
Moving broadcast production from dedicated appliances to generic compute creates an awkward question: how should application A hand live uncompressed media to application B when both are software processes, possibly running on the same server?
Traditional broadcast architectures tend to think in terms of devices and connections. Software architecture gives you processes, memory, containers and compute nodes. Treating two processes on one machine as though they were two physical SDI-era boxes separated by a network is possible, but it does not necessarily exploit the architecture of the computer they are already sharing.
MXL takes what its project FAQ calls a “compute-first” approach. Within one host, applications exchange media through shared memory. The FAQ describes a filesystem in RAM as the same-host mechanism. The SDK’s Flow API exposes shared-memory access, with the project describing zero-copy sharing or low-copy movement as architectural characteristics.
Those terms describe the data path. They should not be translated into a blanket promise of zero latency for an entire production system. Applications still have processing, buffering, bugs, dead license servers, scheduling and synchronisation behaviour of their own.
The stable bit is deliberately boring
This is where the “you do not need to worry today” comes: The current stable release on the project’s release page is MXL 1.0.2. The EBU lists that release as completed, and the project’s 1.0 line is the stable basis for production integration. Version 1.0.2 consists primarily of bug fixes, tooling improvements, documentation work and clean-ups rather than a dramatic change in the exchange model.
The stable Flow API provides the same-host shared-memory model. In practical terms, that is interesting when several media functions run on a common server and need access to the same live media without each vendor inventing a separate local hand-off. The EBU has moved beyond an isolated laboratory experiment. Its current DMF programme lists wider vendor interoperability testing and MXL in early products as completed work. That is an adoption signal, but it is not a universal product compatibility statement.
Multi-host is the part to watch
The more consequential development is what happens when those media functions no longer fit comfortably inside one host. MXL 1.1 is not yet stable. The current 1.1.0 release candidate is explicitly marked as a pre-release, while the EBU’s current programme still lists the full 1.1 release as work in progress.
The 1.1 development branch introduces mxl-fabrics, a framework for replicating flows between hosts using libfabric and accelerated networking technologies including RoCEv2 and EFA. The beta release also introduced GStreamer MXL plug-ins and a utility for inspecting ancillary-data flows. The current release candidate includes experimental partial-grain, or slice, transfer over mxl-fabrics.
ST 2110 is not being evicted
MXL also needs separating from another easy misunderstanding. It does not mean that ST 2110 suddenly becomes obsolete. The project’s own explanation contrasts its shared-memory and fabrics approach with packetised RTP-style exchange that retains more of the traditional hardware connection model. MXL is complementary to ST 2110: ST 2110 remains relevant for transporting professional media through network infrastructure, while MXL addresses software-to-software media exchange inside compute environments.
Those jobs can meet in the same facility. A live source might enter a compute environment over conventional professional IP infrastructure, pass through several software media functions using MXL internally, and later leave that environment through another network interface. The actual boundaries depend on the products involved. So this is not another format war in which one acronym is expected to eat the other. For once, there may be enough acronyms to share.
And it is not a standard
Another useful distinction for 2027 vocabulary tests: the MXL project itself explicitly says MXL is not a published standard. That matters because some secondary and vendor descriptions call it a protocol or open standard. The project’s own FAQ instead defines MXL as a publicly available open-source code project. Its implement-first philosophy uses working code and a reference implementation as the machine-readable definition of how participating software should exchange media. The source is published under the Apache License 2.0.
This code-first model reflects the stated aim of iterating faster than a conventional multi-year standards process. It also means production teams should be precise when asking vendors about support. “MXL compatible” needs to lead to questions about which release, which interfaces, which media payloads and what deployment topology the product actually implements. A logo on a slide is not a compatibility matrix.
The logos nevertheless matter
There are quite a few attached companies. The EBU lists MXL demonstrations or activities involving AWS, Appear, Cisco and Intel, Grass Valley, Matrox Video, NetOn.Live, NVIDIA, Riedel, Ross Video, Sony, TAG Video Systems, Techex and TVU Networks around NAB 2026. Its earlier IBC material included MXL-related demonstrations involving AWS, Grass Valley AMPP, NVIDIA Holoscan for Media, Sony software-defined broadcast, TVU MediaMesh, NetOn.Live LiveOS and Matrox ORIGIN.
The project’s original Technical Steering Committee also included the EBU, CBC/Radio-Canada, BBC, Grass Valley, Riedel, Lawo, NVIDIA and AWS, with the project established under the Linux Foundation and developed with involvement from NABA. That breadth is significant because an interoperability layer has a fairly obvious chicken-and-egg problem. One vendor implementing it is an interesting SDK experiment. Several competing vendors experimenting with it starts to resemble an ecosystem.
Your NLE probably does not care yet
For DIGITAL PRODUCTION readers, one useful reality check is that the MXL documentation does not present this as an artist-facing host integration. There is no published matrix saying that your NLE, compositor, 3D package or game engine has suddenly become an MXL client. The project provides an SDK and developer tooling, with examples including GStreamer pipelines, Docker Compose and Kubernetes deployment material.
That places MXL several layers below the normal creative interface. A software-defined replay engine, live graphics processor, monitoring application or processing service could use MXL underneath its own controls. An operator might continue using the vendor’s familiar interface while the media exchanged between backend services has changed completely. This is one reason the technology could become important without becoming visible. Storage APIs, container orchestration and network fabrics already influence what production applications can do without becoming colour-page controls. Media exchange can follow the same pattern.
Why post should still keep one eye open
MXL originates in live production, but the distinction between live infrastructure and post infrastructure is becoming less tidy.
Facilities increasingly combine ingest, live graphics, replay, automated processing, review, transcoding, remote operations and cloud services. Stuff that would have been separate departments in earlier days…. The MXL project is asynchronous by design, and its own architecture discussion explicitly includes the possibility of faster-than-live processing. That does not mean MXL itself supplies rendering, AI processing, transcoding or editorial functions. It provides a mechanism through which media functions implementing those jobs can exchange media.
For a post house, VFX facility or virtual-production team, that makes MXL potentially relevant where creative applications meet live or near-live software infrastructure. It could influence the architecture underneath review systems, live graphics pipelines, software-defined ingest or hybrid processing, even if traditional shot work continues to move through familiar files, caches and scene descriptions.
MXL has reached the point where ignoring it completely is less useful than spending ten minutes understanding what problem it is trying to solve. At the same time, the current state of the project does not justify presenting it as a compulsory technology like XML, Coffee or Python.
https://tech.ebu.ch/dmf/mxl
https://github.com/dmf-mxl/mxl
https://techex.tv/mxl
https://nevion.com/lexicon/media-exchange-layer-mxl/
https://github.com/dmf-mxl/mxl/releases/
https://github.com/dmf-mxl/mxl/wiki/Frequently-Asked-Questions
https://tech.ebu.ch/groups/dynamic-media-facility
https://tech.ebu.ch/news/2026/ready-for-production-media-exchange-layer-v1-0-0-published
https://tech.ebu.ch/news/2025/06/ebu-launches-open-source-mxl-sdk-for-software-based-media-exchange
| Product | Media eXchange Layer (MXL) |
| Ecosystem | EBU Dynamic Media Facility |
| Project governance | Open-source project established under the Linux Foundation, with EBU, NABA, broadcasters and technology vendors contributing |
| Stable release | MXL 1.0.2 |
| Development release | MXL 1.1.0-rc1, pre-release |
| Implementation | C++ SDK, C API, Rust bindings |
| Documented payloads | V210 video, Float32 audio, ANC data |
| Stable exchange model | Same-host shared-memory access through the Flow API |
| Emerging exchange model | mxl-fabrics inter-host work in the 1.1 pre-release line, including libfabric with RoCEv2 and EFA |
| Licence | Apache License 2.0 |
| Documentation | MXL repository |
