Rising compute costs put MXL’s business case under pressure

By Dak Dillon June 9, 2026

Weekly insights on the technology, production and business decisions shaping media and broadcast. Free to access. Independent coverage. Unsubscribe anytime.

The broadcast industry has been here before.

A new framework arrives with a compelling architectural argument. Vendors align behind it. Working groups form. And facilities are left asking a question that tends to get lost in the technical conversation: what does this actually cost?

The Media Exchange Layer (MXL) is the current version of that question.

The technology has a growing base of vendor support, a working SDK and a growing body of interoperability testing behind it. It also depends on shared compute infrastructure, including servers, memory and in some configurations GPUs, at a moment when the cost of all three is rising dramatically.

For CFOs, operations heads and procurement teams, the architectural elegance of MXL is secondary to a more basic calculation. Does adopting this framework reduce what a facility spends, increase it or simply move costs from one column to another?

The honest answer, based on responses from vendors and system integrators, is that it depends, and that the dependency is not always on factors a facility can control.

Costs shift, they do not disappear

“MXL does not eliminate infrastructure costs, it shifts it,” said Ken Smith, senior media design engineer at Diversified. “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.”

That framing is useful because it resists the promotional logic that often surrounds new frameworks. The question is not whether MXL has value, most respondents in our Industry Insights roundtable agreed it does under the right conditions, but whether the conditions at a given facility match the ones where that value materializes.

Advertisement

For a facility with highly dynamic workflows, frequent reconfiguration needs and existing investment in COTS server infrastructure, the math may work. For a facility running stable, predictable workflows on hardware that is not yet at end of life, the calculation looks different.

“Rising memory and GPU costs actually make the discipline behind MXL more important, not less,” said Adam Marshall, chief product officer at Grass Valley. “The point is not to throw more compute at the problem, but to reduce waste by avoiding unnecessary copies, handoffs and duplicated processing.”

Marshall pushed back on the framing that rising compute costs argue against MXL. His position was the reverse: that cost pressure makes the efficiency argument for MXL more relevant, not less.

That argument has merit on its own terms.

Software-defined workflows running on shared compute can, in principle, use resources more efficiently than fixed-function hardware that sits idle between productions. MXL’s shared memory model is specifically designed to reduce the overhead of moving media between applications, overhead that in a traditional architecture gets absorbed invisibly into hardware costs.

The caveat Marshall added is worth noting. MXL delivers on that efficiency argument only when it is implemented as a genuinely integrated layer, not as an additional stack sitting alongside existing infrastructure. Facilities that treat MXL as a bolt-on risk adding cost rather than reducing it.

A minimal footprint, if the workload fits

Olivier Suard, vice president of marketing at Nevion, addressed the memory cost question directly and argued it is being overstated. The additional compute consumption that MXL requires, he said, is small relative to the processing demands of live production workflows.

“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,” Suard said. “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.”

That position assumes, however, that a facility is already running software-based media functions on shared compute. For facilities still operating primarily on dedicated hardware, the cost of standing up that compute infrastructure is not marginal. It is the starting point.

Chris Scheck, head of marketing content at Lawo, made the broadest cost argument in favor of software-based processing on COTS hardware, the infrastructure class that MXL is designed to run on.

“Software-based processing on generic servers has some indisputable benefits that outweigh component price considerations,” Scheck said, citing the ability to avoid planning for peak capacity, reduce idle hardware and run audio and video applications simultaneously on a single server. Broadcast vendors, he added, no longer need to design their own processing hardware, equipment 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.”

The argument is familiar and not without foundation.

Advertisement

COTS hardware has continued to outpace purpose-built broadcast equipment on raw performance metrics. But the cost of COTS hardware is also rising. Scheck acknowledged that FPGA circuits, SSDs and memory chips are all subject to the same price pressures the question raises, before arguing that the structural advantages of generic servers remain.

“Even with rising memory and GPU costs, MXL helps customers get more value and performance out of their machine resources,” said Drew Martin, head of video product management at Riedel Communications.

What the range of answers actually says

The spread of positions, from Smith’s careful cost-shift framing to Scheck’s broader endorsement of COTS economics, does not reflect disagreement about what MXL does. It reflects the reality that MXL’s financial case is highly context-dependent.

A framework that reduces waste and improves utilization delivers on that promise only if a facility has waste to reduce and resources that are currently underutilized. A framework that avoids expensive purpose-built hardware delivers savings only if the alternative hardware is actually cheaper when total cost of ownership is accounted for. And a framework that enables elastic deployment delivers operational value only if a facility’s workflows are elastic enough to need it.

None of that makes MXL a poor investment.

It makes it an investment that requires the same scrutiny any significant infrastructure decision deserves, scrutiny that the enthusiasm around a new framework can sometimes crowd out.

The industry has seen that pattern before.

The ST 2110 transition carried similar promises of cost efficiency through IP infrastructure. Some facilities realized those savings. Others found, as Bowser Mason noted at a recent industry event, that the off-the-shelf hardware promise did not fully account for the specialized requirements of broadcast applications.

MXL is a different technology solving a different problem. But the question it faces, does the financial case hold when procurement teams run the actual numbers, is the same one every infrastructure standard eventually has to answer.

Advertisement