Industry Insights: The Media Exchange Layer’s role in software-defined production

As broadcasters continue to explore software-defined architectures, one topic is increasingly moving from engineering discussions to broader infrastructure planning: the Media eXchange Layer, or MXL.

Designed to enable efficient media exchange between software applications, MXL is emerging as a potential building block for more flexible, interoperable production environments. Yet questions remain about where it fits alongside SMPTE ST 2110, how organizations are approaching deployment, and what challenges still stand between industry interest and large-scale adoption.

For this edition of Industry Insights, NCS brought together technology vendors, manufacturers and industry experts to discuss MXL’s role in modern media infrastructure.

In this first part of a two-part series, participants examine what problems MXL is solving today, how early adopters are approaching implementation, and whether it represents an evolution of existing IP workflows or an entirely new architectural layer.

Key takeaways from this Industry Insights roundtable

• Complementary technologies: Most participants viewed MXL as a complement to SMPTE ST 2110 rather than a replacement, with each serving different roles within modern media architectures.
• Software-first exchange: MXL is designed to improve how software applications exchange uncompressed media, reducing latency, processing overhead and integration complexity in compute-based environments.
• Incremental adoption: Early deployments are largely focused on targeted pilots and hybrid implementations that preserve existing infrastructure while introducing software-defined workflows.
• Interoperability focus: Participants consistently identified vendor interoperability and open media exchange as among MXL’s most significant potential benefits.
• Work still ahead: While enthusiasm is growing, respondents noted that ecosystem maturity, multi-server scalability, orchestration and operational tooling remain areas requiring further development.

How are organizations interpreting the role of the media exchange layer (MXL) within the broader shift toward software-defined media facilities?

Ian Wagdin, VP, technology and innovation, Appear: The best analogy for MXL’s significance is SDI, which got its power from ubiquity, not specification, enabling decades of innovation by making hardware interoperability effortless. MXL is designed to do the same for software. It provides a common layer for containerized applications from different vendors to exchange media natively in compute environments. Notably, the governing body within the Linux Foundation pursued an “implement-first” strategy — building a working SDK before standards ratification — which accelerated adoption and marks a significant departure from previous standardization efforts.

John Mailhot, SVP, product management, Imagine Communications: Most organizations view SMPTE ST 2110 and MXL as complementary technologies serving different operational domains. Typically, MXL is viewed as part of the transition toward software-based infrastructure — focused on efficient media exchange between software processes running in computing environments such as Kubernetes clusters — while ST 2110 continues to provide deterministic transport across facility infrastructure. Dynamic media facilities (DMF) can and should leverage the equipment and systems broadcasters already own — whether based on ST 2110 or even SDI.

Paul Briscoe, chief architect, TAG Video Systems: Most organizations are mapping MXL onto their existing ST 2110 mental model. They’re treating it as another protocol layer rather than a transport architecture that removes constraints they’ve been working around for years. The more accurate framing is that MXL handles what ST 2110 was never designed for: consistent operation across on-premises, cloud, and hybrid environments and freedom from the more fragile PTP-aware multicast UDP networks of 2110.

Adam Marshall, CPO, Grass Valley: There is still a level of learning needed in the market around the role MXL plays. It is not a replacement transport layer, but a solution for media exchange within compute architectures, working alongside traditional transport at the edge. MXL unblocks one important part of the puzzle, which is how media flows are handed off between applications in shared, multi-vendor, software-based environments, but it still needs the wider DMF model, and platforms such as GV AMPP, to make discovery, identity, control and security practical in the real world.

Advertisement

Russell Trafford-Jones, industry engagement manager, Techex: Organizations are starting to see MXL as one of the missing pieces in the software-defined facility puzzle. It gives software applications a way to exchange uncompressed live media with something closer to the immediacy and confidence engineers associate with SDI, rather than forcing everything through codecs or network transport simply because that was the available route. It’s seen as what makes a truly flexible, vendor-interoperable, deploy-anywhere live production environment possible.

Drew Martin, head of video product management, Riedel Communications: Many organizations see MXL as a key enabler of software-defined media facilities. It provides a more efficient and interoperable way for vendors to share real-time, uncompressed media flows, which is increasingly important as workflows continue to move into software-based environments.

Francesco Scartozzi, VP, sales and business development, Matrox Video: MXL is increasingly being positioned as an interoperability layer for software-defined production, enabling media applications to exchange uncompressed content across standard IT infrastructure without vendor lock-in. Rather than replacing existing transport standards, MXL focuses on application-level interoperability and modular service integration.

What problems is MXL actually solving today, and where does it still fall short in practice?

Ian Wagdin, VP, technology and innovation, Appear: Today, MXL reduces latency, CPU overhead and integration complexity by enabling media applications to exchange data through shared memory rather than repeatedly packetizing and rebuilding streams, supporting more open, best-of-breed workflows. In order to maintain interoperability and vendor differentiation, the scope of MXL is deliberately limited to a single exchange format. This means that some operations may need a conversion function before and after the MXL layer.

John Mailhot, SVP, product management, Imagine Communications: MXL is one small part of a much larger push towards DMFs. It solves efficient, high-performance media exchange between coordinated software applications operating on shared compute infrastructure, and is particularly well suited for virtualized, orchestrated workflows that deploy on dynamically scalable processing resources. Its limitations today are less about capability and more about the overall maturity of the DMF ecosystem, including aspects of planning, scheduling, deployment, connection management, and integration with the surrounding environment.

Chris Scheck, head of marketing content, Lawo: MXL is being developed by broadcast vendors, broadcasters, and software developers as we speak, with a working incarnation expected later this year, so we’ll have to postpone our judgement until then. The most important challenge it will solve is that processing apps by different vendors will be able to exchange media through a shared memory layer—with no latency-inducing encapsulation and decapsulation routines to get the media from one app to the next.

Paul Briscoe, chief architect, TAG Video Systems: The concrete problem MXL solves is moving media efficiently between functional elements within and between containers and hosts without the overhead of doing it using streams. Where it still falls short is large geo-scale RDMA deployments, simply because we’re early on the MXL curve and streaming is quite efficient across large spans. Adoption of MXL as the core stack in production will accelerate scale rapidly as its use evolves to achieve greater capability and scale.

Adam Marshall, CPO, Grass Valley: MXL is solving very real problems around the exchange of media essence between software-based applications in shared compute and containerized environments. It helps avoid unnecessary media copies and enables asynchronous processing, which plays much better to the strengths of how compute actually processes tasks. What is intentionally outside MXL is the orchestration and control layer, keeping the SDK simple and interoperable, while JT-DMF addresses how flow discovery, control and security should work in practice.

Olivier Suard, vice president, marketing, Nevion: MXL provides an industry-standard way for software-based media transport and processing applications to share data extremely quickly and efficiently. In doing so, not only does it support the need for low latency in live production but, commercially, it ensures that buyers (e.g broadcasters) are not locked into some vendors’ proprietary ecosystems.

Russell Trafford-Jones, industry engagement manager, Techex: Today, MXL is solving a very practical problem: how to move uncompressed media between third-party software processes on the same server. It removes a lot of the codec, transport and CPU overhead that can appear when SRT or SMPTE ST 2110 are used between software applications that are already sitting next to each other. Where it still falls short is reach: The shared-memory model lives inside a single server, and the MXL project work extending it across multiple servers with RDMA is still maturing.

Ken Smith, senior media design engineer, Diversifed: MXL is solving some of the industry’s biggest challenges around media exchange, interoperability, and reducing vendor silos by creating a more standardized framework for software-based and distributed media workflows. It enables workflows to become more portable and dynamically orchestrated across on-prem, cloud, and hybrid environments. Where it still falls short is in practical implementation maturity — particularly around interoperability consistency, operational complexity, timing determinism, and the level of visibility and reliability broadcasters expect in mission-critical live production environments.

Drew Martin, head of video product management, Riedel Communications: MXL helps address utilization and timing challenges in software-based media workflows, improving overall efficiency and synchronization. That said, integration across diverse systems can still be challenging, and there’s work to be done to make adoption easier in more complex environments.

Advertisement

How are early adopters approaching MXL?

John Mailhot, SVP, product management, Imagine Communications: Many of the early demonstrations use MXL as static connections between static processes — the “running state” of the workflow. But this misses the primary value of the dynamic media facility — the dynamic operation of the system. The true value of the DMF will come from the layers above MXL, defining workflows, deployment architectures, and operational conventions so that workflows can be dynamically instantiated and deconstructed at will — which is when the benefits of the DMF become tangible.

Russell Trafford-Jones, industry engagement manager, Techex: Early adopters are being pragmatic, starting with targeted interop use cases where uncompressed exchange between software systems takes obvious friction out of an existing workflow. Nobody is ripping out a facility; they are running pilots and interop demos to pressure-test latency, reliability, timing and operational fit in real production-like conditions. The pattern is simple: prove MXL behaves like a familiar live media connection, then use that confidence to open the door to software-defined architectures.

Ken Smith, senior media design engineer, Diversifed: Early adopters are approaching MXL cautiously, incrementally and strategically targeting specific workflows such as multiviewers, signal processing, or remote production as hybrid models. It is being treated as an experimental, compute side fabric while continuing to use 2110 for facility wide media movement.

Drew Martin, head of video product management, Riedel Communications: Early adopters are gravitating toward MXL largely because of its SDK and the ability to avoid building custom solutions from scratch. Its software-based approach fits well with the way engineers are currently developing modern media workflows.

What does a realistic implementation path look like for MXL within existing SMPTE 2110-based facilities?

Ian Wagdin, VP, technology and innovation, Appear: The conceptual distinction really matters here: ST 2110 is a transport protocol for connecting physical devices; MXL operates in the compute domain, where applications need to pass data asynchronously and faster than real time. They are complementary, not competing. The practical approach is to continue using ST 2110 for facility-wide transport while introducing MXL within software processing environments — a hybrid architecture that allows organizations to modernize incrementally while protecting existing investments.

John Mailhot, SVP, product management, Imagine Communications: The realistic path forward is incremental integration, not wholesale replacement. Existing SMPTE ST 2110 deployments continue to handle transport between physical systems; as facilities implement general-purpose computing farms for software-based processing, ST 2110 delivers signals to the pool and retrieves them afterwards, while MXL operates inside the software-defined pool for application-to-application media exchange. Most organizations see this as a hybrid operational model that preserves current infrastructure investments while enabling more flexible software-native workflows.

Chris Scheck, head of marketing content, Lawo: For MXL to make a meaningful difference, it needs to be supported by as many app vendors as possible that all exchange media via a common shared-memory plane. Before MXL can kick in, however, broadcasters will need to adopt video and audio processing apps that run on COTS servers. The move away from bespoke processing hardware towards apps is already well underway and can anyway be a gradual process if one only replaces hardware that is reaching end of life with apps.

Paul Briscoe, chief architect, TAG Video Systems: The practical starting point is a same-host deployment, which requires no RDMA and lets teams validate the integration before introducing network complexity. From there, you extend to multi-server configurations using RDMA over converged ethernet as needed. MXL maintains full ST 2110 compatibility, so you’re adding a transport layer that removes scaling constraints and doesn’t rip out the infrastructure you’ve already invested in and simply continues to build on today’s compute/network IT model.

Jan Helgesen, head of products and solutions, Nevion: In facilities utilizing SMPTE ST 2110, MXL will predominantly serve as the means for efficient content exchange among software-based media functions. Consequently, the implementation approach will be closely aligned with the integration of software-based processing within these environments. For SDI-based facilities, it may be possible to establish a more direct transition from SDI to MXL; however, this is largely dependent on the specific balance between hardware and software processing infrastructure in use.

Ken Smith, senior media design engineer, Diversifed: A realistic implementation path for MXL within existing SMPTE 2110 facilities will likely be incremental rather than a full replacement of the current architecture. Most broadcasters will continue using deterministic 2110 transport for core real-time media flows, while introducing MXL in areas that benefit from software-defined processing and elastic compute resources. The challenge will be integrating that flexibility while maintaining the timing precision, interoperability, and operational reliability expected in live broadcast environments.

Advertisement

Drew Martin, head of video product management, Riedel Communications: A realistic implementation path within existing SMPTE 2110 facilities involves the two technologies working together. ST 2110 continues to serve as the standard for sending and receiving feeds and managing media distribution within and beyond the data center, while MXL enables real-time intramachine and intermachine communication. As facilities continue moving toward more software-defined workflows, ST 2110 will remain central to media transport, with MXL acting as the live production fabric that supports efficient, real-time media exchange inside the data center.

Is MXL being viewed as an evolution of current IP standards or as a parallel architecture?

Ian Wagdin, VP, technology and innovation, Appear: MXL is best understood as an evolution of existing IP and software principles rather than a competing architecture, building on NMOS, ST 2110 workflows and shared-memory techniques already familiar in IT and cloud. The EBU DMF reference architecture, with its clearly defined layers covering orchestration, security and media functions, provides the framework within which MXL’s role can be precisely located. The goal is not to replace proven standards but to extend them into software-native environments where stream-based approaches become inefficient.

John Mailhot, SVP, product management, Imagine Communications: It is generally being viewed less as an evolution of existing IP transport standards and more as an expansion of the overall media infrastructure stack. Rather than displacing SMPTE ST 2110, it addresses a different operational requirement centered on software-native media processing within scalable computing environments. The industry increasingly sees these technologies as complementary components within a broader layered architecture.

Chris Scheck, head of marketing content, Lawo: I guess one could say that MXL is an initiative to achieve fast, uniform media transport with different means, as everything happens inside a server. Unlike for IP, however, there is no industry body that first needs to agree on best practices before rolling out a standard, which takes time broadcasters and AV users no longer have. While IP standards are by no means obsolete, broadcasters, vendors and software developers realized the benefit of developing MXL as an open-source project, inviting contributions from those who believe that a software-based dynamic and agile media technology stack is of the essence to remain relevant in a fast-evolving media landscape.

Paul Briscoe, chief architect, TAG Video Systems: It’s both, and this framing matters for how organizations approach MXL. MXL is architecturally distinct, memory-to-memory transport rather than streaming packet-by-packet delivery, but operationally it’s designed to coexist with ST 2110 infrastructure, not displace it — it’s all still built on compute and IP networking. Facilities already invested in IP aren’t facing a forklift replacement, they’re adding a layer that makes their existing investment work in environments where ST 2110 alone doesn’t, and combined with DMF, enabling entirely new thinking in architecture, design and operation.

Adam Marshall, CPO, Grass Valley: MXL is best viewed as an evolution in media architecture, rather than a replacement for current IP standards. SMPTE 2110 standardized how media essences move across IP networks, while MXL is focused on how software applications exchange and process media more efficiently within shared compute. The two will absolutely coexist, with ST 2110, SDI and compressed transport continuing to play a key role at the edge, in and out of that shared compute environment.

Olivier Suard, vice president, marketing, Nevion: MXL is not a replacement for SMPTE ST2110; it’s a complementary technology. Whereas SMPTE ST2110 is a universal way to transport signals in real-time over an IP network, MXL is a way to transport signals (or mode correctly share data) in real-time between software applications or rather software media functions. SMPTE ST2110 will continue to be relevant for a long time, just as SDI is still relevant. The real evolution going on is the move from dedicated hardware towards software.

Russell Trafford-Jones, industry engagement manager, Techex: MXL is best understood as a parallel architecture solving a different problem, not a successor to 2110. SMPTE ST 2110 remains essential for real-time transport across the facility, but it adds unnecessary complexity when you use it for high-performance exchange between software processes on the same server. MXL sits alongside 2110 as a process-to-process exchange layer rather than a rebellion against IP standards, just a more natural fit for media moving between nearby software processes.

Ken Smith, senior media design engineer, Diversifed: MXL is a compliment to 2110 and should be viewed as parallel architecture. 2110 should remain as the deterministic transport framework for moving professional media across physical IP networks, while MXL addresses the exchange of media between software applications, containers, and processing functions within compute networks.

Drew Martin, head of video product management, Riedel Communications: MXL is generally viewed as a parallel architecture that complements existing IP standards. While it uses IP for machine-to-machine communication, it aligns more closely with broader IT industry standards than with the broadcast-specific approach of ST 2110.

Francesco Scartozzi, VP, sales and business development, Matrox Video: MXL is viewed as complementary to current IP standards rather than a replacement for them. SMPTE ST 2110, SDI, SRT, and MXL can coexist within software-defined media facilities, enabling flexible integration of multiple media types and workflows. In this model, MXL acts as a foundational software layer for interoperable media services, while Matrox Video provides a broader fabric and orchestration framework that unifies these workflows within software-defined infrastructures.

With rising memory and GPU costs, is MXL the right move?

Chris Scheck, head of marketing content, Lawo: Even the cost of FPGA circuits, which are used in a lot of software-defined devices, not to mention SSDs and memory chips for laptops, etc., is rising, and any price hike tends to come at an awkward time. Software-based processing on generic servers has some indisputable benefits that outweigh component price considerations: Users no longer need to plan for peak capacity, can achieve the same results with fewer 1U servers, and have substantially fewer devices sitting idle most of the time; broadcast vendors no longer need to design their own processing hardware that tends to be outdated by the time it is released and anyway costs more than much more powerful generic servers built by global players.

Adam Marshall, CPO, Grass Valley: Rising memory and GPU costs actually make the discipline behind MXL more important, not less. The point is not to throw more compute at the problem, but to reduce waste by avoiding unnecessary copies, hand-offs and duplicated processing. MXL is the right move when it lowers total system complexity and cost, but it becomes the wrong move if it is implemented as another isolated stack or treated as a simple lift and shift.

Olivier Suard, vice president, marketing, Nevion: Rising memory and GPU costs are indeed a major concern, but relative to the processing requirements of media functions for live production, the additional consumption required by MXL is minimal. Besides, the need to transport signals remains regardless of whether MXL is used or not, so memory and GPU costs are a marginal-to-irrelevant consideration. At the same time, MXL brings substantial benefits in terms of latency and efficiency, which make MXL the right move for software media functions.

Ken Smith, senior media design engineer, Diversifed: MXL does not eliminate infrastructure costs, it shifts it. A business case must be evaluated carefully against rising performance memory costs and GPU resources. Its value is strongest where organizations require dynamic workflows, multi-vendor software alignment, elastic deployment and reduced dependence on fixed function hardware.

Drew Martin, head of video product management, Riedel Communications: Even with rising memory and GPU costs, MXL helps customers get more value and performance out of their machine resources. By improving utilization and enabling more efficient software-based workflows, it allows organizations to make better use of the infrastructure they already have.