Dynamic Media Facility (DMF) Explained: Myths vs Reality

By Andy Rayner, CTO, Appear

I hear the same mix-up constantly: people treat Dynamic Media Facility (DMF) and Media eXchange Layer (MXL) as more or less the same thing. They’re not, and the difference between them matters more than the acronym soup suggests. MXL is effectively an intra-compute media data ‘connector’. DMF is the total vision for a whole facility, of which the MXL connector is a small but highly essential component.

One of my industry roles is chairing the timing working group within the Joint Task Force for the DMF—a collaboration between AMWA and the EBU—so I spend some of my working life in this area. Here’s what I think is actually true about DMF, where MXL fits inside it, and why the parts of this that get the least attention (timing, in particular) are the parts that decide whether any of it works in production.

The principle behind DMF

The EBU has been developing the Dynamic Media Facility concept for a bit over three years now, and the reasoning behind it is straightforward once you see it. Most live production tooling is moving to software because standard IT infrastructure has finally become powerful and feature-rich enough to do the job—that’s genuinely new; it wasn’t true ten years ago. At the same time, a traditional broadcast facility is full of physical infrastructure that, outside a 24/7 playout chain, sits idle most of the time. Sports production is the clearest example: across a full week, the hours you’re actually using peak production capacity are a small fraction of the total.

The “dynamic” in Dynamic Media Facility is the response to that: build your live production workflow virtually for the period you actually need it, then collapse it again. Buy and operate infrastructure for your steady-state baseline—the always-on stuff, playout, the workload that’s cheapest to run on owned hardware—and flex everything event-driven or occasional on top of that baseline, spinning capacity up for the duration and releasing it afterwards. Anyone who has watched a broadcaster’s production demand spike for a single major event and go quiet again the rest of the year has seen the exact problem this is solving.

That doesn’t mean DMF is a cloud story specifically. It means it’s largely a software story. In practice, most of the organisations I talk to end up hosting a hybrid: private compute sized for the baseline load plus some margin, and hyperscaler capacity for the flex above that, because that combination is usually the most cost-effective way to get both reliability and headroom. Some of that flex capacity might not even come from a traditional hyperscaler — pooled or shared compute between organisations, or capacity offered by a network or service provider, are both plausible models as this matures.

Why “hybrid” means two different things here

I use the word hybrid constantly when I talk about this, and I’ve started calling it a double hybrid deliberately, because it’s answering two separate questions.

The first is where you host the software: private infrastructure, hyperscaler cloud, or a mix. The second is a completely different axis—hardware appliances versus software—and I don’t think that one resolves to “software wins” the way some of the industry conversation implies. Wherever an event is happening, you still need to gather, compress, and transport feeds back to wherever your compute lives, and that job is always going to want space and power-efficient dedicated hardware, like Appear’s X Platform. DMF doesn’t eliminate that requirement; it starts once those signals have reached the compute domain. Everything upstream of that—cameras, microphones, the collection and contribution hardware—still matters, which is one reason the Joint Task Force’s scope deliberately reaches back to origination rather than stopping at the compute boundary. Stay narrow and you end up solving half the problem.

The double hybrid, two separate questions

Where you host the software

• Options: private infrastructure, hyperscaler cloud, or a mix
• Driver: steady-state baseline sized to owned hardware, with event-driven flex capacity on top

Hardware appliances vs software

• Upstream of compute: gathering, compressing, and transporting feeds still wants space- and power-efficient dedicated hardware
• Inside the compute domain: this is where DMF and MXL operate — software governs once signals have arrived

Where MXL actually fits

MXL—the Media eXchange Layer—was the first piece of the DMF vision to get a concrete technical definition, which I think is part of why people conflate the two. It’s an accurate but incomplete impression. Think of MXL as the interconnect between software media functions running inside the compute domain—the software-world’s equivalent of a BNC connector. It’s important, and it’s the piece that made a lot of the recent multi-vendor interoperability demonstrations possible. It is not the Dynamic Media Facility. It’s one component inside it, developed as its own open-source project under the Linux Foundation, with requirements and guidance flowing from the DMF work but built as a separate effort.

It’s also not a replacement for ST 2110, and I push back on any framing that implies it is. The future here is genuinely hybrid, not a migration away from linear connectivity. Outside the compute domain—getting signals to and from a venue, connecting facilities, everything that isn’t happening inside a piece of compute—2110, SDI, and similar linear technologies aren’t going anywhere. MXL is what happens once you’re inside compute. Those are two different jobs, and the industry needs both done well, not one replacing the other.

The four things the Joint Task Force is actually working on

The JT-DMF was proposed at IBC last year and has been running for roughly twelve months. In that time, four working groups have each produced a couple of iterations of thinking, and mine is starting its third:

• Timing—end-to-end timing, from the camera and microphone through the compute domain and back out again. Mine, and the one I’ll come back to below.
• Resource management—understanding what compute resources a given media function actually needs, so an operator can know with confidence whether the capacity they have can run what they’re trying to deploy.
• Flow management and connection—the software equivalent of what NMOS did for ST 2110. In the physical world, 2110 was the connector and NMOS was how you configured it; this working group is building the analogous discovery and connection layer for software media functions. AI tooling can sit on top of that once it exists—you can use agentic tooling to drive orchestration—but it still needs standard, well-defined ways of addressing media functions to learn from. The tooling doesn’t remove the need for the standard; it depends on it.
• Business models—the honest one. Open-source tooling already does a lot of this well. I run a full live production every Sunday at my church on OBS Studio—seven cameras, graphics overlay, logo insertion—at zero software cost. So the real question the industry has to answer is what customers are actually paying for. My colleague Ian put it well: you’re paying for roadmap and support—for a guaranteed path to keeping something running, and a say in where the product goes next, not features you couldn’t get elsewhere at all.

Security threads through every one of these, and I think the industry’s job here is mostly restraint: don’t reinvent what IT security has already solved well. Zero Trust and equivalent practices are mature, well understood, and battle-tested outside broadcast. Our job is to make sure those principles are baked into how we build media functions, not to invent a parallel broadcast-specific security model that’s inevitably going to be weaker than what already exists.

The four Joint Task Force working groups at a glance

Working group	What it’s defining	Why it matters
Timing	End-to-end timing, from camera and microphone through the compute domain and back out again	Nothing else in DMF works without it
Resource management	What compute resources a given media function actually needs	Lets an operator know with confidence whether their capacity can run what they’re trying to deploy
Flow management and connection	The software equivalent of what NMOS did for ST 2110	Gives agentic orchestration tooling standard, well-defined ways of addressing media functions to learn from
Business models	What customers are actually paying for, given how much open-source tooling already does well	Roadmap and support — a guaranteed path to keeping something running, and a say in where the product goes next

What’s actually changed in the last year

Concretely: the Joint Task Force didn’t exist a year ago. It does now, with four + working groups each several iterations into defining real requirements. On the vendor side, we’ve gone from an early MXL prototype to being close to shipping it as a standard part of the VX toolkit—and I don’t think we’re unusual in that; most vendors I talk to have made a similar journey from proof-of-concept to working integration over the same period. What that gives us, practically, is components that are legitimately interoperable within a Dynamic Media Facility, demonstrated live at IBC2026 alongside multiple other vendors’ software.

What it doesn’t give the industry yet is a full solution on orchestration. We’re defining the APIs an orchestration layer would need, but there’s a real open question underneath that about how that function is fully realised. Systems integrators historically pulled together appliances from different vendors into a working facility; in a software world, that role is shifting toward instantiating and orchestrating software tools instead, and some organisations are building that capability themselves rather than waiting for a vendor to hand it to them. NEP Group’s own orchestration platform, launched this year to unify multiple vendors’ production applications inside NEP’s facilities, is a good public example of that shift already happening. We have a lot of software tools in the control space, as do others, and there is definitely consensus building on how to approach this holistically, but I don’t see there is a single right answer yet, and I’d be suspicious of anyone who claims a fully complete solution this early.

Timing: the part that decides whether any of this actually works

This is the part of DMF I have been most involved in, and I think it’s the least discussed relative to how much it matters. The headline principle my working group has been defining is this: the preservation of timing relationships between media signals throughout a live production workflow is the foundation of a functioning DMF. Everything else is easier to get excited about. Nothing else works without this.

Here’s the shift that makes timing hard in a software-defined facility. Linear broadcast connectivity has worked like a hosepipe for ninety years: a constant flow, moving at whatever rate the signal moves. Compute doesn’t work that way. Compute handles data in discrete chunks—grab a block, process it, move it on—and it can do that much faster than real time if you let it. Software’s old reputation for adding latency mostly comes from forcing it to behave like a hosepipe: serialising, buffering, re-serialising, over and over, to imitate a constant flow it was never built to produce natively. Let compute do what it’s actually good at—process asynchronously, as fast as it can—and a lot of that latency disappears rather than accumulates.

That’s also why we talk about “conform on ingress” as a working mantra. Every external signal entering the compute live production domain—from a remote site, from an X-series unit at the edge, from wherever—gets conformed to a known, uniform timing domain right at the boundary. Once that’s done, everything downstream inside the software facility can rely on that consistency instead of re-checking it at every step.

Timing doesn’t stop being a design consideration once you’re inside compute—it just changes shape. A useful way to think about it: your point of acquisition (cameras and microphones) is time zero. From there, every stage—vision switching, audio processing, a remote control surface if you’re running a distributed or REMI-style production, a multilingual commentator sitting in a different country, a contractually mandated profanity delay—adds its own latency, deliberately or otherwise. Add them up and you get a “final channel playout time” that might be a handful of frames after acquisition in a tight, local production, or several seconds later in a complex one with remote commentary and delay built in. Defining those points precisely, and how they compose, is a meaningful part of what my working group is doing right now—and it’s involved enough that it deserves its own dedicated piece rather than a few paragraphs here. We’ll go deeper on it soon.

Where this leaves the industry

I think the honest summary is this: DMF is a genuine, well-reasoned response to compute finally being capable enough to run live production, and to how badly most facilities’ physical infrastructure gets used outside their peak moments. MXL is a real and useful piece of making that vision work, but it’s a small piece—a virtual media connector. The parts that will actually determine whether DMF delivers on its promise are the less glamorous ones: resource management, flow discovery and control, honest business models, security done properly rather than reinvented, and—the one I’d bet on mattering most—getting timing right end to end, not just inside the compute box but from the camera all the way to final playout.

Appear’s role in this isn’t to declare the vision finished. It’s to keep doing the unglamorous, practical work of making it real—which is what being part of the Joint Task Force, and building toward these standards in VX, actually is.

Frequently asked questions

Is DMF the same thing as MXL? No. MXL (the Media eXchange Layer) is the interconnect between software media functions inside the compute domain—a small but highly important component of the Dynamic Media Facility. DMF’s scope is much broader, reaching back to origination (cameras, microphones, contribution hardware) and covering resource management, flow discovery, business models, and timing, in addition to media exchange.

Does MXL replace ST 2110 or SDI? No. MXL operates inside the compute domain, exchanging media between software functions. Linear connectivity technologies like ST 2110 and SDI continue to handle everything outside compute—getting signals to and from venues, between facilities. The future is both, not a replacement of one by the other.

Who is developing the Dynamic Media Facility? The Joint Task Force for the Dynamic Media Facility, a collaboration between AMWA and the EBU, proposed at IBC2025 and running for roughly a year. It’s organised into four working groups: timing, resource management, flow management and connection, and business models.

Why does timing matter so much in software-defined production? Because compute doesn’t move data the way linear broadcast infrastructure does. Preserving accurate timing relationships between signals—from acquisition through every processing step to final playout—is the foundation a functioning Dynamic Media Facility is built on; without it, none of the interoperability or flexibility benefits are usable in a real production.

Andy Rayner is CTO at Appear, and chairs the timing working group within the Joint Task Force for the Dynamic Media Facility (AMWA/EBU). He was previously closely involved in defining the timing model within SMPTE ST 2110.