By Padraig O’Donovan, CEO and Co-Founder, Layercake
The industry has agreed on a map of where media production is going. Yet almost all the attention is on only one layer of it. This is a survey of what the architecture’s authors, the vendors building against it, and the trade press covering it keep saying about another layer, the one that decides whether the map works – and what we have learned running that layer in production.
In April, the EBU published version 2 of its Dynamic Media Facility (DMF) reference architecture. The first item in its own account of what had changed was not the transport layer (the MXL) that dominates the industry’s conversation. It was orchestration: “rather than treating it as an implicit or loosely defined function,” the EBU wrote, “orchestration is now formally defined as something that spans multiple layers of the Dynamic Media Facility, interacting with different components across the workflow.”
The architecture’s own authors moved orchestration to the front of their update. And they were right to: orchestration is the layer that decides whether your facility is dynamic at all, and the vendors and editors covering the DMF have spent a year converging on the same conclusion.
The DMF is the clearest map the industry has of where production infrastructure is going: six software-defined layers running on general-purpose compute – on premises, at a remote site, or in any cloud – with technology and configuration chosen independently at each layer. Most of the conversation about that map is about one layer of it. The Media eXchange Layer (MXL), moves media between software functions sharing compute. It is open source, well governed, and it deserves the attention it gets. SVG Europe’s Paul Markham found the right image for it: “If DMF is the facility, MXL is the cabling.”
The cabling decides how well media moves. Something else decides whether the facility can be built on Tuesday morning, torn down on Tuesday night, and rebuilt in a different shape, possibly in a different cloud, for Wednesday and then again for the weekend.
Four concerns cut through every layer
Alongside the six horizontal layers, the model defines four concerns that cut vertically through every one of them: Orchestration, Control, Monitoring and Security. Version 2 draws a sharper boundary around the first than version 1 did, and its definition is precise. Orchestration “creates and destroys resources in each layer and configures resources so they can be controlled and monitored. It ensures that availability and resilience requirements are fulfilled and uses an Infrastructure as Code (IaC) approach for consistency and reusability.”
Read that definition with a production in mind.
- Reserve the capacity.
- Deploy the infrastructure.
- Deploy the hosts.
- Deploy the containers.
- Create the media flows.
- Configure the functions.
- Run the show.
Then tear all of it down and hand the capacity back.
None of that work belongs to a transport layer, and none of it belongs to a production platform. It is its own concern, with its own model, spanning the entire stack.
The industry has been saying this out loud
The vendor voices that have published on the DMF over the past year keep converging on the same layer. Read together, their statements make one argument.
John Mailhot, SVP of product management at Imagine Communications, told NewscastStudio’s roundtable on the DMF in June: “The DMF model is shifting the industry’s focus toward workflow deployment (orchestration), resource management, and workload flexibility across the entire media operation.”
Paul Briscoe, chief architect at TAG Video Systems, in the same roundtable: “MXL’s real power isn’t as a transport layer in isolation, it emerges when combined with DMF’s resource orchestration to build fluid, best-of-breed solutions.” His description of the destination is worth quoting in full, because it describes a working day rather than an architecture diagram: workflows built “from resources that are persistent, on-demand, or mixed, orchestrated per job and released when done.”
Chris Scheck at Lawo describes the same operational rhythm: operators starting and stopping the apps they need for the next project, a “build-up/tear-down strategy” that “can be performed several times a day with a multitude of processing apps.”
Adam Marshall, chief product officer at Grass Valley, frames it at the level I think matters most: “DMF is helping shift the conversation away from individual products and towards the operating model of the facility itself. It’s encouraging organizations to think more holistically about orchestration, control, observability and security across a multi-vendor environment, rather than treating each workflow as a separate integration project.”
Russell Trafford-Jones at Techex names what has to happen next: “The industry needs mature orchestration, consistent monitoring and proven interoperability between independently procured vendor products, because that is what turns a good idea into infrastructure rather than another clever booth demo.”
And the editorial view has landed in the same place. SVG Europe’s January assessment of the vendors building against the architecture put it plainly: “MXL is an enabling layer rather than a complete production system. The real leverage sits in orchestration and workflow control.” The same analysis notes that MXL is deliberately scoped to the media plane – control, lifecycle management and workflow coordination are left to the layers above.
There is a cautionary voice worth including, because it is the freshest one. Richard Jonker of Netgear, writing in SVG Europe this month, warns that “momentum and readiness are not the same thing,” and that the industry has a habit of getting excited about the upper floors of a new architecture before checking the foundations. He is right to say it, and the honest response is not another architecture diagram. It is evidence of the thing running. I will come to that.
Static infrastructure does not stop being static because it is virtual
There is however a trap.
You can containerise every media function in your building. You can run them on commodity servers. You can move media between them over a shared-memory fabric at very low latency. And if the compute those functions run on is provisioned once, sized for your busiest day, and left switched on, you have not built a dynamic facility. You have built a conventional facility out of software.
The dynamism lives in what creates and destroys those containers – how often, how quickly, and across how many places.
This is why the orchestration question deserves to be settled before the transport question, not after. A facility with brilliant media exchange and manual provisioning is a static facility with excellent cabling. A facility whose whole lifecycle is orchestrated – built for the production, kept resilient through it, reclaimed after it – is dynamic whatever its fabric.
What the job looks like in practice
Streamcake, our platform, holds a Profile: a recipe describing the workflows and resources a production needs. Schedule that Profile against an event and Streamcake reserves the capacity, provisions the compute on whichever ‘cloud’ you are using (your own servers or someone else’s), deploys the templated media stack, configures it, connects the flows, and hands you a running facility.
While the show runs, it keeps the facility up. If capacity fails, it fails over automatically – hunting region, then availability zone, then provider, until it has what the production needs. At that point in the schedule there is nobody to ask, so it does not ask.
When the show ends, it takes the facility down and stops the meter.
Then it does it again tomorrow, for a different production, with a different shape.
Creating infrastructure is the easy half of that job. Plenty of tools can stand things up. Destroying a facility reliably – on schedule, across providers, without stranding storage or leaving an instance running in a region nobody is watching – is the half that decides your bill, and it is the least glamorous code in the whole stack. The EBU’s definition puts creation and destruction in the same sentence for a reason.
The saving the cost debate keeps stepping over
The largest saving a dynamic facility offers is the one the published cost debate keeps stepping over: the facility not existing between productions.
There is a serious conversation in the trade press about whether any of this saves money. NewscastStudio framed it exactly right in June, asking whether, for CFOs and procurement teams, adopting the framework will “reduce what a facility spends, increase it or simply move costs from one column to another.” The answers on offer have been consistent: reduce waste, avoid unnecessary copies and handoffs, avoid duplicated processing, stop sizing every purchase for the busiest day. All true. And all of it is about using infrastructure more efficiently while it is running.
The word dynamic points at something larger: the facility exists while the production needs it, and not otherwise. Spin it up for the match. Run the match. Tear it down. Pay for the match. The difference is between trimming a bill and not receiving one.
In our production deployments, that structure cuts infrastructure cost by 20 to 90 per cent. The range is wide because the saving is not a rate – it is a function of how much of the year your facility does not need to exist. A continuously running channel saves at the low end. Seasonal sport, occasional live events, a schedule with peaks and long gaps: those save at the high end, because the facility spends most of the year not existing.
The question worth taking to your finance team: what are you currently paying for capacity that is doing nothing?
Choose your fabric, keep your orchestrator
You do not have to answer the transport question to get started, because orchestration sits above it. Orchestration is a vertical concern; transport is a horizontal layer; they are at right angles.
The fear of committing to a transport that does not win is reasonable, and the architecture itself refuses to pick a side: it places a transport abstraction beneath the exchange layer and names shared-memory DMA, RDMA and cloud-vendor fabrics side by side beneath it. Ciro Noronha, CTO at Cobalt Digital, has made the complementary point that MXL and ST 2110 “are not in competition and have different purposes.” And NewscastStudio’s own analysis of the transition concluded that “the next infrastructure model will probably not arrive as a clean break from the last one. It will be layered on top of existing systems, with different technologies handling different parts of the workflow.”
Whatever your facility uses to move pixels – MXL shared memory, a cloud backplane, NDI, hybrid ST 2110 – something still has to build the facility, keep it alive, and take it down. [DR5]
Where we stand, honestly
Streamcake orchestrates the facility lifecycle the DMF describes, and it is the only thing it has ever done.
No other product has been built from the ground up for a dynamic media facility across both ground and cloud. The other platforms reaching for this ground arrived from adjacent jobs – monitoring and estate management, scheduling, production platforms – and they carry the shape of where they came from. That is no slight on them. But there is a real difference between a system that learned to provision and one designed around the assumption that the facility does not exist yet.
And to Jonker’s fair challenge – momentum is not readiness – the answer is production history, not promises. The QRL season: 430 matches, contract to live in under a month, one operator. GPSQLD.TV: live in ten days. Wiistream: more than 3,000 games streamed across a single weekend, 110 running at once.
Streamcake is cloud-agnostic across your own on-prem ‘cloud’, private data centre based ‘clouds’, AWS, Azure, Google Cloud, Oracle Cloud, Akamai Cloud, and connects more than forty vendor brands and hundreds of service integrations. None of it is roadmap. It has been running for years.
Kubernetes, since someone always asks: Kubernetes orchestrates containers on a cluster, and the DMF rightly puts a container platform in its stack. But a media facility is more than containers on one cluster. It is infrastructure, hosts, media functions, deployment, failover across regions and providers, and teardown when the show ends. The EBU model separates container orchestration from facility orchestration because they are different jobs. Streamcake does the facility.
The question to settle early
If you are mapping your facility to the DMF, the transport question will take most of the meeting time this IBC. The architecture’s authors, the vendors building against it, and the editors covering it have spent a year pointing at a different layer that should come first.
Settle this question first:
What is going to build your facility, keep it alive, and make it dynamic enough to take advantage of the benefits a Dynamic Media Facility can provide?
Streamcake, by Layercake. Camera to consumer. That’s Dynamic.