Dynamic Media Facilities: Why DMF Matters & What’s Happening Now

If I were still working as a station engineer in Albuquerque, NM, and I heard people talking about Dynamic Media Facilities, I’d probably think: “Okay, what problem is this actually solving for me?”

Because from where I’d be standing, the facility might look fine at first glance. It’s doing what it was designed to do. I’ve built a workflow that supports the evening news, some local programming, and maybe production of a few commercial spots every now and then.

But when you really look at it, you start to notice the limitations. A lot of that expensive equipment is sitting idle most of the day. It’s there for the morning and evening newscast, but not much else. Or maybe there is a color corrector that only gets used every once in a while for commercial production.

And if you want to use the space for other purposes – let’s say to launch a high-end podcast, produce digital content, or reconfigure the space for a different kind of production – it may not make sense to go through the trouble of reconfiguration just to support a few extra production hours. Even though the facility has a lot of capability, it’s not optimized for what you need, or it is sitting idle. This is really the key point.

Even as more processing moves into software and servers, many of us are still thinking about it the old way, like we’re just replacing one box with another. But what broadcasters need now is something more flexible. You want to be able to chain together resources for different types of productions at different times, and you don’t want to pay for capabilities you don’t need.

That’s the pressure a lot of facilities are under right now. And that’s where Dynamic Media Facilities (DMF) comes in. Broadcast engineers are starting to ask: are our facilities actually working as efficiently as they could be?

What does a Dynamic Media Facility look like?

Instead of fixed, hardware-defined workflows, DMF introduces a fundamentally different model. As shown in the figure below, workflows are built from modular, autonomous functions. They perform one and only one function.  These atomic functions can be chained together to create different workflows. Because resources are shared, not dedicated, facilities can be reconfigured on demand. That means the same space can produce a commercial in the morning, switch to a podcast in the afternoon, and run the evening news at night, drawing the appropriate resources from a pool, and then orchestrating the workflow you need, when you need it. No more expensive equipment sitting idle most of the day. 

You only use what you actually need. Instead of investing in dedicated CAPEX hardware, DMF uses resources mostly on a SaaS basis:

• Available on demand

• Invisible when not in use

• Scalable up or down 

• Scheduled as needed

The missing pieces: interoperability and orchestration

Once you move into a world of software-based processing, shared compute, IP-connected devices, and dynamic workflows, the challenge isn’t just having the resources. It’s knowing what’s available, where it is, what it does, whether it’s in use or can be scheduled, and how it connects to the rest of the signal chain.

If you’re going to build a facility that can shift dynamically from one workflow to another, you need a way to automatically discover, identify, and connect the right resources every time. Interoperability and orchestration become essential. You can’t rely on custom integrations and one-off vendor silos when dealing with a large number of endpoints and fluid workflows.

You need a common way to discover resources, call up the right function, connect workflow components dynamically, and do it all in a way that works across systems and vendors. You need to be sure you don’t spin up functions that consume more compute resources than you have available, and you also need a way to keep things synchronized across the workflows you create.  These are exactly the problems the JT-DMF is tackling.

A word about MXL and DMF

While MXL has attracted significant attention in recent months, it represents just one piece within a much broader industry effort: DMF. The real story is the growing collaboration around Dynamic Media Facility, where broadcasters, vendors, and systems integrators are working together to define the interoperable frameworks that will underpin the next generation of media infrastructure. MXL is a critical building block, but DMF is the bigger picture that’s being developed.

Joint Task Force on Dynamic Media Facilities (JT-DMF)

A joint project between the Advanced Media Workflow Association (AMWA) and the European Broadcasting Union (EBU), JT-DMF brings together broadcasters, vendors, and systems integrators to work toward a shared goal: Make dynamic media facilities real and interoperable.

The JT-DMF aims to answer questions like: how do you share production resources on a common compute instance, or across instances? How do you connect a flow coming out of one software application to the input of the next function in the chain?  How do you preserve timing in these software-only, faster-than-realtime environments? What does orchestration look like? What are the core pieces? Is there a common approach across the industry that makes sense?

To make DMF possible, major industry players including broadcasters and vendors are coming together via the JT-DMF to actively shape the conversation in 4 critical areas:

1. End-to-End Synchronization Working Group

Creating a unified model for timing and synchronization across dynamic, distributed facilities.

2. Flow Connection Working Group

Establishing how media flows are discovered, described, negotiated, and connected within a dynamic environment.

3. Compute Resources Management Working Group

Defining how compute, storage, networking, and specialized media functions can be provisioned, orchestrated, scaled, and released.

4. Business Track 

Identifying the business drivers, commercial models, and organizational changes required to adopt dynamic media architectures.

Where JT-DMF stands right now (and why it matters)

• Initially, there was a meeting held at the CBC to bring together interested parties and determine what shape developments might take. 
  

• Technical groups known as “tiger teams” met several times and were looking to find key technical points.
  

• The Joint Task Force was formed in the fall of 2025 in Geneva with a kick off meeting.
  

• JT-DMF Working Groups started to organize in the beginning of 2026.  
  

• The first version of MXL, the media exchange layer, was released at the Video Services Forum (VSF) meeting in February 2026. 
  

• In March of 2026, the first meeting of the JT-DMF in the United States was held at the Paramount offices in New York City. 
  

• The second version of the DMF Reference Architecture will be released by the EBU.
  

• In June of 2026, there was a face-to-face JT-DMF in Geneva at the EBU. 
  

• See the latest DMF info and talk with subject matter experts at the AMWA demo area on the EBU's stand at IBC. Details to follow.

You can be a part of the shared vision of DMF. Open questions around how DMF works, what challenges it can solve, and who stands to benefit from it are being shaped now. 

JT-DMF is the organization answering those questions and shaping the vision. If you want to be a part of those conversations, now’s the time to get involved.

Momentum is building. Whether you work for a vendor, systems integrator, or end user, the shift to software-defined infrastructure is already underway. The move toward dynamic facilities is not theoretical. It’s inevitable and it’s happening now. 

Are you ready to join the conversation?

Get involved in a JT-DMF working group by joining AMWA. AMWA members can join and contribute to any technical or business working groups. For membership info or to join, contact cindyz@AMWA.tv.