The broadcast industry is actively seeking solutions to a core challenge in software-defined production: streamlining the transfer of video, audio, and metadata between different applications. The goal is to eliminate bottlenecks, minimize latency, and overcome vendor limitations that have traditionally plagued these processes. The Media Exchange Layer, better known as MXL, is an industry initiative designed to tackle this issue head-on, utilizing shared memory access rather than conventional streaming protocols.
Launched in April 2025 by the Linux Foundation, in partnership with the European Broadcasting Union (EBU) and the North American Broadcasters Association (NABA), the project has garnered support from prominent broadcasters such as the BBC, CBC/Radio-Canada, France TV, and SVT. Technology providers including AWS, NVIDIA, Grass Valley, Intel, and Lawo are also participating.
“The promise of MXL is that users will be able to avoid vendor lock-in on generic servers where processing apps from different vendors not only run side by side, but also exchange data via a so-called shared memory layer, to avoid latency issues,” said Chris Scheck, head of marketing content at Lawo.
Miroslav Jeras, CTO at Pebble, added, “There has been a brake on the adoption of wider software infrastructures and the adoption of the cloud: the lack of open standards for interoperability. Initiatives like MXL should enable system architects to build multi-vendor platforms in virtualized environments without the need for bespoke integration work.”
MXL enables applications running on the same server or connected infrastructure to share video frames, audio samples, and timing data directly in memory. This contrasts with existing methods like SMPTE ST 2110 or NDI, which involve packetizing media, transmitting it across a network, and reconstructing it at the destination. The key advantage lies in resource efficiency. Traditional streaming protocols require significant CPU resources for packetization and buffering, leading to latency at each processing stage. Early MXL implementations have demonstrated latencies below one millisecond per transfer, compared to approximately 20 milliseconds per device with ST 2110.
The initiative stemmed from practical needs identified by broadcasters planning new facilities and workflows. CBC, for instance, began developing the concept while designing its Toronto headquarters, aiming for infrastructure that could adapt to diverse production needs without hardware limitations.
François Legrand, senior director engineering, CBC/Radio-Canada, stated in the MXL announcement: “Software-driven broadcast production is the future, and real-time media exchange is a critical piece of this evolution. The MXL Project is a pivotal step toward an open, interoperable ecosystem that allows broadcasters to maximize efficiency while reducing infrastructure complexity. We expect that starting with software rather than writing a document will significantly speed up the process of developing the solution.”
The BBC encountered similar challenges with resources spread across multiple UK locations. Jatin Aythora, director, BBC Research & Development, noted, “As broadcasters move their live production and media operations onto software-based infrastructure inspired by cloud architectures, the concepts of EBU’s Dynamic Media Facility initiative will provide the scalability, flexibility and efficiency needed to support future needs.”
Both organizations recognized vendor interoperability as a persistent hurdle. Most existing memory-sharing solutions are proprietary, which restricts system design flexibility and creates reliance on specific technology vendors. The system employs ring buffers in shared memory where applications write and read media data. The MXL library offers APIs that facilitate zero-overhead sharing through a reader/writer model, rather than a sender/receiver architecture. This eliminates the need for packetization or memory copying, saving bandwidth and reducing CPU load. Media is organized into flows and grains, terms derived from NMOS IS-04 specifications. Timing data indexes each grain relative to the PTP epoch, which is crucial when systems span multiple hosts. Cloud providers offer time synchronization services that MXL can use to maintain alignment across distributed infrastructure.
The technical implementation also utilizes UNIX file permissions to control access at both domain and flow levels, ensuring security without adding overhead to the data path. The initial development phase concentrates on specific uncompressed video and audio formats, a deliberate choice to address common use cases while the core technology matures. Variable framerate video and complex compression formats are not currently supported. Current implementations operate within single-host environments, but technologies like Remote Direct Memory Access (RDMA), particularly RoCEv2, enable memory exchange across wider areas by allowing servers to access each other’s memory across IP networks, bypassing the kernel and avoiding CPU overhead.
Instead of traditional standardization processes, the project adopted an open source model. MXL does not replace SMPTE ST 2110, which will continue to be used at network boundaries and between facilities. This division of roles places ST 2110 at the periphery for ingest and output, while MXL handles internal media exchange within compute clusters, allowing broadcasters to maintain compatibility with existing infrastructure while improving efficiency within software-based production environments.
In October 2025, the EBU announced a partnership with the Advanced Media Workflow Association to create the Joint Taskforce on Dynamic Media Facilities. This group will address control plane issues, including application discovery and connection, and system orchestration across distributed infrastructure. The project aims for a production-ready version one release by early 2026, with participating organizations planning to integrate MXL into commercial products within that timeframe.
By reducing media exchange overhead, MXL allows more functions to run on the same hardware, reduces latency in multi-step workflows, and eliminates vendor-specific interconnection dependencies. Migrating core media functions to MXL-based architecture offers operational benefits. With containers replacing fixed-function hardware, production environments become easier to scale across on-premises servers or cloud infrastructure. This soft provisioning replaces the capital expenditure model of hardware expansion. The vendor-agnostic nature of the open source SDK allows broadcasters to create workflows from in-house, vendor, or open-source components. MXL ensures interoperability between these elements without extensive pre-testing or custom integration work for each tool combination.
Memory-layer messaging also simplifies troubleshooting. Traditional IP workflows require tracing packets across networks to pinpoint problems. With MXL, diagnostic information is immediately available at the memory layer, providing clear visibility into media flow health. The architecture also prepares broadcasters for emerging technologies like AI-driven media functions, real-time analytics, and edge-based processing by providing a foundation for integrating these capabilities in a modular, composable manner. The technology also enables asynchronous workflows where processing can occur faster than real time, allowing functions to complete and make results available immediately when compute capacity exceeds real-time playback constraints. This benefits organizations managing variable workloads or multiple simultaneous productions, allowing dynamic resource allocation based on demand rather than fixed hardware configurations.
Further development is needed in areas such as audio grain sizing, the control layer for application discovery and connection establishment, and orchestration systems for managing MXL-based workflows across complex infrastructure. The project also faces the practical challenge of industry adoption. While major broadcasters and vendors have committed to MXL, its success depends on proving itself in production environments before becoming a standard. The immediate focus remains on completing the timing model and finalizing the control layer specifications, which are essential for MXL to function reliably across distributed infrastructure and multiple vendor implementations.
MXL is a technical solution addressing inefficient media exchange between software applications. Its widespread adoption will depend on its performance in production environments and consistent vendor implementation. The open-source approach and broad industry participation suggest a solid foundation for either outcome.