Russell Trafford-Jones makes a compelling case for DMF and software-defined production. But I’m not convinced the industry knows what it’s signing up for—or whether it’s ready to let go.

By Ben Anchor — Tuesday, 18 November 2025 · Listen to the podcast episode

I’ve just finished a conversation with Russell Trafford-Jones about DMF—the Dynamic Media Facility concept—and I’m left with that familiar mix of excitement and unease that comes whenever someone proposes tearing up the rulebook.

Russell’s been in broadcast for 20 years, works at TechEx (a company that specialises in moving live video), and he’s enthusiastic about what happens when you stop caring about the metal and focus purely on the software. His pitch is simple: imagine if your entire facility was just software floating around on generic compute, orchestrated dynamically, scaled elastically, indifferent to whether it’s on-prem or in AWS. No vendor lock-in. No over-provisioning. Just workloads spinning up when you need them and disappearing when you don’t.

It sounds utopian. And that’s precisely why I’m wary.

The Promise: Flexibility Without the Baggage

Russell frames DMF as the logical endpoint of a journey the industry’s already on. We’ve moved from SDI routers to IP networks, from hardware appliances to virtualised playout, from on-prem to cloud. Each shift bought us flexibility—and forced us to confront new complexity. DMF says: what if we went all the way? What if there were no dedicated boxes, just software that runs anywhere, talks to anything, and gets orchestrated by some yet-to-be-perfected layer of intelligence?

He cites Sky Sports Extra as a proof point: 50% more live events without ballooning costs, made possible by cloud-scale elasticity. That’s a genuine win. And he’s right that the industry has always risen to meet big goals—we’ve done it with HD, with 4K, with IP itself. So why not this?

But here’s where I start to push back: those previous transitions had forcing functions. HD meant new cameras, new displays, new consumer demand. IP meant routers that couldn’t scale, infrastructure that couldn’t adapt. DMF doesn’t have that same inevitability. It’s being driven by a desire for efficiency and optionality—laudable, but not urgent in the way a format shift is. And without urgency, adoption gets patchy, standards fragment, and we end up with a dozen incompatible “software-defined” ecosystems.

The Reality: Orchestration is the Hard Part

Russell acknowledges the elephant in the room: orchestration. Who presses go? How do you make six different vendors’ software cooperate in real time? How do you guarantee frame-accurate timing when you’re dealing with containerised workloads on shared infrastructure?

His answer is MXL—the Media Exchange Layer—which is being developed openly on GitHub by a consortium of vendors. It’s a zero-latency, uncompressed way of passing video, audio, and metadata between processes on the same compute node. Think of it as shared memory for live production: trivial in concept, devilishly hard to standardise.

And timing? Russell admits that’s “always the hard bit.” That’s an understatement. Broadcast has spent decades building deterministic systems because live doesn’t tolerate slop. The moment you introduce shared infrastructure, cloud-native scheduling, and dynamic scaling, you introduce jitter, contention, and the possibility that your graphics engine gets starved of CPU because someone else’s transcode job spiked.

I’m not saying it’s unsolvable. I’m saying the industry hasn’t solved it yet, and until we do, DMF remains a concept rather than a deployment model.

The Cultural Shift: Are We Ready to Let Go?

There’s a deeper question here, and it’s not technical. It’s cultural. Broadcast is a control-oriented industry. We like knowing where the signal is, what box it’s going through, who owns it, and how to troubleshoot it at 3am when something goes wrong. DMF asks us to let go of that—to trust that the orchestration layer will do the right thing, that the software will behave, that the infrastructure will scale.

Russell talks about organisations needing to “be able and ready to deal with software”—to embrace containers, infrastructure as code, automated deployment. That’s a tall order for an industry where a lot of engineering teams still think in terms of hardware lifecycles and manually patched systems. The skills gap is real, and it’s not just about training people to use Kubernetes. It’s about rewiring the institutional muscle memory that says “if it’s mission-critical, it goes in a box.”

My Take: Optimism, Tempered by Pragmatism

So where does that leave us? I think DMF is the right direction of travel, but I’m not convinced the industry is ready to sprint. Russell’s optimism is infectious, and I respect the work being done by the EBU, AMWA, and vendors like TechEx to define these layers and make them interoperable. But I’ve seen too many “revolutionary” standards fizzle because adoption was optional and the pain of the status quo wasn’t acute enough.

What I’d like to see is a more honest conversation about the trade-offs. Yes, DMF promises flexibility and efficiency. But it also means dependency on orchestration intelligence that doesn’t fully exist yet, infrastructure skills that many organisations don’t have, and a loss of the tactile control that broadcast engineers have relied on for decades.

We’ll get there. But it’s going to be messier, slower, and more iterative than the pitch deck suggests. And that’s fine—broadcast has always been a pragmatic industry, not a utopian one. The question is whether we can build the bridge without falling into the gap between vision and reality.

If you’re interested in where this goes next, follow the MXL project on GitHub and keep an eye on what the joint EBU/AMWA task force does with DMF orchestration. And listen to the full conversation with Russell on the Broadcast Media: The Inside Track podcast—it’s worth your time, even if you come away as conflicted as I did.