The development of the Media eXchange Layer (MXL) will have a profound impact on the broadcast industry, helping broadcasters, streamers and production companies streamline production.
That’s the belief of the panel that took part in TVBEurope’s webinar exploring the building blocks of MXL and how it will lead to seamless content exchange across multiple platforms and technology vendors.
Key to the work that’s gone into developing MXL is the notion of interoperability, enabling all of the pieces of equipment in a typical broadcast facility to work together.
“These days, everything is basically a computer running a software application,” explained Peter Brightwell, lead R&D engineer at the BBC.
“So if you think about what’s happening with video, a frame of video would be held in the memory of that box, converted into a stream and sent across the SDI cable or the network fibre, and then it’ll be unpacked at the other end. It’s a good way of joining things together using SDI, as an example. It’s not ideal, though, if the applications are running on the same computer. It’s wasteful; it adds overhead.
“MXL enables applications to share video, audio, and data directly between software applications,” added Brightwell. “It avoids unnecessary copying of data, allows parallel working, and it means it’s better suited to typical modern hardware where you’ve got clusters of computers working simultaneously. You can have software running on multiple computers within your data centre, basically accessing each other’s memory in a secure way.”
This idea is not new; broadcast technology vendors have been developing software-based production platforms for a while, some of which use a shared memory approach. What makes MXL different however, is that it is an open source project, with broadcasters, vendors, the EBU and Linux Foundation all working together to develop the SDK.
“We’ve got a lot of big names from the industry involved with this,” added Brightwell. “It’s all happening in the open on GitHub. You can see progress, and the first release of code is imminent. After that, it won’t be long before we have versions that [enable] sharing between CPU and GPU memory.”
Streamlining Production
MXL will have a major impact on production, said the panel, helping broadcasters streamline what can be a very complicated process. For the BBC, MXL will mean it can make the differences between its UK hubs become similarities, as Brightwell explains: “The BBC is quite a complex place, as I’m sure everybody knows, and has little islands of teams around the country, [each with] different technology decisions, different people buying different servers, and different approaches to how [they] send the video and the audio between the various applications they’re using. The idea is that all those differences become similarities.
“For instance, we have a team looking at providing enterprise-wide Kubernetes, like a container running system for different projects. So by providing that and making sure that MXL will run with that, then there’s a chance that some savings will come along due to moving resources into one approach.”
The move to software-defined workflows is providing broadcasters, streaming services and sports organizations with both flexibility and scalability, said Appear’s VP of technology, Ian Wagdin. “We need to be able to provide [this technology] in order to stay relevant to our customers. We need to be able to provide the tools that enable them to design the workflows and build the workflows that they want to operate.
“For me, that’s why MXL is so key because it unlocks those next steps and benefits that we’ve been promising since we started the move to IP.”
MXL will also help end-users to “stand up” productions, according to Lawo CTO, Phil Myers. Adding an overlay on a common platform to enable production, whether in a MCR, ACR, or some sort of a flyaway kit, is a lot easier in the MXL domain because it can be automated for consistency, he explained. “It means you can put the focus back on where it should be, which is the production value, what you actually put on screen.
“As we see now, the distribution chain out of this infrastructure is quite complex. It’s quite cumbersome in the old way of doing that. Now, if you have to take an SRT output or SMPTE 2110 or an MXL output, it’s really simple in a software world but you do need the interconnect. MXL will make it easier to build up that infrastructure and I think that’s where the streamlining will come.”
Open Source
As mentioned, MXL is open source. The reasoning behind that was to bring it to market as soon as possible, rather than go through multiple iterations before it could be released as a standard.
Key to that agility has been technology vendors working together, not an easy feat when many have an established technology stack, whether it’s a core technology, a transport layer, platform architecture, or any shared memory model.
“MXL disrupts portions of that internal secret sauce, which forces a strategic decision,” said Costa Nickols, exec-team strategy advisor, media and entertainment at Telos Alliance. “Do you build a native MXL implementation that potentially dilutes some of the platform differentiation that you have, or do you engineer a bridge or a gateway that connects to your existing stack to MXL?”
MXL enables technology vendors to develop solutions with one toolkit, so that the end-users do not have to repeat integration for every platform that uses different types of shared memory, Nickols added.
“Customers should not be worried about how to orchestrate and architect their system, and having to figure out different limitations in bandwidth and this and that. What they really need to focus on is creating and delivering content.
“By implementing MXL and allowing that entire integration across multiple vendor solutions to happen, it does allow them to do exactly that.”
Shared Memory
The EBU Technology and Innovation Group launched v1.0.0-rc1 of the MXL SDK in December for live production workflows, which is focused on a single compute use-case, with some vendors such as Matrox already integrating it into their products.
“There’s still work to be done at the higher order levels, such as around control timing to have a fully complete system that can be used in production. These issues really need to be solved first,” added Daniel Robinson, product manager at Matrox Video.
The panel were asked by the audience if there could be any problems with MXL when it comes to multicast delivery. Robinson explained that MXL and its node-to-node API LibFabric are primarily unicast.
“The idea is that you have multiple hosts where you’re maybe receiving a 2110 signal which is then converted to MXL in shared memory. That then means any of the media functions running on a host will be able to access that memory really efficiently. Then, if there’s a consumer of that same flow on a remote machine, it’s available in the local shared memory of that machine, and all of the consumers on that machine would also be able to contribute.
“So it’s going to be quite a different topology to what we see with 2110, where multicast is often prevalent. MXL is going to be more of a point-to-point model, almost a bit like a mesh.”
The full webinar is available to watch on-demand here.
Tom Butts will host a second webinar offering insights into overcoming integration challenges, maximising the value of software-defined infrastructures, and unlocking new opportunities for innovation in live and studio production, on Wednesday 28th January at 5pm GMT. Register to attend here.
