Things are better when we work together. Discuss.

Broadcast workflows are only ever as strong as their weakest connection, and those connections generally matter more than the individual parts. It is a challenge that the broadcast industry have solved over the years with a variety of different technologies, most recently with ST 2110 delivering interoperable multi-vendor connectivity as part of the move to more flexible IP-based infrastructures.

The same challenges apply with moving real-time broadcast workflows into asynchronous cloud compute environments. But even this isn’t a new challenge, and broadcasters are already achieving multi-vendor interoperability in the cloud, says Matrox Video Product Manager Daniel Robinson.

“The demand is there and people are already doing it,” he says. “There are live cloud productions happening now, but the interoperability layer is often NDI. That’s real and it works, but it has challenges.

“NDI introduces cumulative latency because it’s synchronous, and the quality is limited because you’re sending compressed rather than uncompressed data. Moving to something like MXL could address those limitations; being asynchronous means you don’t accumulate latency as you pass through each step of a workflow, and most asynchronous systems operate on uncompressed content, so there’s no quality loss at each stage.”

What Interoperability Means Now

MXL – or the Media eXchange Layer – is the result of the EBU’s JT-DMF working group to transport data across an IT infrastructure in the most efficient, optimized, and open way possible.

“MXL is a means to transport audio, video and metadata through common IT standards through shared memory,” says Lawo CTO Phil Myers. “It allows multiple vendors to be on the same IT infrastructure and it also moves us to an asynchronous world where we can move data as fast as we need to.

“Historically, the interoperability layer in the physical world was SDI, and in the IP world it is ST 2110. MXL is the evolution of that. You need to be able to move data not just between applications on the same host, but between multiple hosts, and those hosts might be across different data centers in different countries. And in the same way that NMOS was important to ST 2110, JT-DMF is going to be fundamental to MXL.”

If it sounds far-fetched, it shouldn’t. Shared memory isn’t a new idea, and proprietary implementations of it aren’t new either but its application as an open, standardized interface for live production? Well, that is new.

“MXL is the media transport layer, which is an important part of the interoperability story, but not the whole thing,” adds Robinson (Matrox Video). “In many ways it’s the easier part to solve; shared memory has existed on computers for a long time and vendors like Vizrt and Pebble have implemented shared memory interfaces, but each of these vendors’ interfaces were proprietary.

“What MXL provides is a standard shared memory interface. MXL is adding a way to transfer shared memory between hosts faster than real time, enabling replicated asynchronous flows. Is MXL the only route to achieving multi-vendor interoperability? No. Is it the initiative with the most momentum right now? I think it is.”

The first public release of the MXL Software Development Kit (SDK) was developed quickly – it came less than seven months after its inception at an EBU kick off meeting. Part of the reason for the speed of development is that it’s not reinventing the wheel; to Robinson’s point, the broadcast industry has seen this before. But it also has strong industry support, an agile open-source project structure, and it leans into already well-defined and established IT architectures.

“Many of the major IT companies are involved in the JT-DMF,” says CBC’s Director, Global Collaborations / Innovation Hub, Felix Poulin.  

“Companies like Intel and Nvidia are involved and they bring their own expertise around things like containers, resource allocation, and Kubernetes. These methodologies and protocols are quite standard in IT, and we’re really adopting those directly rather than trying to reinvent them.

“If you look at the layer diagram for the EBU DMF reference architecture, the bottom layers – the infrastructure layers – are shown in blue, and the principle is not to reinvent those. ”For those we can use the existing IT technology. That leaves room for specialist broadcast vendors to create great applications on top of all of this.”

The fact that it is an open source development, says Riedel CEO (Product Division) Jan Eveleens, also helps speed up development; crucially it might also speed up implementation. Because as we’ve seen many times in the past, standards often leave room for interpretation because everybody interprets them in their own way.

“Open source development can help because it already provides an interface as an implementation, rather than a set of words that people can interpret which parts to implement,” he says. “A standard is like a legal contract and similarly to a legal contract you need people to interpret it. The problem is that people might not always agree on the same interpretation.

“But with open source that is no longer a problem. Most open source communities are made up of deep technical engineers that are just focused on fixing the problem and making it better. It’s a very different mechanism.”

The State Of MXL Right Now

This speed of development can be distracting; although MXL is a genuinely promising initiative with real momentum, it is still in its earliest stages. The direction is right and the foundation is solid, but it is earlier than much of the public hubbub around it suggests.

MXL doesn’t address timing across large systems. It doesn’t address flow discovery and control, metrics for frame drops and packet loss, or orchestration. What MXL currently solves is the transport layer – what Eveleens (Riedel) refers to as “the wire.”

“The current focus of MXL is mostly on what I call the wire; it’s about how we interconnect one process with another and hand over video, audio and other data,” he says. “But it is also important to agree on a standardized way of managing and orchestrating these processes because otherwise we solve less than half of the problem.

“The value is not just about achieving low latency and reducing compute power, but about how the whole thing can be managed, and how it can be deployed quickly and reliably. That is something which I think is in the scope of the whole effort, but today most of the focus is still on the wire.”

Myers (Lawo) agrees, and while he sees a short-term solution amongst the vendor community, he believes the EBU’s JT-DMF working group will provide a robust solution in the longer term.

“What MXL doesn’t cover is timing, orchestration, discoverability and registration, and that work is currently inside the JT-DMF,” adds Myers. “You need all of that to build a truly open system, but what I think we will see in the short term is that individual vendors will handle orchestration management, but you’ll still have MXL interoperability across them. Think of it like bringing out a more advanced version of ST 2110 in a very short period of time but using shared memory to move it around a network infrastructure.”

Keeping The Pressure On

Maybe it’s because it has so much potential, but the desire to maintain its momentum amongst all our panel is significant. While it seems the toolkit is proving popular, Appear CTO Andy Rayner, who also chairs the JT-DMF work strand on end-to-end timing and synchronization, has some reservations.

“We are invested in the development of this. We have one of Appear’s key software gurus spending a fair bit of his time contributing to the weekly evolution of MXL, I chair one of the JT-DMF strands, and our VP Technology and Innovation has a lot of oversight of the entire project,” he says.

“But in terms of contributing code to the core MXL development, I’m only aware of four or five vendors taking part. Most of what we’ve seen with MXL so far has been proof of concept rather than ruggedized and road tested technology, and currently there are far more companies taking the MXL software toolkit and using it within their development.”

Eveleens (Riedel) agrees: “It’s a core part of our long-term architecture, which is why we have a lot of engineers working on it. That makes it easier for us to be active in this development, but it would be good to increase the number of contributors across the board in order to create a more active community and provide a foundation for something that will be supported more widely.”

In fact, in addition to Appear and Riedel, Lawo and Matrox Video are also contributing code as part of the project, and Lawo’s Myers is more positive about broadening this out in the future. He believes that as the development gains more ground, its open architecture will encourage more and more development, citing past open source developments to argue the case.

“The only way this doesn’t succeed is if we lose the motivation we currently have,” he says. “I’m a strong believer in the open-source model; it means lots of people can contribute easily, and you need lots of contributors. If only five companies are contributing, and one of them has to step back for business reasons, the project is vulnerable. An open-source project with a broad contributor base is much more resilient. SRT (Secure Reliable Transport) is a brilliant example of how quickly something can move when it’s structured that way.”

One takeaway, and a potential fillip for development, is that unlike historical interop requirements, the shipping of hardware is largely a thing of the past.

“The great thing about the IP world is that a lot of this can be proved virtually,” says Rayner (Appear). “One of the things we’ve pushed for existing standards like ST 2110, TR07, and TR08, is to host repositories where vendors exchange packet captures in a controlled manner. It means each vendor can do its own debugging and interop testing at home.

“There have been some conversations about MXL interops, but the great thing about MXL is that interoperability is much more likely with an SDK than it is defining an interface specification. Adopting an SDK means people are effectively running the same code to talk to the interface, and that approach in itself automatically reduces the risk of incompatibility.”

Building Critical Mass

One person who is especially keen to encourage development is CBC’s Poulin. He knows how much broadcasters are already engaged in the concept of multi-vendor interoperability in the cloud because he is one of those broadcasters.

“For CBC I am responsible for establishing collaborations with the industry, with other broadcasters, and with vendors,” he says. “At the EBU, I co-chair the Dynamic Media Facility group, which is responsible for the reference architecture. In the MXL project I’m co-chair of the Technical Steering Committee and I’m the user representative in that co-chair role. And in the JT-DMF I’m also on the governance board, where we set priorities and direction.

“What’s interesting is that I come from a position of genuine need because we need this technology to work. Helping the industry come together around it is therefore of real strategic importance.  I think it’s important that users are represented in these industry forums and take some leadership, because at the end of the day we are the ones buying these products. If they’re fit for purpose, everyone has a better chance of success.”

With a foot in both camps, Poulin has a unique perspective on the panel and is just as focused on developing buy-in for end users as he is for vendors.

“It’s difficult these days,” he says. “Broadcasters and media organizations are under increasing pressure and have fewer resources. In Europe, the EBU brings a good critical mass of broadcasters to align on those topics and can play a representative role in international forums on behalf of a larger group. The larger organizations like the BBC and some German broadcasters are also involved, and so are some of the smaller ones; the Nordic broadcasters like SVT are also moving in this direction.

“The US market has a different dynamic, which is why we have a JT-DMF meeting in New York in March to specifically engage more users in North America. Historically, broadcasters used to be more involved in these kind of committees than they are today, and this particular subject is bringing some of that user engagement back.”

According to Eveleens (Riedel), the need to grow MXL’s level of visibility is tangible.

“We still have to see whether MXL gets sufficient traction; we have to be honest about that,” he says. “Riedel was already working on developing this idea when we discovered other people were too, and so we’ve seen it evolve from a simple conversation to something which is now getting much more visibility.

“We weren’t the only vendors building solutions to exchange video and audio in a more efficient way, but I think the project needs to generate even more visibility.

We are still in an early phase, and many people are not yet ready to fully commit to this technology as a structure for future media.”

It might still be early days, but as we’ll find out in part five, there’s another reason software-based environments are setting the pace of the broadcast industry, and it could accelerate everything we’ve discussed beyond recognition.