
In my previous article, we examined how the European Broadcasting Union’s Dynamic Media Facility (DMF) reimagines broadcast infrastructure as a software-defined, vendor-agnostic facility – and how the Media eXchange Layer (MXL) provides its technical glue.
That vision sounds compelling. But for sports broadcasters planning future live operations, the more pressing question is practical rather than architectural: is anyone actually building this yet?
DMF and MXL are ambitious. They ask vendors to rethink decades of product design, shifting away from monolithic hardware and closed internal pipelines towards micro-services, shared media exchange and open interoperability. That’s a profound change, affecting not just engineering choices but commercial models, product roadmaps and operational culture.
“Specialist functions – including AI-driven highlights, object-based graphics and multi-language generation – could integrate directly into shared MXL environments, enabling a more open marketplace of media functions”
Let’s examine the emerging vendor ecosystem around DMF and MXL, the state of early products and prototypes, and what broadcasters can realistically expect over the next 12-24 months.
A collaborative push, not a top-down mandate
One of the strengths of this initiative is the collaborative pedigree brought by the EBU. This is not a prescriptive product specification imposed from above, but an architectural direction shaped by the broadcasters who expect to deploy it.
The broadcasters publicly involved include the BBC, CBC/Radio-Canada, France Télévisions, VRT, SVT, SRG SSR, RTÉ, Bell Media and Olympic Broadcasting Services. Collectively, these organisations bring deep engineering capability and real operational pressure from live sport, news and events.
EBU Technology & Innovation presentations indicate several members are moving into DMF pilot work, with MXL intended as the internal exchange layer. This early alignment matters: vendors respond when customers present a clear, shared direction.
Although MXL remains early in its lifecycle, a number of technology suppliers have already signalled intent or active participation.
Grass Valley’s AMPP platform already embodies many DMF principles – micro-services, orchestration, hybrid deployment – and company leadership has publicly described MXL as a potential foundation for future interoperability between media functions. Internal R&D demonstrations integrating MXL libraries into AMPP components have been shown in controlled environments.
Intel and NVIDIA are participating to help MXL’s data model and memory-exchange semantics take advantage of modern CPU, GPU and acceleration capabilities.
Matrox Video is aligning its Origin Fabric SDK with the EBU’s DMF vision. Appear is integrating MXL architectural principles into its VX software platform. Lawo and Riedel are exploring how MXL could be applied within software-defined processing workflows. AWS has participated in DMF workshops.
Read more From stadium to studio: Appear’s Ian Wagdin explains how DMF and MXL enable software-defined video
Alongside established vendors, a number of specialist companies – spanning AI, live clipping, vision mixing and sports data – are evaluating the SDK as an opportunity to integrate directly with broadcasters’ emerging DMF environments.
Why the MXL SDK matters
The release of the open-source MXL SDK under Linux Foundation governance has been the single biggest accelerator of vendor engagement. By providing a shared implementation of grain structures, transport abstractions, timing models and reference components, the SDK removes the need for vendors to interpret the architecture independently, and ensures interoperability is anchored in shared open foundations – mitigating the risk of proprietary interpretations.
MXL is deliberately focused on the media plane, not orchestration or business logic. Control, lifecycle management and workflow coordination remain the responsibility of higher-level frameworks – whether vendor platforms, Kubernetes-native tooling, AMWA NMOS, NBMP, or broadcaster-defined control planes. This separation of concerns is intentional and helps mitigate the risk of MXL becoming another monolithic standard.
Single-vendor risk in the DMF/MXL ecosystem
As adoption of the EBU’s Dynamic Media Facility (DMF) and Media eXchange Layer (MXL) grows, some broadcasters and vendors are asking whether the ecosystem could become dominated by a single platform provider, potentially discouraging wider participation.
MXL is an enabling layer rather than a complete production system. The real leverage sits in orchestration and workflow control, where larger software platforms naturally have an advantage. Some major vendors, including Grass Valley, have moved early and visibly, helping to turn DMF from theory into practice.
That leadership is valuable, but platform gravity is real. If MXL is perceived as working best inside one ecosystem, other suppliers may question the return on investing in native support.
The EBU is conscious of this risk. MXL is governed as an open-source project under the Linux Foundation, with broadcasters driving requirements and multi-vendor interoperability a stated goal.
Ultimately, the test will be whether MXL enables genuine long-term choice – with multiple platforms, mixed-vendor deployments and independent validation – rather than becoming synonymous with any single implementation.
What exists today – and what doesn’t
As of January 2026, no major broadcast vendor is yet shipping a fully MXL-native commercial product.
What does exist today falls into three broad categories. First are R&D and lab-based prototypes, demonstrated at events such as IBC and NAB, where broadcasters and vendors have shown media functions exchanging grain-based video via MXL, graphics overlays running as isolated micro-services, and replay or multiviewer components sharing frames in memory. These demonstrations validate the technical model, but aren’t production systems.
Second are hybrid implementations, where vendors use aspects of MXL internally within their platforms while continuing to expose traditional IP or API interfaces externally. Early examples include cloud-based switching or replay functions explored in R&D environments using MXL for internal media exchange, monitoring tools ingesting grains from MXL-enabled functions, and edge appliances capable of feeding media into MXL-based processing clusters.
Third is infrastructure alignment. Vendors supplying compute, networking and virtualisation layers are adapting their products to support NUMA-aware memory sharing, RDMA-capable networking, high-bandwidth internal fabrics, and compatibility with NMOS and PTP-based timing. This groundwork is essential before higher-level media applications can scale reliably.
For most broadcasters, DMF and MXL will not replace existing facilities wholesale. Instead, they will be layered in gradually – first around specific workflows, then around clusters of functions, and only later as a broader architectural foundation. Hybrid operation is not a temporary compromise but an expected operating mode for much of the next decade.
Vendor roadmaps and what broadcasters should expect next
Most suppliers describe a broadly similar, phased roadmap that aligns with the EBU’s own expectations. The near term is focused on prototypes, SDK experimentation and interop testing. During 2026, partial commercialisation is expected, with products beginning to expose MXL-compatible interfaces alongside existing ST 2110 and SRT workflows. Broadcasters are likely to deploy MXL initially around discrete live tasks such as clipping, multi-angle replay or graphics processing.
By 2027 and beyond, the ambition is for full multi-vendor MXL clusters operating in production, with broadcasters running multiple DMF workloads concurrently across live, editorial and distribution environments. At that point, specialist functions – including AI-driven highlights, object-based graphics and multi-language generation – could integrate directly into shared MXL environments, enabling a more open marketplace of media functions.
This timeline is ambitious, but it mirrors the pace of cloud-native transformation seen in other software-driven industries.
It’s likely that hybrid environments will mix MXL-enabled software functions with conventional IP devices. Close collaboration between broadcaster engineering teams and vendor architects will be essential, as will a willingness to iterate quickly and accept some early gaps in tooling around orchestration, timing and monitoring.
Those early experiments, however, will define the reference implementations others follow.
From concept to product
DMF and MXL are not yet a mature commercial ecosystem. But they have passed a critical inflection point: broadcasters are committing, vendors are investing, open-source foundations are in place, and pilot deployments are underway. The industry is now moving from concept validation to productisation.
The final article in this series will examine CBC’s plans for the 2026 Milano Cortina Olympics – not as a full DMF deployment, but as a realistic, high-pressure proving ground. Large-scale live sport is where architectural theory meets operational reality, and Milan Cortina will be one of the first opportunities to see how DMF principles and MXL-based media exchange perform under genuine broadcast constraints.
Read more:
Part 2: DMF and MXL in practice: Which vendors are adopting it, and how fast is the ecosystem maturing?