Understanding the Media Exchange Layer: A shift in how broadcast software connects

The broadcast industry is working to solve a fundamental problem in software-based production: how to move video, audio and metadata between applications without the bottlenecks, latency and vendor limitations that have defined previous approaches.

The Media Exchange Layer, or MXL, represents an industry effort to address this challenge through shared memory access rather than traditional streaming protocols.

Announced in April 2025 by the Linux Foundation in collaboration with the European Broadcasting Union and the North American Broadcasters Association, the project has drawn participation from major broadcasters including the BBC, CBC/Radio-Canada, France TV and SVT, along with technology providers such as AWS, NVIDIA, Grass Valley, Intel and Lawo.

“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.

“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,” said Pebble’s CTO Miroslav Jeras. “Initiatives like MXL should enable system architects to build multi-vendor platforms in virtualized environments without the need for bespoke integration work.”

What MXL does

MXL enables applications running on the same server or connected infrastructure to share video frames, audio samples and timing data directly in memory.

This approach differs from existing methods that rely on SMPTE ST 2110 or NDI, which require packetizing media, transmitting it across a network and reconstructing it at the destination.

The advantage centers on resource efficiency.

Advertisement

Traditional streaming protocols consume significant CPU cycles for packetization and buffering, which introduces latency with each processing step. Early MXL implementations have demonstrated latencies below one millisecond per transfer, compared to approximately 20 milliseconds per device with ST 2110.

Why broadcasters pursued this approach

The initiative emerged from practical needs as broadcasters planned new facilities and workflows. CBC began developing the concept while designing its Toronto headquarters, seeking infrastructure that could adapt to different production requirements without hardware constraints.

“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,” said François Legrand, senior director engineering, CBC/Radio-Canada, in a statement on the MXL announcement. 

The BBC faced similar considerations with resources distributed across multiple UK locations. 

“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,” said Jatin Aythora, director, BBC Research & Development.

Both organizations identified vendor interoperability as a persistent obstacle. Most existing memory-sharing solutions are proprietary, limiting flexibility in system design and creating dependencies on specific technology providers.

How MXL works

The system uses ring buffers in shared memory where applications write and read media data. The MXL library provides APIs that enable zero-overhead sharing through a reader/writer model rather than a sender/receiver architecture. This eliminates the need for packetization or memory copying, preserving bandwidth and reducing CPU load.

Media is organized into flows and grains, terms borrowed from NMOS IS-04 specifications. Timing data indexes each grain relative to PTP epoch, which becomes important 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 uses UNIX file permissions to control access at both domain and flow levels. This provides security without requiring additional overhead in the data path.

The first phase of development focuses on specific uncompressed video and audio formats. This constraint was deliberate, chosen to address the most common use cases while the core technology matures. Variable framerate video and complex compression formats are not currently supported.

Current implementations also operate within single-host environments. However, technologies exist for memory exchange across wider areas. Remote Direct Memory Access, particularly RoCEv2, allows one server to access another’s memory across IP networks by bypassing the kernel and avoiding CPU overhead.

Rather than following traditional standardization processes, the project adopted an open source model.

Advertisement

Relationship to existing standards

MXL does not replace SMPTE ST 2110, which will continue to function at network boundaries and between facilities. 

The division of roles places ST 2110 at the periphery for ingest and output, while MXL handles internal media exchange within compute clusters. This allows broadcasters to maintain compatibility with existing infrastructure while gaining efficiency benefits inside software-based production environments.

In October 2025, the EBU announced a partnership with the Advanced Media Workflow Association to form the Joint Taskforce on Dynamic Media Facilities. This group will address control plane issues, including how applications discover and connect to each other, and how systems are orchestrated across distributed infrastructure.

The project timeline targets a production-ready version one release by early 2026. At the time of the April 2025 announcement, participating organizations expressed intent to integrate MXL into commercial products within that timeframe.

Implications for broadcast infrastructure

MXL addresses specific technical constraints in software-based production. By reducing the overhead associated with media exchange, it enables more functions to operate on the same hardware, decreases latency in multi-step workflows and removes dependencies on vendor-specific interconnection methods.

Migrating core media functions to MXL-based architecture offers several operational advantages. 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 associated with hardware expansion.

The vendor-agnostic nature of the open source SDK allows broadcasters to compose workflows from in-house, vendor or open-source components. MXL provides interoperability between these elements without requiring extensive pre-testing or custom integration work for each combination of tools.

Memory-layer messaging also changes troubleshooting dynamics. Traditional IP workflows require tracing packets across networks to identify where problems occur. With MXL, diagnostic information is available directly at the memory layer, providing immediate visibility into media flow health.

The architecture also positions broadcasters for technologies still under development. As AI-driven media functions, real-time analytics and edge-based processing become more common in production workflows, MXL provides 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. When compute capacity exceeds the requirements for a particular function, that function can complete its work and make results available immediately rather than waiting for real-time playback constraints.

Advertisement

This flexibility matters for organizations managing variable workloads or multiple simultaneous productions. Resources can be allocated dynamically based on actual demand rather than being dedicated to specific functions in fixed hardware configurations.

Open questions and what comes next

Several technical areas require further development, including 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, the technology must prove itself in production environments before becoming a de facto standard.

The immediate development focus remains on completing the timing model and finalizing the control layer specifications. These elements are necessary for MXL to function reliably across distributed infrastructure and multiple vendor implementations.

MXL represents a technical solution to a specific problem: inefficient media exchange between software applications.

Whether it becomes widespread infrastructure or remains a specialized tool will depend on how well it performs in production environments and whether vendors implement it consistently across their product lines. The open source approach and broad industry participation suggest the foundation is in place for either outcome.