All 9 articles in this series are now available in our free eBook ‘Cloud Compute Infrastructure – The Book 2026’ – download it HERE.

All articles are also available individually:

MXL is the foundation layer in the DMF reference architecture and is therefore an important component. An earlier Broadcast Bridge article described it as a key enabler.

Recall this layered arrangement from the previous article about DMF. The MXL layer is highlighted and sits immediately above the hosting layers. The rest of DMF is built on top of it.

This is fundamental, and this layered model is even reflected in the MXL project logo:

MXL is being delivered as a small library of code in an open-source Software Development Kit (SDK). Keeping things small and compact rather than delivering an entire framework aims to facilitate faster MXL deployment.

The key MXL design goals are:

• Shared memory (local and wide area).
• Low latency (especially for replication between hosts).
• Security via MXL domains.
• Scalability using containers.
• To be software friendly with robust API connections.
• To eliminate unnecessary media compression cycles.
• Sharing high data-rate media between Media Functions.
• Deliver a reduction in hardware deployment.

The shared memory concepts are already well understood by IT engineers. At the moment, this is working for devices communicating with one another within the same host. Sharing their memory is simple. More advanced sharing over wider domains is being developed.

What Is MXL?

The Unified Media eXchange Layer describes how virtualized DMF Media Functions share data with each other. MXL describes how this is done transparently with low CPU overheads and low latency.

MXL is analogous to the cable connections between the hardware devices in a traditional broadcast architecture. Because it can support multiple connections to the same source data, it works more like a matrix than a single cable. This facilitates the replacement of hardware devices with virtual containers running on local or cloud-based servers.

The EBU is driving the development of the MXL Standard, but is also collaborating with the Linux Foundation and the North American Broadcasting Association (NABA). The involvement of the Linux Foundation is to provide a technical charter and put the governance in place to deliver a framework for making Open Source projects.

MXL is available as an Open-Source project. This increases the likelihood of widespread adoption. The SDK is being developed first rather than being developed after the standard is ratified. Unconventional perhaps, but also possibly very effective and quick to market. This might set an example to other standards activities.

The EBU says:

The initial version of MXF will support these media types for exchange between the DMF Media Functions:

NMOS & MXL

MXL is conceptually based on NMOS Flows and Grains between Sender and Receiver ports in the devices. The unique identifiers and timing support defined by NMOS are also important in MXL.

NMOS is conceived around Nodes which contain one or more devices, and each device can support one or more senders and receivers. Simple devices might only have a single sender or receiver. These are all described as a resource and given a unique ID in the NMOS domain. Anything with a resource ID can be addressed for interaction with other resources.

NMOS and MXL share similar functionality, but use a different nomenclature. In this context, NMOS is a philosophy while MXL is an implementation:

This functionality is illustrated here with nested entities. They are labelled with NMOS and DMF nomenclature:

The simplest example in the NMOS documentation describes two devices with a single flow between them. The flow also has a unique ID so it can also be addressed as a resource. Here is an equivalent MXL scenario:

A more complex example describes an IP enabled camera with multiple flows in each direction:

A flow is a sequence of grains emitted by a sender and consumed by a receiver. The grains have various properties that help to manage them in the receiver:

• Timestamp relative to the PTP time-base.
• Flow ID to gather related grains together.
• Payload (video, audio or data).

All of the grains in a flow must carry the same kind of data. Video and audio grains would be delivered in separate flows with a regular cadence synchronized to the PTP timeline. Control and data grains are delivered at irregular intervals as needed. An MXL Domain (as shown in the recorder) combines all the flows needed for a workflow.

What Is Shared Memory?

MXL reduces latency by using shared memory to exchange information between the Media Functions. This is not a new concept. In fact the UNION declaration which shared data storage between different data structures was supported by the Fortran compiler in 1977.

There are several tiers of shared memory dealing with different physical architectures:

• Tier 1 - Different processes in the same host sharing local memory.
• Tier 2 - Different hosts in the same cluster replicating memory.
• Tier 3 - Different hosts in different clusters replicating memory over ‘long’ distances.

Note: That these tiers are not part of the current MXL design. They are used here to organize the different distribution models.

From a functional perspective, the different tiers should all look the same to a Media Function using MXL to share data with its siblings. The underlying implementation is hidden by using an abstraction layer which works fundamentally like a device driver:

Other techniques will emerge as MXL drives the need for shared memory between widely separated systems. MXL is currently being developed around the Tier 1 shared physical memory with ideas on how RDMA and DDP will support it for Tier 2.

Tier 1 - Physical Shared Memory

Shared memory within a single host avoids the need for the CPU to copy the data and provides significant performance benefits. A process can store data in a well-known memory location for another process to pick it up without the CPU needing to clone the data between two locations in memory.

Sharing data across multiple containers running on the same host is already supported in the prototype version of MXL.

Media is exchanged in shared memory using a tmpfs file system located at /dev/shm in the Linux OS environment. Consult the Linux Filesystem Hierarchy Standard for details of how this works.

Security in UNIX environments is described by the POSIX standard. In the context of MXL, it allows Read/Write permissions to be granted for individual users or members of a group. This manages the memory sharing without compromising the security.

Tier 2 - Virtual Shared Memory

Sharing memory between processes running on different host computers requires a mechanism to replicate the data from one host to another. Multiple hosts running in a single cluster can use the RDMA protocol described in RFC 5040 to virtualize their memory sharing.

Providing a buffer at each end where the contents are cloned automatically implements virtual shared memory.

The RDMA protocol for network shared memory is built on top of the DDP protocol. The data could be delivered via MPA and TCP but SCTP has lower latency and delivers the data faster.

Modern network interface cards can store incoming network data using Direct Memory Access (DMA) without the CPU needing to unload the network card data and store it in memory. This also frees up CPU capacity. The network transfer is very rapid with only a small amount of latency compared with physical sharing.

Tier 3 - Wide-Area Shared Memory

Extending shared memory between different clusters and clouds will need assistance from the cloud provider. Amazon Web Services (AWS) provides the Elastic Fabric Adapter (EFA). Use the equivalent Cloud Provider tools on a Google hosted platform. This is on the horizon but not yet being implemented in MXL.

Using Buffers In Shared Memory

MXL organizes the shared memory as ring buffers. A conventional buffer has a simple linear arrangement; a ring buffer joins the ends together. Provided the content is read from the buffer at least as fast as it is being written, a ring buffer appears to have infinite capacity. MXL adds a further refinement in that it allows multiple writer-reader pairs to occupy the same buffer:

Media Function senders will load grains of data into the buffer and receivers in other Media Functions will extract them. The buffer is the manifestation of an NMOS flow. Since this all happens in (Tier 1) shared physical memory within a single host, the latency is near zero.

MXL software will need to provide careful buffer management as it matures. If the readers in the Media Functions stall, the senders must avoid buffer overruns. Processes in UNIX can freeze or stall for a variety of reasons when they run out of resources. No doubt the designers are aware of this and will implement countermeasures.

Where To Find Out More

DMF and MXL are works in progress with standards to be released in due course. Some early draft material and prototype software is in circulation for early adopters to use in the meantime. More information is available from these organizations:

• EBU.
• Linux Foundation.
• NABA.

Resources From The EBU

Resources From The Linux Foundation

The Linux Foundation is an important member of the Open-Source software community. Their involvement ensures that the platform support will be first class. This should be easily reflected into macOS due to its UNIX heritage. Windows support will benefit by having a UNIX environment installed to support MXL. You might use Cygwin or the Windows Subsystem for Linux (WSL) to create the necessary environment.

Resources From POSIX Org

Related Standards

There are literally thousands of three- and four-letter acronyms. Sometimes called buzz-word soup, it is very easy to mistake one for another when they are so very similar.

Acquire the resources on these key protocols and projects to start with, then gather the other related standards for supporting technologies.

• MXL - See the open-source Git repository.
• RDMA protocol standard - RFC 5040.
• DDP standard - RFC 5041.

Conclusion

We are very early in the MXL development lifecycle and there is still much work to do. MXL is still at the experimental prototype stage with a version 1 release expected in 2026. Progress to date has already encouraged the Canadian Broadcast Corporation (CBC) to build a new studio infrastructure using MXL as a foundation, but DMF and MXL are being widely adopted by major broadcasters and the momentum behind it is significant.

At the moment, MXL is focused on a limited sub-set of uncompressed video and audio formats. More complex compression and variable frame rates will arrive later on.

Timing is very much a work in progress. Media grains as defined in NMOS need to carry their time signature as they travel through the ring buffers so they can be reassembled in the receiving Media Function in a coherent sequence. Delivering media as grains rather than streams might allow multiple buffers to be used to increase the transfer capacity.

The Canadian Broadcasting Corporation is targeting February 2026 to deploy DMF and MXL in time to support the Winter Olympics.

ST 2110 has been a significant enabler and an important step along the way to DMF. It is still relevant and important as it deals with ingest and edge connectivity to legacy architectures. It also has some useful applications in the delivery of media flows between CPU clusters.

It is rare that a broadcasting technology concept is so elegantly simple as MXL!

Appendix - IETF Documents (RFC, STD & BCP Collections)

The RFC documents are Requests For Comments. Generally speaking these are treated as standards although this wasn’t the original intent. One of the problems with RFCs is that as new ones are issued to obsolete old ones, the number changes. This makes it confusing to describe internet protocols in terms of their RFC number.

In 1992, the IETF started issuing STD documents. These would aggregate several RFCs under a stable and static reference number. The RFC numbers could then change but the STD number would remain the same.

Appendix - Other Similar Technologies

There are a few similar and related technologies that implement similar synchronized and shared content and data. Authentication of the client against the security model in the server is vitally important. Understanding these provides additional options for planning your infrastructure. MXL is designed around shared memory but it can use files and folders for the exchange.

All 9 articles in this series are now available in our free eBook ‘Cloud Compute Infrastructure – The Book 2026’ – download it HERE.