How best to optimise the use of technology in the containerised media production environments that are now emerging is on the mind of many broadcast vendors and organisations these days, including the European Broadcasting Union (EBU). Beginning with a white paper in April 2023, the EBU has been developing an initiative, Dynamic Media Facility (DMF), which aims to explore how future media productions can benefit from “highly flexible and dynamic technology approaches”.
A central aim of the project is the development of a Reference Architecture that offers a structured framework for users to express and evaluate their requirements using common models, interfaces and terminology. The intention is that this will help guide the adoption of relevant technologies and practices from the broader IT landscape, while also highlighting areas where alignment on shared solutions can reduce redundant effort and remove barriers to flexibility—ultimately allowing the media industry to focus on what really adds value to its products.
There are many facets to the DMF project, but in recent weeks, the EBU has announced that one of the “key enablers” has reached fruition. The Media eXchange Layer (MXL) is a code package that standardises how media processing functions in virtualised environments can share and exchange data with each other. Essentially providing the “virtualised cabling”, MXL will facilitate the DMF vision of supplanting individual hardware boxes with virtual containers running on local servers or, as is becoming increasingly habitual, the cloud.
Focusing on function
The first conversations about the project that became DMF took place three years ago at an EBU meeting in Brussels. “We had this bow-tie diagram with the media function as the dot and everything in the wings,” recalls Willem Vermost, senior media technology architect at the EBU. “We realised that a lot of time is spent discussing metadata schemes and various specific details, but they may not bring a lot of value. Instead, the value is actually when you change your media, and that [stems from] the media function. So we saw that if you look at it from a very granular point of view, and you then start connecting those bubbles as a graph, you can create a process flow which serves as your media workflow.”
There was also a recognition that lessons could be learned from the adoption of SMPTE ST 2110. “When people started to build their own 2110 stacks, including the packet pacing [regulating the rate at which data packets are sent to avoid network congestion and enhance performance], you had to do a lot of interoperability tests before you could be sure that everybody was compatible,” says Vermost. “But if you had all these media functions running in a compute exchanging media with each other through one shared SDK, you wouldn’t have to do interoperability testing on this layer anymore—saving a lot time and money.”
Ultimately, it was determined that the reference architecture would need to comprise “three major blocks: one at the bottom which talks about IT architectures that we’re not allowed to touch because this is what we want to get from the IT industry; the layers on top which are essentially the media infrastructure; and then a third block which includes the aspects that cut across all the layers, such as discovery, monitoring and security.”
The greatest value
A meeting in Geneva in November 2024 was instrumental in determining that MXL should be the next focus of activity. “It was agreed upon that the media exchange layer was the first thing that would bring the greatest value to everyone,” recalls Vermost. “There were also plenty of voices saying that it would only work if it’s open source and everybody can use it. So the challenge then was to create a community that could write code, within a framework that allowed everyone to work safely.”
Subsequently, a meeting at CBC/Radio-Canada earlier this year led to the Linux Foundation and the North American Broadcasting Association (NABA) becoming closely involved with the development of MXL. Rebecca Hanson, director-general of NABA, recalls: “This project was brought to us by Felix Poulin of the CBC, a member of NABA. He briefed our Technical Committee numerous times and generated a fair amount of interest. This prompted us to sign an MOU with the EBU regarding how we can support the project, including recruiting North American broadcasters for input.”
As to how NABA hopes MXL will help improve and streamline workflows in the future, Hanson responds: “I think of the greatest interest to NABA members is maximising flexibility and interoperability. This core ‘value’ will provide broadcasters with the ultimate freedom to customise their facilities to their specific needs, and to provide options among vendors.”
Rails for an ecosystem
The resulting code package is now available via Github (link here). In the words of the EBU, it provides “an open framework for real-time ‘in memory’ media exchange that allows seamless integration across compute nodes, production clusters and broadcast platforms. In essence, it is the rails for an ecosystem, and their use is free of charge.”
In terms of the roadmap for MXL, Vermost says that “the charter of this particular project is agreed upon. Within the charter, there’s a technical steering committee—comprising the people who are actually writing the code—that is also tasked with creating a user requirements committee.” Several workshops and seminars are also on the schedule, after which it is hoped that people will “contribute to the code, look at the code, download the code, and use it.”
In the case of NABA members—most of which are large, multi-station broadcast groups—it seems likely that deployment will occur primarily within cloud-based deployments. “Most are well on their way to moving to the cloud,” says Hanson. “Regarding the DMF/MXL initiative, they are really only starting to get involved now. Since the technical steering committee has completed their initial work and the code is now publicly available, now is the time for broadcasters to share their functional requirements ‘wish list’ so that the effort truly works for broadcasters and isn’t purely vendor-driven.”
Next steps
Whilst MXL is an important part of the DMF project, there are still many other aspects to be addressed, not least connectivity between the virtualised containers. “We need to include at least discovery, registration and connection capabilities; all those things you require to be able to connect your media functions and have them point to the right location in memory to exchange media flows and so on,” says Vermost.
It’s possible that existing specifications from NMOS could provide some of the missing pieces here. “A lot of broadcasters have already invested in NMOS, so there is a logical research stage in looking at NMOS and whether it’s a logical path for us. We need to find out whether it has to be changed [for DMF] or can it be used out of the box? Those are the sort of questions that we’ll be addressing next.”
There are also plans for extensive documentation, including use cases that will benefit from a DMF approach, and a high-level model for the lifecycle of media workloads as part of the Reference Architecture. But although it’s relatively early days, Vermost says there have already been broader hints that the initiative is on the right track.
“I was at an event before NAB and one of the things that was being discussed a lot [among delegates] was DMF, which completely blew my mind,” he admits. “But it did seem to be a vibrant topic already at NAB, and now with what we have announced and are planning, we hope that will continue into IBC.”
To access the full archive of EBU white papers and publications, including those related to DMF and MXL, visit https://www.ebu.ch/home.
This article originally appeared in the July/August issue of TVBEurope, available to download free here.
