MXL Touts True IP Interoperability

As the television industry continues its transition from SDI infrastructure to IP networking, broadcasters and vendors have joined forces to solve interoperability issues between different manufacturers’ software products that have plagued both early ST 2110 plants and production applications running in the public cloud. And in the open-source “virtual cabling” technology known as the Media eXchange Layer (MXL), they may have come up with a cheaper, faster alternative to 2110 for handling uncompressed video in the IP domain.

The MXL technology initiative was born out of the European Broadcast Union’s Dynamic Media Facility (DMF) project. DMF, which was first proposed in 2023 and presented in detail at IBC 2024, is aimed at creating completely software-based, truly flexible broadcast architectures that can be quickly scaled up or down to meet changing production requirements.

Under the DMF concept, traditional broadcast functions will run as containerized software applications, or microservices, on common off-the-shelf (COTS) IT hardware located either on-premise or in the public cloud. And broadcasters won’t be saddled with products that run on COTS servers which can’t be reconfigured to do multiple applications and wind up being single-use boxes that don’t differ much in functionality from the legacy proprietary hardware they replaced.

A Complex Cake

The EBU diagrams the DMF as a complicated cake composed of six horizontal layers, with half being IT technology and the other half being broadcast-specific. The three generic IT layers are the infrastructure (high-performance compute with CPU/GPU processing and gigabit ethernet networking), host platform (Linux operating system) and container platform (Kubernetes orchestration or similar). The three broadcast-specific layers are the media exchange, media functions and application/UI. Cutting across all six of these layers, on the vertical axis, are three layers of “cross-cutting” concerns that apply to all, which include provisioning, control and monitoring and security.

Put simply, the IT layers are intended to leverage established high-performance computing (HPC) technology, while the broadcast-specific layers are where more innovation and development is required. But both halves of the DMF stack will benefit from significant improvements in processing speed and throughput from the IT world, much of it driven by the recent AI boom.

“The software transformation of the industry can unlock a lot of the benefits of the R&D that’s spent in the IT industry, and we can use that in broadcast,” says Marwan Al-Habbal, product manager at Matrox Video. “There’s no need to reinvent the wheel with proprietary broadcast technology. Let’s just use this.”

Matrox is one of six vendors that in November 2024 formed a “Tiger Team” tasked by the EBU with tackling media exchange, soon formalized as MXL. The goal was to allow applications from different vendors to simultaneously access and work with video in shared memory, either on the same server or between networked compute nodes. The other team members are Grass Valley, Lawo, Riedel, Intel and Nvidia.

Those six vendors were joined in the MXL kickoff meeting at EBU headquarters in Geneva by other vendors including AWS, Telos Alliance, Sony, Google Cloud and Appear; industry organization Video Services Forum (VSF); and broadcasters including CBC/Radio-Canada, BBC and France TV.

CBC/Radio-Canada was particularly interested in MXL after its experiences in creating a new ST 2110 plant in Montreal, says Francois Legrand, senior director of the CBC Innovation Hub. The IP-based facility has given CBC new flexibility in configuring resources, like dynamically mapping control rooms to different studios. But some FPGA-based server products that the CBC installed haven’t lived up to their promised potential because they weren’t able to be reconfigured to handle multiple functions.

“Every product is one thing, and they will remain that thing forever,” Legrand says.

He and his colleague Felix Poulin, director, global collaborations for the CBC Innovation Hub, are determined to have a better result in their Toronto facility, which they are planning to gradually upgrade in place. They see MXL as a way to achieve true interoperability, and they have been deeply involved in developing the SDK and evangelizing the technology in general.

“We’re serious about going as far as we can with software-defined infrastructure,” Legrand says. “For me, that software-defined infrastructure is a prerequisite to another transformation, which is more AI in our workflow. Those AI algorithms, typically they work in software. You need to have your team in software to be able to leverage some kind of AI processing or AI audio mixing, or whatever — you need to be in that software world first.”

Lawo had already developed similar technology to DMF with its Home apps, as had Grass Valley, Riedel and Matrox with their own cloud-based production platforms. But CTO Phil Myers said the 2024 Geneva meeting was impactful in not only having key vendors there to discuss technology, but also having broadcasters in the room to share their operational and economic requirements.

“What came from that, looking at the Dynamic Media Facility stack, was to say, well, the media exchange layer of how you pass data between the media functions is going to be the thing that’s the most important,” Myers says. “Because if you want to have multi-vendor, multi-functions on the same box or across compute boxes, you’re going to need a holistic approach to be able to share it.”

A Novel Approach

With a focus on speed, the Tiger Team decided to avoid the usual lengthy standardization process traditionally followed by new broadcast technologies. Instead, they opted to create MXL as an open-source software development kit [SDK], holding weekly conference calls and posting their work on GitHub to invite industry contributions. They moved fast, holding a follow-up meeting at the CBC’s Toronto broadcast center in March 2025, gaining formal governance under the auspices of the Linux Foundation in April 2025, and then releasing an alpha version of the MXL SDK at another EBU meeting in June.

By IBC 2025 in September, MXL was ready enough to be featured in several multivendor demos. Broad interoperability testing is currently underway, and the group hopes to have a minimum viable product (MVP), or MXL Version 1.0, ready for release in early 2026.

Brian Olsen, video production segment manager for Intel and an industry veteran with previous stints at Pinnacle Systems, Miranda, Ross Video and Vizrt, is very impressed by MXL’s rapid progress.

“I’ve been around for a while in the space, and I’ve never quite seen this level of cooperation between vendors,” Olsen says. “That was one of the things I was excited about. If everybody puts aside the competitive aspect for a little bit and actually works together to try to build this, it’s going to happen faster. And, of course, you’ve got the best chance for interoperability as well when everybody’s kind of on board with how they want to do it, and they’re agreeing on some common color space, video formats, audio formats and basically the SDK to pass that media from vendor to vendor.”

Asynchronous In The House

MXL can work with ST 2110 on the periphery (through inputs and outputs) and incorporates some key 2110 technologies like NMOS (Networked Media Open Specifications). But there are fundamental differences in how it handles video. While 2110 is based on IP switches and gigabit ethernet networking, it still handles video and audio in a similar fashion to SDI, pushing flows in a synchronous fashion as tiny packets, one frame at a time.

“And modern computers and networks really hate doing lots of little things very accurately,” says Grass Valley CTO Ian Fletcher. “They’re very good at big things very quickly. So, no matter how fast your network is, it will still take a frame to send a frame from one computer to another using 2110. And in fact, it will take more than a frame, because there’s usually buffering on either end.”

MXL, on the other hand, takes advantage of shared memory buffers to process video in an asynchronous fashion and then uses ring buffers to achieve an accurately timed video output. So, when Microservice A is generating uncompressed video flows and Microservice B needs to read them to perform a job, Fletcher says, it doesn’t push them as a flow to be copied.

“This is a case where you don’t do that,” Fletcher says. “You literally put your frame into memory, and this one knows where to go and look for it, and it basically reads that memory. You’re not copying things around all the time.”

If you’re not a software engineer, the technology behind MXL can be rather complicated to understand. But Fletcher says a simple way to think about is to use the analogy of plumbing in a house, where the “house” is a software-based production platform like Grass Valley AMPP (or Lawo’s Home, Riedel’s SimplyLive or Matrox’s Origin). The plumbing (i.e., access to shared memory) in that house allows water (uncompressed video) to flow between different rooms and work with taps and sinks (microservices) from different manufacturers. And in the next phase of MXL, it will also allow that water to flow to the house next door (a separate computer node that is connected by high-speed networking).

Grass Valley doesn’t want to make everything, notes Fletcher, and the security and maintenance provided by a “house” platform like AMPP, when used with MXL, will allow smaller vendors to simply focus on the particular functions they specialize in.

“The important thing is, those vendors need to be able to make their taps and sinks and showers knowing that they would work in the Grass Valley house or a Lawo house or a Riedel house,” Fletcher says. “And so that’s the problem that MXL solves.”

The next phase of MXL comes in connecting neighboring houses. It will use a technology called RoCE, which stands for Remote Dynamic Memory Access over Converged Ethernet, an industry standard used in big data centers for years.

“The nice thing about the way RoCE works is it literally takes memory from one machine, maps it through the NIC [network interface card] without going through the CPU, to the memory on another machine,” Fletcher says. “Effectively, it is like letting us share memory across high-performance computer networks. That’s how we would connect the rooms together, and it’s also how we would connect houses together.”

Smoothing Cloud Production

MXL is not designed to link ground-to-cloud functions, which generally use compressed transport streams like SRT. Instead, it is designed to work strictly with uncompressed video in either on-premise or cloud compute. But Drew Martin, head of video product management for Riedel, still thinks MXL could give a big boost to live cloud production by allowing broadcasters to transport high-res frames between two separate vendors’ software on the same machine, without having to re-encode it or go out to 2110.

Those extra steps in current cloud workflows add both latency and cost, he says. “What people have hated is when they’re in the cloud, they’ll use software solutions, and because the software solutions have to re-clock it on the way out, every software solution does not really have a steady latency,” Martin says. “It’s kind of hopping up and down. It’s really hard for people to align video and audio once you break it up and put it back together. It’s been limiting a lot of the live productions.”

That said, he thinks it’s still early days for MXL. He says there is significant work still to be done on the control, security and orchestration software needed for MXL to be used across a large, complex system. And he doesn’t expect consensus will be reached as easily on those layers as it was on MXL.

“My biggest fear is that you have Lawo Home, you have Grass Valley AMPP, you have Matrix Origin, and if you wanted to run all three of them at the same time, you’d probably have to run all three platforms, all three licensing mechanisms and all that stuff,” muses Martin. “There’s a little bit of that mess that we’re trying to figure out.”

A Note Of Caution On Control

John Mailhot, systems architect for IP convergence at Imagine Communications, has been following MXF closely through his related work with the VSF and will be giving a presentation on the technology along with the CBC and NABA at the SVG Summit in New York later this month. Mailhot thinks MXL’s open-source development path makes sense, and he finds the way it employs RDMA to be interesting. But he says that using shared memory is nothing new, as it has been prevalent in the computer industry for years.

Imagine is ready to support MXL in its products when customers ask for it, Mailhot says. But he is skeptical that the industry will be able to as easily find consensus as vendors move up the DMF stack from the plumbing layer that is MXL and tackle thornier issues like control, provisioning and support. He doesn’t think the notion of a standardized “monster orchestrator in the sky that works for everybody” is very realistic.

“There are lots of control solutions out there that solve for those upper layers of the stack,” Mailhot says. “But they’re not free. They cost money and time and effort to put together, and they’re done by the usual suspects as the vendor. And I don’t see that really changing that much, that model.”

The post MXL Touts True IP Interoperability appeared first on TV News Check.