SEPTEMBER 2026
In partnership with
IN ACTION FROM PROTOTYPE TO PRODUCTION
A RAPID RISE TO REALITY O
ver the past year, the Media eXchange Layer (MXL) has evolved from an intriguing concept into a robust, open-source standard. We remember sitting in the Grass Valley Forum event at the start of IBC2025, listening as they told us about this new thing called MXL, having no idea it would become such a huge talking point in the industry. Fast forward 12 months, and everyone was talking about MXL and DMF at IBC2026. As David Edwards, senior product manager at Techex, told us: “Last year it was PowerPoints and a little bit of smoke and mirrors to pretend that there was something; this year it is a reality. We have a video workflow and an audio workflow working together." The speed of adoption is being driven by the fact that MXL is open-source. Vendors are working with other vendors and broadcasters to move the specification forward. “Because the MXL library was published as open source... that's really a great way to get everybody to align around doing things the same way,” said Steve Reynolds, Imagine Communications’ CEO. “MXL is getting to a point where there is provable interoperability, and that's great." So with all that said, this ebook is looking at where MXL is now. It seems we’re not far away from vendors fully integrating the technology into their products, enabling broadcasters to build flexible, software-defined environments that adapt to their evolving production needs.
In partnership with
www.tvbeurope.com CONTENT Content Directors: Jenny Priestley jenny.priestley@futurenet.com Tom Butts tom.butts@futurenet.com Senior Content Writer: Matthew Corrigan matthew.corrigan@futurenet.com Graphic Designers: Matt Lochrie, Rosie Webber Production Manager: Nicole Schilling Contributor: David Davies Cover image: Getty Images
ADVERTISING SALES Publisher TVBEurope/TV Tech, B2B Tech: Joseph Palombo joseph.palombo@futurenet.com Account Director: Hayley Brailey-Woolfson hayley.braileywoolfson@futurenet.com
SUBSCRIBER CUSTOMER SERVICE To subscribe, change your address, or check on your current account status, go to www.tvbeurope.com/subscribe
ARCHIVES Digital editions of the magazine are available to view on ISSUU.com Recent back issues of the printed edition may be available please contact customerservice@futurenet.com for more information.
LICENSING/REPRINTS/PERMISSIONS TVBE is available for licensing. Contact the Licensing team to discuss partnership opportunities. Head of Print Licensing Rachel Shaw licensing@futurenet.com
MANAGEMENT SVP, MD, B2B Amanda Darman-Allen
JENNY PRIESTLEY CONTENT DIRECTOR, TVBEUROPE
VP, Market Lead Carmel King MD, Content, Broadcast Tech Paul McLane VP, Global Head of Sales, B2B Dena Malouf
TOM BUTTS CONTENT DIRECTOR, TV TECH
Managing VP of Sales, B2B Tech Adam Goldstein VP, Global Head of Strategy & Ops, B2B Allison Markert VP, Product & Marketing, B2B Andrew Buchholz Head of Production US & UK Mark Constance
Contents 4
Head of Design, B2B Nicole Cobban
AI-ready infrastructure
16 Making open media operations practical
6
End-to-end visibility
8
The evolution of MXL
18 Real-time has a timing problem
10 Beyond media exchange
20 Software-defined media fuels MXL adoption
12 The end of drumbeat timing?
24 Breaking free of walled gardens
14 MXL reaches new milestone
26 MXL’s real test starts after Amsterdam
Future PLC is a member of the Periodical Publishers Association All contents © 2026 Future Publishing Limited or published under licence. All rights reserved. No part of this magazine may be used, stored, transmitted or reproduced in any way without the prior written permission of the publisher. Future Publishing Limited (company number 2008885) is registered in England and Wales. Registered office: Quay House, The Ambury, Bath BA1 1UA. All information contained in this publication is for information only and is, as far as we are aware, correct at the time of going to press. Future cannot accept any responsibility for errors or inaccuracies in such information. You are advised to contact manufacturers and retailers directly with regard to the price of products/ services referred to in this publication. Apps and websites mentioned in this publication are not under our control. We are not responsible for their contents or any other changes or updates to them. This magazine is fully independent and not affiliated in any way with the companies mentioned herein. If you submit material to us, you warrant that you own the material and/or have the necessary rights/permissions to supply the material and you automatically grant Future and its licensees a licence to publish your submission in whole or in part in any/all issues and/or editions of publications, in any format published worldwide and on associated websites, social media channels and associated products. Any material you submit is sent at your own risk and, although every care is taken, neither Future nor its employees, agents, subcontractors or licensees shall be liable for loss or damage. We assume all unsolicited material is for publication unless otherwise stated, and reserve the right to edit, amend, adapt all submissions.
TVBEUROPE EBOOK 2026 | 03
ADVERTORIAL
AI-READY INFRASTRUCTURE By John Mailhot, SVP, product management, Imagine Communications
T
he television industry has been trying to do more with less for as long as there's been budgets. We have always wanted to share expensive resources, move productions between studios, scale capacity for peak events, and avoid building dedicated islands of infrastructure that sit idle much of the time. None of those goals are new. What is new is that the technology underneath them has finally caught up with the ambition. SOFTWARE CHANGES WHAT IS POSSIBLE Two developments are important here. Software tools for building and operating large systems are far better than they were five or 10 years ago, and individual computers can perform much more media processing. Nearly every function in the television chain—apart from capturing pictures and sound at one end and presenting them at the other—can now be implemented in software. It’s not necessarily the most efficient or economical answer for every function, but software is a feasible option across each part of the workflow. This is where the Dynamic Media Facility, or DMF, comes in. SMPTE ST 2110 transports professional media between physical devices and compute systems, while MXL enables efficient media exchange among software applications running within a shared compute environment. DMF brings those layers into a broader operational architecture—one that encompasses workflow planning, application deployment, compute allocation, connection management, and the management and orchestration of resources throughout their lifecycle. Historically, making a facility flexible meant defining every path, designing each production into every studio it might use, and building the macros needed to move between them. That required complex software and substantial integration, configuration, and maintenance. The facility could be flexible, but achieving and sustaining that flexibility was expensive—and tracking it to any changes in the production design was an ongoing burden. This is where AI enters the story. Most of the attention today is on generative AI and its ability to create or modify scripts, pictures, and audio. That will certainly affect media, but it is not the application most relevant to a dynamic facility. Here, the more compelling opportunity is using AI to help people understand, configure, and reconfigure equipment and production chains. A simple example would be to ask, “What is on the multiviewer in Studio 3?” An AI application with the right access could look at the routing control system, find the destinations and their names, and return a useful summary. The more interesting question comes next: “I want to run tomorrow’s show from Studio 3. Will that work?” Today, answering that question may require an engineer to compare
04 | TVBEUROPE EBOOK 2026
signal paths, processing capacity, multiviewer layouts, control surfaces, audio resources and existing macros. An AI agent could start with the requirements of the show, compare them with the resources in Studio 3 and propose a plan. The operator could question it, conversationally adjust it, and, once satisfied, authorise the execution in time for tomorrow’s show. This changes the level at which people interact with the facility. Rather than describing every path, the production team describes the result. Engineering still determines what is possible, establishes safe boundaries, and handles unusual cases. But the discussion begins where the production team already works: What does this show need, and can I do it here tomorrow? WHY MCP MATTERS Making this practical requires a carefully controlled interface between the AI and the facility. A modern media system may expose millions of parameters, most of which are irrelevant at any given moment, but Model Context Protocol (MCP) provides a standardised way to expose the information and capabilities relevant to the task at hand, giving the AI the context it needs to use that information while controlling which changes it is allowed to execute. MCP is a standard way for AI applications and agents to use data and capabilities provided by external systems. In a broadcast facility, an MCP service can expose selected operational information and a specific set of permitted actions. It can allow an agent to inspect one group of destinations without seeing another, or propose routes in one studio without being allowed to change protected paths. We already apply these kinds of restrictions to human operators and physical control panels. There is no reason an AI interface should have fewer controls. MCP also reduces the amount of information the AI has to process. A good interface can present destinations by meaningful names, describe the relationships that matter, and leave out the large amount of device data that is not relevant to the task. In the other
“An AI-ready facility should build on existing infrastructure and remain open to different AI models rather than locking the operator into a single vendor”
Credit: Getty Images
ADVERTORIAL
direction, it can limit the actions the agent is able to take. This curation is important for cost and performance, but even more important for making the agent's behaviour understandable and manageable. The system underneath remains the system of record. The AI can interpret a request, examine the relevant context and develop a plan, but deterministic products still perform the routing, playout, monitoring, or scheduling operation. Depending on the application and the customer's policy, the agent might only answer a question, recommend an action, stage a change for approval, or execute within a narrowly defined area. IMAGINE DEMONSTRATES A PRACTICAL PATH FORWARD These technologies and applications are still developing, so the sensible starting point is assistance rather than unrestricted autonomy. A good interface gives the AI a task-specific view of the system rather than a mass of raw device data. As the organisation gains experience, it can decide where automated action is useful and where the economic or operational risk calls for direct human approval. Imagine has been demonstrating this approach across systems customers already rely on: MCP-enabled interaction with Magellan Control System for routing and processing, conversational assistance for multichannel playout, curated data for diagnostics, and MCP-enabled monitoring. Our ad tech portfolio applies the same principle to Landmark Sales ad placement workflows. The tasks differ, but in each case MCP gives the AI a governed way to work with a trusted core system.
An AI-ready facility should build on existing infrastructure and remain open to different AI models rather than locking the operator into a single vendor. Models and user interfaces will continue to change. The more durable investment is an open, softwaredefined operational layer with structured data, standard interfaces, permissions and observable actions. That allows broadcasters to introduce new AI capabilities incrementally, as their operations and the technologies evolve. Ultimately, every operational decision will involve the same things that have always shaped broadcast infrastructure: economics, operational risk, and human factors. AI does not make those tradeoffs disappear. AI does, however, move the economic and human factors in a helpful direction, enabling decision-makers to plan and execute production changes more dynamically—which is the real point of DMF. An AI-ready facility should allow a production team to describe what it needs while engineering defines what the system is allowed to do. AI systems can bridge this gap, proposing and even executing system changes to map productions into available resources. DMF provides the architecture for deploying and managing resources dynamically, with MXL handling media exchange among applications in shared compute. MCP gives AI a controlled way to interact with that environment. Put these pieces together, and the AI enables the infrastructure to adapt to the production—instead of forcing every production to adapt to the infrastructure.
TVBEUROPE EBOOK 2026 | 05
ADVERTORIAL
END-TO-END VISIBILITY
Media moves natively in MXL. Someone still has to watch every frame, writes Robert Erickson, VP sports and live production, TAG Video Systems
B
roadcast infrastructure has taken three real steps forward in my career. The first was the move from analogue to digital. With SDI, every connection was physical, one box cabled to another. The second step came in the 2010s, when IP took over. SMPTE ST 2110 became the standard for a lot of us, and compressed IP protocols like SRT filled in wherever hardware couldn't reach. Even there, you were still wrapping video and audio in a transport stream and pushing that wrapper from one device to the next. It was IP. It was still packaging. MXL is the third step, and it works differently than the first two. It's the first time our industry has adopted the way the IT industry shares media: natively, in memory, the way high-performance computing environments have been doing for close to 20 years. Compute nodes inside a dynamic media facility, a DMF, share audio, video and metadata the way they'd share any other data. No wrapping, no unwrapping. It's the first architecture in our industry built entirely in software from the ground up, and that architecture change requires a different way we process and monitor our media.
06 | TVBEUROPE EBOOK 2026
A transport stream gives you that access by default: pull the wrapper apart, read the headers, probe the payload. Shared memory doesn't. Whoever's watching the media has to find a new way in for at least part of the path. HOW TAG MONITORS MXL A DMF has three places where media needs watching: coming in, moving through it, and going back out. Only the middle one is new. Coming in, MXL doesn't touch what you already trust. Media entering a DMF still arrives the way it always has, over SRT, NDI, 2110, whatever your sources are using. None of that changes because your facility is running MXL internally. TAG is already the source of truth on everything crossing that threshold: every stream probed and monitored for quality before it ever becomes part of your dynamic media facility. Inside the DMF, that visibility has to follow the media into a format built for compute, and this part is new. MXL runs on RDMA over Converged Ethernet, RoCE, the same interconnect HPC and
ADVERTORIAL
Visual metric comparison table supercomputing environments have used to move data node to node for 15 to 20 years. There are maybe tens of thousands of people in the world who've actually configured a network to run it, and almost none of them come from broadcast. That's a real learning curve for engineering teams. The networking layer was the hardest part of 2110 the first time too. Now, we’ve done it so many times that we know exactly what to plan for and expect. Monitoring platforms built as hardware, or built on the assumption that a transport stream will always be there to tap into, run into trouble here. TAG was written as software from day one. When the EBU released the MXL SDK and documentation, we implemented it and it worked. MXL is another format our platform supports, the same way SRT or 2110 are. The flows moving through your DMF in native MXL are visible to TAG: watched, probed, and confirmed as they move node to node. Going out, it wraps back up, and so does the monitoring. Once your finished product needs to leave the DMF for distribution, to an affiliate, an OTT platform, or a downstream partner, it typically gets wrapped back into a legacy standard: SRT, 2110, MPEG-TS, whatever the destination requires. Those legacy protocols aren't going anywhere: they exist because they work in conditions MXL was never designed for. On the way out, TAG is watching that handoff too. MXL NEEDS ONE MONITORING TRUST LAYER END-TO-END Put those three points together and you get visibility across a DMF that spans two completely different technology generations at once: legacy transport on the edges, native compute in the middle. TAG
“[MXL is] the first time our industry has adopted the way the IT industry shares media: natively, in memory, the way high-performance computing environments have been doing for close to 20 years” doesn't have to choose. We support both. That end-to-end visibility matters to different broadcast stakeholders. For engineers, it means the platform they already trust keeps working and reaches into the new MXL environment too. For the people signing off on the investment, monitoring is already covered—both for the workflow you're keeping and the part that's brand new. MXL is a genuine architectural shift, and it deserves the attention it's getting. What does it change for the person running the facility? For TAG customers moving into MXL, the answer is simple. Not much. You still know what's happening to your media, everywhere it goes.
TVBEUROPE EBOOK 2026 | 07
FEATURE
THE EVOLUTION OF MXL The EBU’s Willem Vermost explains how the Media eXchange Layer is transforming software-based production for broadcasters worldwide Why has the EBU been so central to the development of the Media eXchange Layer? The EBU had already gathered considerable input from its members before the Covid-19 pandemic, at a time when many were actively experimenting with software-based production. During the pandemic, this transition accelerated significantly: remote working and software-based workflows suddenly became indispensable. Projects such as RTBF’s Studio 42 (winner of the EBU Innovation Award 2020) demonstrated at an early stage the considerable production benefits that could be gained by separating the user interface from the underlying processing. Once the restrictions imposed by the pandemic were lifted and we were able to meet again, the EBU brought together users and manufacturers of broadcast technology in Brussels in 2023. The central question was: how could these technological developments be applied to the future of media production? Those discussions laid the foundations for the layered model that was later described in the white paper Dynamic Media Facilities. In November 2024, we brought together a much broader group of public service media organisations and technology companies in Geneva. From the various layers of that model, one priority clearly emerged: the need for a common, computer-friendly way of exchanging media between different software components. This became the starting point for MXL: an open-source implementation of the Media eXchange Layer defined in the Dynamic Media Facility Reference Architecture (DMF-RA). Why is now the time for the adoption of MXL? Real projects. With a major modernisation project under way in Toronto, our Canadian colleagues at CBC/Radio-Canada brought considerable leadership and momentum to the initiative, helping to drive the project forward. At its heart, we are solving a real business problem. Caretta Research suggests that today’s fit-for-purpose production equipment is significantly underused, raising the question of whether increasingly specialised facilities are the right answer. Production environments need to remain fit for purpose for many years, yet it is difficult to predict what users will need to do even a few months from now. Rather than building fixed infrastructure around today’s
08 | TVBEUROPE EBOOK 2026
requirements, we need technology that is flexible enough to adapt as those requirements evolve. Commodity computing technology has now become sufficiently powerful to offer a different approach. What was once only possible with specialised broadcast hardware can increasingly be achieved through software running on standard computing infrastructure. This combination of flexibility and computing power creates an opportunity to build production environments that can evolve with the needs of the industry, rather than having to predict those needs years in advance. What has been the reaction from EBU Members to the development of MXL? The response from our members has been overwhelmingly positive. Many are currently developing new infrastructure or even building entirely new headquarters, and they need these facilities to be fit for purpose not only today, but well into the future. With production demands being a moving target, this approach will help ensure that their infrastructure can adapt as those requirements evolve.This demonstrates that we are addressing a genuine and immediate industry need, with strong support from our members to move the project forward as quickly as possible. What has been the main question you’ve been asked by broadcasters about the adoption of MXL, and how have you answered? Now that we have MXL, are we done? Far from it. MXL is an important
FEATURE
Can you give us some examples of early adoption approaches among broadcasters globally? A notable example of early adoption comes from CBC/RadioCanada, which applied the EBU’s Dynamic Media Facilities Reference Architecture within its production workflow for the Milano Cortina 2026 Olympic Games. This experience demonstrates how the DMF approach can support the transition towards softwarebased production while providing valuable insights from a realworld broadcast environment. In a trial conducted in parallel with the live production, CBC/Radio-Canada also demonstrated how incorporating MXL can help reduce latency in software-based production workflows. How has MXL continued to develop over the last six months? The latest V1.1 development introduces mxl-fabrics, a highperformance inter-host flow-replication framework using accelerated networking through libfabric, with support for
technologies such as RDMA over Converged Ethernet (RoCEv2) and AWS Elastic Fabric Adapter (EFA). This is an important step towards the goal of allowing media functions to exchange media across compute nodes without having to be tightly coupled to the underlying transport mechanism. In other words, the media-facing MXL API can remain transportagnostic while the fabric layer handles the specifics of how the data moves between hosts. That architecture should make it possible to accommodate different accelerated-networking technologies as the ecosystem evolves, potentially including technologies such as Ultra Ethernet without requiring media functions themselves to understand the details of each transport. What’s next for MXL? One example is the ongoing work to support timed data, allowing information such as triggers, titles and other control metadata to be exchanged and processed alongside audio and video. What comes next for MXL is ultimately driven by the Requirements Council and, most importantly, by real user needs. Every requirement that is implemented, or considered for future development, is rooted in the practical needs of the community. The level of demand, together with the willingness of users to contribute to and support a requirement over the long term, plays an important role in determining what is taken forward. In this way, the MXL roadmap is not driven by technology for its own sake, but by the needs of those using it to shape the future of software-based media production. Anyone interested in contributing or helping to shape that future is encouraged to join the project: https://tech.ebu.ch/mxl.
Image: Getty Images
piece of the puzzle, but it is only one piece. It addresses a specific challenge: how media can be exchanged efficiently between media functions in a compute environment. It does not bring a solution to any of the other layers described in the DMF Reference Architecture. And what about ST 2110? Will MXL eventually deprecate it? Absolutely not. The two technologies are complementary. ST 2110 provides an efficient way of transporting media to and from compute infrastructure. Within the compute environment itself, MXL can then be used to exchange media between different mediaprocessing functions. Together, they provide the foundations for a flexible, software-based production architecture.
TVBEUROPE EBOOK 2026 | 09
ADVERTORIAL
BEYOND MEDIA EXCHANGE
Daniel Robinson, product manager at Matrox Video, considers what it really takes to build a Dynamic Media Facility.
B
roadcasters are all working the same sum. The cost of producing content is flat at best and rising in most cases: more platforms to deliver to, more formats to package, more redundancy to maintain, more hardware to refresh. Revenue is not keeping pace. Linear audiences erode, streaming economics remain unsettled, and advertising is split across more destinations than ever. The result is a margin squeezed from both ends, and a clear mandate from the boardroom: extract greater value from the content the organisation already makes. The obstacle is structural. A traditional facility is built from fixed-function devices, each bought to do one job at peak demand and remain idle afterward. Capacity cannot be moved from one production to another, and it certainly cannot be repurposed for a different kind of output. Hardware is the ceiling. DMF: A LIGHTHOUSE, NOT A BLUEPRINT The EBU's Dynamic Media Facility (DMF) reference architecture is the industry's response, describing a facility not as a room of purpose-built devices but as a set of software media functions (ingest, replay, graphics, mixing, playout) running on standard IT infrastructure, on-premises or in the cloud, spun up, scaled and torn down as workloads demand. Comprised of a six-layer model: three industry-specific layers (Application and UI, Media Functions, Media Exchange) sitting on three generic ones (Container Platform, Host Platform, Infrastructure). The goals: software-first production, agility on demand, open interfaces and vendor choice, highperformance shared-memory media exchange, better utilisation, resilience and sustainability. The industry needs this document, and Matrox Video is an active participant in the work. To be clear, the DMF reference architecture is less an architecture than a lighthouse: a shared statement of where the industry is heading. On the questions of how (how functions agree on time, state is managed, control reaches functions that may be running anywhere) it currently holds placeholders. Workstreams are set up to fill them. However, one
question is unavoidable: can DMF be built today, and what does it really take to build one? In ascending order of difficulty: a common transport, a common understanding of time, and a common model of control. TRANSPORT Software media functions need to hand live media to one another in a process that doesn’t involve packetising it onto the network and de-packetising it on the other side. Matrox Video pioneered asynchronous, shared-memory media exchange between software functions with the launch of Matrox ORIGIN, and brought that know-how to the open project that became the Media eXchange Layer. MXL gives every vendor the same library for sharing media between functions. It's a significant step, because it removes the need to fall back to a synchronous transport such as ST 2110, and the encapsulation and de-encapsulation that go with it, every time media crosses a vendor boundary. A shared buffer is the floor, not the building. Passing grains between functions asynchronously doesn’t, by itself, give you asynchronous processing end to end. For that, every function needs to agree on what identity and on what an instruction means. TIMING For example, an ST 2110 gateway lands a feed into MXL. Downstream, one vendor's function handles the video, another the audio. The director calls a transition: fade the video to black and duck the audio underneath. Two functions, two vendors, one action. Each function runs asynchronously, at its own pace, on whichever host it was scheduled to. If the instruction to each simply says ‘now’, each acts on whatever grain it happens to hold when the message arrives. The fade lands on one frame, the duck on another, and the output drifts out of sync. A traditional facility papers over this problem with frame synchronisers scattered throughout the plant. A software facility has no excuse for that, and no need for it either. What’s required instead is a common understanding of time and
“DMF is the direction of the industry. Reference architecture describes the destination; MXL lays the first shared piece of the road. What it takes to arrive is transport, timing and control working together on infrastructure that is resilient and location-independent by design” 10 | TVBEUROPE EBOOK 2026
ADVERTORIAL
content identity: every grain carries a timestamp against a shared clock, and every control action is expressed against that timeline rather than when the message arrived. Both functions act on the same instant, regardless of where or when they process it. CONTROL In an asynchronous facility, ‘switch to camera two' is not a single event. It is an instruction to be resolved against identified content, at a specific time, by functions possibly on different hosts, in different locations, and may be in the process of moving. Control therefore needs a shared model of state and a way to address any function wherever it lands. Matrox ORIGIN provides this as a REST-based control plane over its media fabric, with the flow identity and timing built into every grain, making instructions like these deterministic. Application issues one time-bound instruction; the framework takes care of the plumbing, ensuring every participating function honours it. WHAT ‘DYNAMIC’ MEANS Get transport, timing and control right, and the rest of the DMF vision stops being aspirational. Dynamic means composable. A production is assembled from media functions rather than wired from devices, and the same functions can be recomposed for the next production. Kubernetes gives operations teams a familiar way to deploy and schedule, and Matrox ORIGIN ships a Kubernetes-native operator for exactly that. But Kubernetes is the DevOps mechanism, not the point. Composability comes from functions sharing a media exchange, a timeline and a control model. Dynamic means location-independent. Because functions exchange media asynchronously and act against shared time, a function can run on any host in the cluster, in another building, or in the cloud. Matrox ORIGIN routes media and can migrate it live without interruption, letting a broadcaster ship compute to an event, borrow capacity from another production, or outsource a peak. And dynamic means resilient in a new way. Instead of duplicating whole devices, Matrox ORIGIN provides redundancy at grain level. Protection follows the content, not the box. CAN A CROSS-VENDOR DMF BE BUILT? Yes, and it should be. A single-vendor DMF would fail the goal that
motivated it. But it requires the industry to agree on timing and control the way it has begun to agree on transport through MXL. Today those are the placeholders in the reference architecture. Workstreams on end-to-end synchronisation, Flow Discovery, and Compute Resource Management are where the gaps will close. Matrox Video is active in each, bringing answers that already run in production. The industry does not have to wait for the last placeholder to be filled to start building. CLOSING THE COST-REVENUE GAP This is where the architecture meets the balance sheet. The cost problem is not that hardware is expensive; it’s that hardware is fixed. Software media functions on generic compute change the maths. Capacity used for a live broadcast can be recomposed for another job. The revenue side follows. Squeezing more value from content means putting the same content through more outputs, in more formats, for more audiences, at marginal cost rather than by standing up another hardware chain. A facility that can compose a new production in software can try a new output without a capital request. DMF is the direction of the industry. Reference architecture describes the destination; MXL lays the first shared piece of the road. What it takes to arrive is transport, timing and control working together on infrastructure that is resilient and location-independent by design. Few companies are positioned to deliver that today. Matrox Video, with Matrox ORIGIN, is one of them.
TVBEUROPE EBOOK 2026 | 11
ADVERTORIAL
THE END OF DRUMBEAT TIMING? Russell Trafford-Jones, industry engagement manager at Techex, explores the challenges broadcast faces moving time from the sync pulse to 'time of day'
EVERYONE PLAYING TO THE SAME BEAT The familiar friend for all broadcasters is the synchronisation pulse. Whether black and burst, world clock or one of many others, the idea is the same: a pulse rippling throughout the system ensures all video frames start at the same time and allows audio to keep the correct sync. Whether you think of it as a drumbeat or as an orchestra conductor, as long as everybody plays on the beat, the system stays coherent. The drumbeat has served the industry well ever since the dawn of broadcasting. The downside is that a beat tells you when to play but not what to play. A feed arriving three frames late is still perfectly in step since each frame starts exactly where it should. The system simply doesn't know about the delay, so we rely on engineers to dial in an offset until it comes good. BAR NUMBERS ON THE SCORE The big change is to write an actual time into the media itself. If time of day is embedded into a transport stream, or timecode is in the video, then delays can be set automatically and we can unlock new workflows. If a pulse is the conductor's beat, a timestamp is the bar number on the score. A beat tells everyone when to play, whereas the bar number tells them what. Say “from bar 57” and every player lands on the same note. With the time of day embedded in every
12 | TVBEUROPE EBOOK 2026
feed, you can take media apart, process it, and put it back together knowing which parts match. That opens up asynchronous, faster-than-real-time processing. Latency can vary, branches of different lengths can be recombined, and media can be reunited long after it was separated. This flexibility is what software offers but is near impossible without leaving the drumbeat behind. WHY PTP HAS NOT ALREADY SOLVED THIS Every time an ST 2110 device processes media and sends it on, it stamps it with the current time, which means we lose the origination time. The audio passes through a mixer and a DSP and is re-stamped at each, so by the time it reaches the encoder it no longer shares a timestamp with the picture it was captured alongside. Putting them back together falls to an engineer measuring the path and dialling in a delay. It is not for want of good time. ST 2110, like AES67, runs on PTP, counting from 1st January 1970 on the TAI timescale, and every RTP timestamp is derived from it. But the industry has mostly used PTP to manufacture a beat rather than as a lasting record of when the media was made.
Credit: Shutterstock
T
iming is a part of broadcast engineering that nobody sees, because it works. Every cut between cameras, every audio mix and every presenter whose lips match their words relies on the system knowing which moment belongs to which. Historically, this is thanks to good planning and dialling in delays where needed. But as we look to base our systems on software-defined infrastructure, timing is set for a shakeup.
ADVERTORIAL
THE WORKHORSE, AND ITS SOFTWARE SUCCESSOR The Dynamic Media Facility (DMF) vision sees all media functions as software. The workhorse of the industry, SDI, has since the 1990s given us an interoperable, vendor-agnostic way of exchanging uncompressed video and audio with almost zero latency. Software has had no standard equivalent, only vendors' own hand-offs. MXL, the Media eXchange Layer, has stepped up to be that technology. In MXL, media is written into shared memory so other software can read it directly. Video is written as grains, the smallest unit that stands on its own, such as an uncompressed frame, while audio is written as samples. Crucially, the timestamps are not recalculated at each hop. Every frame and sample carries its timestamp, and a function processing it writes its output against that same time, however long the work took. In the DMF, the audio leaves the mixer and the DSP still carrying the moment it was captured, so the encoder simply matches it to the picture. That matching is the synchronisation. Nobody measures the path or dials in a delay, so adding a function, swapping a vendor or changing how long the audio takes cannot knock picture and sound apart. Whatever route the media takes, it arrives already knowing what it belongs with. THE QUESTIONS THAT OPEN UP The JT-DMF, the Joint Task Force on Dynamic Media Facilities, has an end-to-end synchronisation working group which has, to date, issued two documents discussing conforming timing at the input and
“Video is written as grains, the smallest unit that stands on its own...while audio is written as samples” managing it within DMF infrastructure. One open question is which time to work on, since now is not a single value: cameras through a vision mixer might cost four frames, so the mixer runs on a time of 'now' minus four frames. Timing planes are not new to broadcast, but software puts them back into focus. THE PRIZE None of this is a reason to hesitate, only to be precise. The prize is a facility where media can be pulled apart, processed in parallel, run faster than real time, moved between vendors' functions and kept in sync at all points in the workflow. The drumbeat is not going anywhere at the edges of the system. Inside it, timestamped flows are the key that unlocks the flexibility and efficiency media organisations need in today's market to grow and to succeed.
TVBEUROPE EBOOK 2026 | 13
Image: Willem Vermost, EBU
FEATURE
MXL REACHES NEW MILESTONE An integral part of the EBU’s groundbreaking Dynamic Media Facility (DMF) initiative, the Media eXchange Layer (MXL) code package recently hit API and ‘feature freeze’ for v1.1— signalling its growing readiness for realworld workflows, writes David Davies
I
t is now three-and-a-half years since the European Broadcasting Union began to set out its vision for the future of virtualised media production with the publication of a white paper. Defining the concept of a Dynamic Media Facility (DMF) to enable ‘flexible, software-first environments', the project called for the creation of a Reference Architecture—of which a high-performance media exchange layer employing shared access to video, audio and data was always destined to be an integral component. Catching up with DMF Group co-chairs Peter Brightwell (lead R&D engineer, BBC) and Félix Poulin (director global innovation collaborations, CBC/Radio-Canada) in September 2026, it soon becomes evident
14 | TVBEUROPE EBOOK 2026
that a great deal of progress has been made with the resulting Media eXchange Layer (MXL). Supporting the exchange of uncompressed or compressed live media payloads between media functions running on containers on the same hosts, or on different hosts in a cluster, it serves to minimise latency and avoid excessive copying by using asynchronous shared access between containers—marking it out from some streaming technologies, including those pertaining to ST 2110, that are used for synchronous operation. Other features include shared access being granted through authorisation, and media functions only exchanging with other authorised functions. It was recently announced that MXL had “officially hit API and feature freeze for MXL v.1.1 Release Candidate 1”, with interested developers, integrators and broadcast engineers encouraged to test RCL before the release is declared production-ready. There’s no doubt that it constitutes a significant moment in the overall MXL/DMF project. Brightwell observes: “Even in its first (v1.0) version, MXL has generated plenty of interest in the industry, helping vendors building solutions for software-based live production systems. It provides an open-source SDK for sending video, audio and data between processing elements using an efficient shared memory approach. “MXL v1.1 takes this further through its ‘Fabric API’, which extends that shared memory approach to work between hosts,” he continues. “The Fabric API uses technologies such as RDMA over Converged Ethernet
FEATURE that are used for data-intensive high-speed operations within data centres and cloud services. Such operations will be at the heart of future live production facilities needing the scalability, flexibility and resilience that broadcasters will need to support their business transformation.” Invited to consider how widely the potential of MXL is now understood, Poulin says that as with every technology transition, “there are a bunch of pioneers and early adopters who get the ball rolling. The MXL development attracted many of the players who were already engaged with the transition to DMF and realised that interoperability was a limiting factor. Now the DMF ball is rolling, we will see the majority who will progressively join over the next few years. The industry is now transitioning from proof-of-concept to real-world integration, a progression clearly visible in the multi-vendor interoperability showcases” at events such as IBC2026. Brightwell echoes these sentiments, but indicates that there is one lingering misconception that needs to be corrected. “A lot of people know about MXL now, including what it does,” he says. “However, we have heard some people say it’s a replacement for ST 2110 etc., which is not the case as they address different problems. MXL is an enabler to build future software-based live media operations—that’s what DMF is about, and MXL is part of DMF, and I’m pleased to see we are also now seeing vendors promote the DMF message as well as MXL as their customers become more aware of what will be possible and start thinking about what they will need in the future.” PROGRESSIVE/PRAGMATIC Meanwhile, both CBC/Radio Canada and the BBC are continuing to explore their own implementations of MXL. Co-existing with its ST 2110 systems for well-established productions, CBC/Radio Canada already uses MXL for sports content augmentation and is now working towards deployment for local live news on FAST channels—something that “would not make economic sense if we had to build traditional fixed control rooms for such occasional use,” states Poulin. “This represents not a radical shift, but a progressive and pragmatic evolution. And this way we can learn and grow our expertise at the same time the industry is converging on solutions.” At BBC R&D, MXL has been tested in its live media on-premises cloud, including performance testing of local sharing and the new Fabric API, and integration with other live media systems, such as those employing ST 2110. In addition, says Brightwell, “as we work with BBC technical teams on how timeaddressable media (and the TAMS initiative) will modernise our supply chain, we are looking out for where there are live production components that would benefit from MXL.” Looking ahead, the profile of the entire project is set to rise higher via the auspices of JT-DMF, a Joint Task Force on Dynamic Media Facilities between the EBU and AMWA. This Media exchange in detail was the subject of a showcase at IBC2026—
Félix Poulin (left) and Peter Brightwell where there were also plenty of related presentations at the Conference and on the IP Showcase boat. The current work of the JT-DMF looks to be especially critical to the success of the overall project. As Brightwell notes: “MXL itself only considers the video, audio and data, so it’s essential that some of the control and orchestration activity happening in JT-DMF also starts being adopted. An immediate one is the work on a common connection mechanism to use with MXL, such as AMWA’s new BCP-007-03 recommendation based on extending NMOS.” He also draws attention to the need for a common way for software components (what DMF calls ‘media functions’) to describe their “technical capabilities and requirements”, an issue that the AMWA Compute Resource Management Group is now addressing. “These are steps towards promoting a more useful interoperability for the market, so users don’t have to worry so much about which vendor they buy from as the risk of lock-in to a ‘walled garden’ is reduced,” says Brightwell. Most imminently, Poulin expects many vendors providing softwarebased live media functionality to integrate MXL support within the coming months now that v1.1 is available. “However,” he adds, “true widespread utilisation in major systems will follow as we further define orchestration and common architecture patterns—work that the JT-DMF is actively progressing.”
TVBEUROPE EBOOK 2026 | 15
ADVERTORIAL
MAKING OPEN MEDIA OPERATIONS PRACTICAL M edia production is entering a phase where new operational ingredients are becoming practical at the same time. Dynamic Media Facilities, software-defined production, open media exchange, orchestration, observability, trust, AI and unified media operations are no longer separate conversations. Together, they describe a larger shift in how media organisations can create, operate and adapt. At the centre of that shift is a simple but important question: How can production environments become more dynamic without becoming more fragmented? For decades, media workflows have been built around clearly defined systems, signal paths and operational boundaries. That structure created confidence. Engineers knew where media lived, how signals moved and how systems behaved under pressure. But audience demand has changed. Production teams now need to support more formats, more platforms, more versions, more locations and more operational models. The challenge is not only to move media. The challenge is to make media accessible to the right functions, in the right context, at the right moment. That is where MXL matters. The Media eXchange Layer (MXL) should not be understood as just another integration method or transport layer. Its importance is more fundamental. MXL provides a shared media access layer for software-defined production. It gives software media functions a common way to access and exchange media efficiently while preserving the timing, identity and context that production workflows depend on. This distinction is essential. SDI and SMPTE ST 2110 continue to play critical roles in facilities, devices and real-time production environments. MXL addresses a different challenge: what happens once media moves into compute. Instead of every software function needing its own transport, copying, conversion and integration logic, MXL creates a common exchange model designed for softwaredefined processing. That is why MXL is so important to the Dynamic Media Facility direction. A Dynamic Media Facility is not simply about cloud or virtualisation. It is an operating model built around software media functions, shared resources, orchestration, monitoring, security and open media exchange. MXL provides one of the key foundations that allows these functions to work together in a more open, modular and scalable way. The value is not technical openness for its own sake. The value is operational freedom. When media functions can share media through a common access layer, organisations can reduce dependence on custom
16 | TVBEUROPE EBOOK 2026
bilateral integrations. They can combine capabilities from different technology stacks more easily. They can add, replace or evolve functions without rebuilding the foundations of every workflow. They can create workflows that are more adaptable to changing production needs while still preserving the timing, identity and operational context that live media requires. This also changes how we should think about modernisation. The goal is not to replace every existing environment with a single new model. Most media organisations operate in mixed realities. They depend on dedicated hardware, SDI, IP, software-defined workflows, cloud resources, partners and existing infrastructure. The opportunity is to make those ingredients work together as one seamless operation. That is the idea behind Unified Media Operations. It is not a product category or a demand that everyone should build the same architecture. It is a practical direction: bringing hardware-based systems, software-defined workflows, open media exchange, orchestration, automation and partner technologies into a more coherent operational model. In that context, MXL becomes one of the key enablers of openness. It helps turn software-defined production from a collection of individual applications into a more connected operating environment. It gives the industry a more structured way to build interoperable software Media Functions. And it helps make Dynamic Media Facility principles usable within the operations media organisations run today. But the transformation is not only technical. As operations become more dynamic, confidence becomes critical. Teams need to understand how workloads move, how resources scale, how resilience works and how systems remain observable and secure. Trust, resilience and visibility are not side topics. They are what allow open, software-defined production to be used under real production pressure. The same applies to AI and operational intelligence. New intelligence only creates value when it supports human agency. Media organisations need systems that make recommendations, signals and decisions understandable, traceable and useful. The objective is not to remove people from the creative and operational process. It is to give them better context, faster insight and more confidence in the moment. That is ultimately the most important takeaway. MXL is part of a broader transformation, but its role is very specific and very powerful. It makes open, high-performance media exchange practical for software-defined production. It helps Media Functions work together without forcing every workflow into a custom
ADVERTORIAL
integration project. And it supports a more unified operational model where different technologies, vendors and deployment choices can contribute to one production reality. For viewers, this means richer, faster and more relevant stories. For creative teams, it means more freedom to shape productions around the moment. For operations teams, it means more control over complexity. For media organisations, it means greater agility in how they scale, adapt and create value.
The promise of MXL is not simply better connectivity. It is a more open foundation for media production itself. This direction is already gaining industry recognition. MXL won the Content Creation category at the IBC2026 Innovation Awards, recognising the work behind the open media exchange approach. As a founding member and major code contributor, Grass Valley has been a key contributor to the development of MXL, with Ian Fletcher and Vincent Trussart among those helping drive the initiative.
TVBEUROPE EBOOK 2026 | 17
ADVERTORIAL
REAL-TIME HAS A TIMING PROBLEM
Riedel Communications’ Drew Martin explains why data movement, synchronisation, and architecture matter in software-defined media
B
roadcast used to have a built-in safety net. In the SDI era, the infrastructure itself enforced timing. Every piece of equipment had to be synchronised, and frame boundaries, lip-sync, and switching behaved predictably because the hardware left little room for uncertainty. That safety net is disappearing. Modern production increasingly runs on COTS servers, GPUs, cloud infrastructure, and distributed software services. Instead of moving through a predictable chain of dedicated hardware, media can pass between applications, processes, machines, and compute environments. The flexibility is enormous. But it changes one fundamental question: Who, or what, is responsible for keeping everything on time? REAL TIME IS NO LONGER AUTOMATIC In traditional SDI environments, every device had to stay synchronised. In distributed media environments, that is no longer necessarily true. Some functions require precise synchronisation, while others can operate asynchronously. The challenge is maintaining synchronisation where it matters, while allowing workflows to take advantage of software and distributed compute. The Joint Taskforce on Dynamic Media Facilities (JT-DMF) is actively exploring these evolving timing challenges and how to enable robust end-to-end synchronisation across dynamic workflows. The distinction matters because modern systems introduce something SDI largely hid from engineers: data movement has a timing cost. A workflow may involve media functions running on different hosts, with some processing on CPUs and other stages on GPUs. Frames move between memory spaces, processes, devices, and potentially machines. Each handoff can introduce latency and variability. Individually, those delays may be tiny. Across an entire live production pipeline, they can become the difference between predictable real-time performance and a system that struggles to keep up. THE HIDDEN COST OF MOVING MEDIA This is where architecture becomes important. The Media Exchange Layer (MXL) takes a different approach to moving media through
18 | TVBEUROPE EBOOK 2026
software-defined production environments. Rather than treating every application-to-application transfer like a standard network transport problem, MXL uses local and remote shared-memory capabilities to exchange media buffers directly. Think of it as virtual cabling for software-defined media. The goal is to minimise unnecessary copying and processing overhead, reducing latency and improving compute efficiency between processing stages. That becomes particularly important in GPUcentric workflows. A GPU can process enormous amounts of data extremely quickly, but that performance advantage can be undermined when frames repeatedly leave GPU memory, pass through host memory, or make unnecessary trips between devices. A joint study by Riedel and NVIDIA, presented at the 2025 SMPTE Media Technology Summit, examined common data-movement paths in GPU-based media pipelines, including direct GPU-to-GPU transfers, host-mediated routes, and intra-node exchanges. The takeaway was straightforward: where the data goes can matter as much as how fast the processor is. Direct, zero-copy transfers can keep latency low and behaviour predictable. When frames pass through host memory or across nodes without careful device alignment, latency can increase and jitter can appear. The GPUs may finish their work with time to spare. The movement of data between them can become the limiting factor.
Riedel's Sithideth Viengkhou speaking at IBC2026
ADVERTORIAL
Sunday Nyamweno from CBC/Radio-Canada demonstrating MXL Fabric at EBU Network Technology Seminar 2026
MXL is not a replacement for SMPTE ST 2110. ST 2110 remains fundamental to interoperable media transport between systems and hardware endpoints. MXL addresses a different boundary: the exchange of media between software applications inside and across processing environments. Aligned with technologies and standards such as ST 2110 and NMOS, and developed as an open-source project, MXL represents an architectural shift toward standardising how software applications exchange media. That can help applications from different developers operate within the same ecosystem while reducing proprietary dependencies. DESIGNING FOR REAL TIME Perhaps the biggest shift is conceptual. In the SDI era, real time was largely something the infrastructure gave you. In software-defined production, real time is increasingly something you have to engineer. Synchronisation, memory movement, RDMA, device topology, network behaviour, and processing all become part of the timing equation. A system can have enormous compute capacity and still struggle to deliver predictable performance if its architecture forces data to take the long way around. As production becomes more software-defined, GPU-accelerated, distributed, and dynamic, understanding the path of every frame becomes essential. The next generation of broadcast infrastructure won't just need to move more media. It will need to move it predictably, efficiently, and on time.
TVBEUROPE EBOOK 2026 | 19
Backgroud image: Getty Images
TIMING IS BECOMING A SYSTEMS CHALLENGE As software-defined production moves into everyday operations, timing is becoming a broader systems concern. Microservices, containers, orchestration, virtualisation, and cloud infrastructure are increasingly part of production architectures. GPUintensive applications add another layer of complexity. Live inference, vision processing, super-resolution, graphics, and other accelerated workloads can move frames between processing stages more often than traditional production chains. Hybrid and cloud production increase these effects. A workflow may span on-premises infrastructure, private or public cloud, different GPU generations, and virtualisation layers. Each segment can introduce its own timing characteristics. In these environments, broadcast-grade determinism cannot simply be assumed. It must be designed. That leads to some practical questions for engineering teams: • Where does every frame go? • How often does it move between memory spaces or devices? • Can unnecessary copies and device transitions be eliminated? • Where are the synchronisation boundaries? • What happens when workflow topology changes? • How can timing be continuously monitored and validated? These are architectural questions, not simply equipment-specification questions. Open, shared-memory-focused approaches such as MXL address part of this challenge by allowing software media functions to exchange data efficiently while reducing unnecessary movement between processing stages. Interoperability is equally important.
FEATURE
SOFTWARE-DEFINED MEDIA FUELS MXL ADOPTION Tom Butts reports from IBC2026, where the industry was getting more serious about the Dynamic Media Facility
A
s software-defined production becomes more predominant in media workflows, the need for compatibility, openness and speed increase. And perhaps nowhere has the interest manifested itself better than in the evolution of MXL (aka Media eXchange Layer). Publicly announced in the spring of 2025, MXL is the reference architecture for the EBU’s Dynamic Media Facility initiative, and is designed to, in the association’s words, “enable interoperable exchange of media between professional AV production software”. For an industry known for being slow to adopt standards, the buzz and speed at which vendors have embraced MXL is characteristic of how the media production industry has had to adapt to a new reality that is often dominated by standards imposed on them by Silicon Valley rather than the standards groups. INCREASED PARTNERSHIPS The move to MXL has also prompted more partnerships among competitors, which was illustrated by the announcement this summer from Grass Valley and Lawo. The collaboration is initially focusing on validating practical interoperability between AMPP and HOME across control, orchestration, media transport and exchange, and operational monitoring with security-first deployment principles at its heart. This
20 | TVBEUROPE EBOOK 2026
includes exploring use cases such as multiplatform routing, crossenvironment resource visibility, and MXL-aligned exchange between software-based media functions. A year and a half after its official ‘debut’, MXL showed that it was ‘ready for its close up’ at IBC2026. Just prior to the show, the EBU announced v1.1 of MXL that introduces support for the deployment of DMF workflows on clusters of computers, not just single hosts. That support was demonstrated at the Grass Valley booth, where the company demonstrated native MXL v1.1 support in AMPP, together with the latest NMOS implementations for MXL flow discovery and control. Their demonstration consisted of an end-to-end workflow spanning acquisition, ingest, media processing and monitoring, live production, content management and playout. Technologies from Calrec, Lawo, Haivision, TVU Networks, Zoom and others were used in the demo, illustrating the importance of partnerships, according to Grass Valley CTO Ian Fletcher, who noted that the new key feature for 1.1 is the ability to share MXL workflows across compute nodes. “Before, different vendors could exchange compressed video on the same compute node; now we can grow—we can go across compute nodes, both in the cloud in AWS and also on prem,” he said. “And this really opens up a new opportunity to build large facilities completely
FEATURE
on POPs. Using MXL at the core doesn't mean 2110 goes away; it just moves out to the edge, which is where it's ideal.” Customer needs are driving the rapid and increased interest in real-world deployments of MXL, according to Stephan Stadler, chief product officer for Appear. “Our customers don't care whether you're competing on some particular function, they just have a workflow in mind that needs to work, and that's where MXL comes in as a great kind of interoperable layer,” he said.
Ian Fletcher
SHARED MEMORY “The fact that MXL is built around openness and shared memory are important factors in promoting collaboration, efficiency and speed,” said Andreas Hilmer, chief marketing officer for Lawo, which also sponsored a partner demo with Grass Valley at its booth. “It's about shared memory, having multiple apps or instantly giving access to the same frame, which is already in memory, and then it expands from within the memory of one single server across the memory of multiple servers, so it's over the network; that is what MXL is about,” he added. “This cannot only be done within a single vendor environment like we do, but it could be done giving access standardised to multiple vendors.” Thomas Edwards, senior manager of solutions architecture for media and entertainment at Amazon Web Services, discussed the evolution of MXL over the past several years, noting the limitations of the decade-old SMPTE 2110 standard. “2110 has some very tight timing requirements established in some cases because it was designed to interoperate with SDI, which has a very tight synchronous clock,” he said during a presentation at IBC. “Also, when it was developed, memory was super expensive and although [hardware] is getting expensive again, MXL is really built for software. It's asynchronous, and it has a bit of a looser timing concept because it's running in software.” These limitations are what helped prompt the EBU’s DMF initiative,
The Media eXchange Layer (MXL) won the Content Creation category of the IBC 2026 Innovation Awards. (L to R): Willem Vermost (EBU), Vincent Trussart (Grass Valley), Felix Poulin (CBC/Radio-Canada)
he added, with the desire for a more software-focused workflow. Voicing the wishes of DMF proponents, Edwards mused that “we should be able to run media functions on commercially available off-the-shelf compute hardware, and it doesn't matter whether it's on-premises or whether it's running in the cloud'. David Edwards, senior product manager for Techex, believes it's this versatility that will help media production facilities become more flexible. “MXL enables you to build up big, complete broadcast workflows in the cloud efficiently by handing off content at memory level rather than dropping down to SRT or something like that,” he said. “It gives broadcasters the ability to interface between different vendors much more easily than today's workflow.” HERE AND NOW Michael Demb, vice president of product strategy for TAG Video, is particularly bullish, commenting on the company’s demos at IBC. “You could see five different demonstrations at the show with different vendors showing actual real workflows, production workflows working using MXL,” he said. “People keep asking me, ‘Is MXL a real thing?’ and ‘when can we see some initial deployments?’ I think it's a matter of months.” Demb compared the adoption of MXL to that of 2110. “After all these years, we're probably at around 50-ish per cent adoption in the market of 2110; there's still a lot of SDI,” he said. “With MXL, it's accelerated several times. The MXL adoption is going to be super quick. We have broadcasters talking about doing complete production, completely virtualised ‘everything in the cloud using MXL DMF approach,’ all in a year or two from now.” Grass Valley’s Fletcher hinted that it’s already happening. “I just came back from New York, where we've just put a major Tier One network to air with 10 new sports control rooms doing very, high value sports content and commercial insertion,” he said during the Grass Valley Forum just prior to the opening of the IBC Show. “They’ve taken 13 racks of traditional equipment, collapsed it down to just 10 servers, actually 11, one spare one. Each room runs on one server, and then they've got a spare if they ever need it, and all the video passes between these rooms, as MXL data doesn't use 2110; 2110 sits around the edge to feed into the rest of the facility.” Kimberly Brown, senior product marketing manager for Matrox, reflected the attitudes of many vendors, cautioning that MXL fits within a framework that must continue to keep the role of hardware in mind. “MXL and DMF are definitely a trend, but at Matrox, we're trying to not make it a ‘software versus hardware’ conversation because clearly we do a lot of hardware as well,” she said. “We're trying to build it as complementary—that software is not a direct replacement for your hardware equipment.”
TVBEUROPE EBOOK 2026 | 21
ADVERTORIAL
BREAKING FREE OF WALLED GARDENS T he broadcast industry's move towards the Dynamic Media Facility (DMF) is often portrayed as a radical break from the past. In fact, it is better seen as the next step in an evolution underway for more than a decade. For years, media infrastructures relied on dedicated hardware appliances for high performance, reliability and density in continuous, large-scale tasks such as signal transport and processing. Hardware-accelerated software platforms, like Nevion’s Virtuoso, then added flexibility while retaining the efficiency and performance required for mission-critical operations. Today, media processing is increasingly becoming software-defined. Functions once tied to dedicated appliances can now run on standard COTS infrastructure, on-premises, in private data centres or in the cloud, enabling greater agility, scalability and efficiency. FROM MONOLITHIC SOFTWARE TO REUSABLE FUNCTIONS However, the transition is not simply about replacing hardware with software. The real transformation lies in how media applications themselves are built. Many current software platforms are still based on large, selfcontained applications or proprietary platforms. While more flexible than hardware appliances, these architectures can create isolated
ecosystems where functions are tightly coupled and difficult to reuse outside the platform. The vision of the Dynamic Media Facility goes much further. DMF breaks media workflows into discrete and independent media functions that can be combined, orchestrated and scaled individually. Rather than using monolithic applications, broadcasters can build workflows from reusable discrete building blocks, selecting the most appropriate media functions regardless of where they come from—providing them with greater choice and preventing vendor lock-in. This is where the Media eXchange Layer (MXL) comes in. Far more than a transport mechanism between monolithic applications or ecosystems, MXL provides a common framework for connecting individual media function building blocks. Effectively, MXL represents for media functions what SMPTE ST 2110 did for media streams: a standardised way to create open, vendorindependent, interoperable software-based workflows. That’s why new broadcast software products, such as the MOXELA processing platform, are embracing DMF and MXL from the ground up. OPEN, DYNAMIC—BUT NOT HARDWARE-FREE While the future of software-based media infrastructure will be built on open, modular workflows using interoperable media functions, not every workload will move to software, COTS or the cloud. Dedicated hardware and hardware-accelerated platforms will still play a role in demanding 24/7 operations where density, reliability and predictability matter. Whatever the hybrid model chosen by broadcasters, industry-wide standards will drive innovation. For more information, please visit: nevion.com/moxela
24 | TVBEUROPE EBOOK 2026
ADVERTORIAL
MXL'S REAL TEST STARTS AFTER AMSTERDAM By Ian Wagdin, vice president technology and innovation at Appear
O
n the Sunday evening of IBC2026, the Media eXchange Layer (MXL) won the Content Creation Award at the Innovation Awards—not a product, not one company's engineering, but an open-source SDK hosted by the Linux Foundation and driven by the EBU and NABA, with code from Grass Valley, Lawo, Riedel, Appear, and a long list of others. What made this year different was that MXL turned up with something more persuasive than an award: version 1.1 shipped just over six months after 1.0.0 landed on 26th February, and more than a dozen stands showed the same media passing between different companies' software without a frame being re-wrapped on the way. That is the change worth recording. A year ago, MXL was a wellargued idea with a prototype attached. This year it was the real thing—something you could put in a build. WHAT MXL REMOVES The premise is narrow by design. MXL is the mid layer of the EBU's Dynamic Media Facility reference architecture, and it does one job: let media functions running on the same compute exchange uncompressed video, audio, and ancillary data through shared memory rather than over the network. Media lands in ring buffers in a shared-memory folder. Grains carry PTP-referenced timestamps. Multiple readers can attach to the same buffer, so the arrangement behaves more like a matrix than a cable. The discipline is what makes it interesting. MXL is a small C++ library, not a lengthy standards document, and it borrows existing concepts from NMOS and ST 2110 rather than inventing new ones—a host is a node, a media function is a device, a writer is a sender, a buffer is a flow. It asks that software inside a node stop behaving as though it were connected by cables. That behaviour is expensive. In most software chains today, essence is packetised, transmitted, received, depacketised, and re-timed at every application boundary, even when both applications run on the same server. Each hop costs latency and CPU, and where compression is introduced to make the hop affordable, it costs quality too. The commercial argument follows directly. Remove the overhead and more media functions fit on the same node: fewer servers, less power, and a different cost equation for anyone paying for cloud infrastructure by the hour. PRACTICAL APPLICATIONS ON REAL STANDS The demonstrations were revealing precisely because they were
26 | TVBEUROPE EBOOK 2026
unglamorous. Playout engines taking a live contribution feed directly from a software gateway. Audio chains passing between vendors. Multiviewers attaching to flows they did not have to receive over the network first. AI inference reading essence in place rather than through I/O it was never designed for. These are the workflows where the overhead has always been most visible, and they are the right places to start. Appear's contributions were of that kind. One, with Imagine Communications, took live input through the VX Platform into multiple XVR playout engines over MXL. Another connected Appear in the multi-vendor chain on the Grass Valley stand at IBC, alongside AMPP's native MXL 1.1 support. On Tata Communications' booth, an X5 connected to Tata's cloud, where the VX Platform handed media to Sony's M2L-X. The chain spanned edge hardware, cloud software, and another vendor's switcher—evidence that a multi-vendor workflow can bridge edge and cloud. MXL provided the common exchange layer rather than a bespoke point-to-point integration. That is the point. A BROADCASTER-LED PROJECT What should reassure anyone considering a business case is that MXL was never a vendor initiative looking for customers. The organisations publicly engaged include the BBC, France Télévisions, and several other EBU members, alongside CBC/Radio-Canada, Bell Media, and Olympic Broadcasting Services, with many more—US networks among them—engaged through NABA and JT-DMF. Several are contributing code, not just requirements. What they want from it is consistent: interoperability that arrives as standard rather than as an integration project, less complexity in the chain, and less latency through it. The detail matters, though. CBC applied the broader DMF principles at the Milano Cortina Games in February, but MXL itself was a direction of travel rather than a deployed component of that particular implementation. The early wins will be discrete tasks— clipping, multi-angle replay, graphics, monitoring—with full multivendor clusters following as products become available. STILL TO COME Anyone planning a technology refresh needs to be clear about where the boundaries sit. Before 1.1, MXL flow exchange was confined to a single physical server. The new MXL Fabric layer—software that mirrors one server's shared memory into another's—now replicates flows between hosts over accelerated networking. Reaching further,
ADVERTORIAL
Media eXchange Layer (MXL) partners receive the Content Creation Award at the IBC2026 Innovation Awards in Amsterdam
between separate groups of servers in different sites or different cloud regions, is still to come. The format list is deliberately short, and what it should cover next is still under discussion. Connection management is still being worked through as NMOS support for MXL. Nor is the outstanding work all technical: JT-DMF has separate workstreams on compute resource management—how a facility decides what runs where, and on what—and on the commercial models that come with buying media functions rather than boxes. Timing is where this gets interesting. Inside a node, grains carrying PTP-referenced timestamps are tractable. A facility running ST 2110 at the edge, MXL inside compute, and part of the chain in a cloud region has an end-to-end timing problem that no single layer solves. Solving that problem will decide whether a hybrid build is operable or merely demonstrable. It was, not coincidentally, the subject Appear's CTO, Andy Rayner, took to the EBU stand. THE BOUNDARY IS THE ARCHITECTURE It is important to note that MXL adds a layer rather than replacing another. The EBU's Willem Vermost contrasts transport efficiency with compute efficiency: ST 2110 delivers the first; MXL the second. ST 2110 remains how media gets in and out—cameras, venues, inter-facility links, playout to transmission. SDI is still there wherever
existing equipment connects. MXL changes how media moves once inside the software. Facilities will operate all three for years, and the boundary between them is not a staging post on the way to somewhere else; it is a permanent part of the design. MXL is not limited to ST 2110 workflows. With both NDI and MXL supported in Appear’s VX Platform, moving between the two is a straightforward workflow step. That is a more comfortable position than the early ST 2110 years, when adoption was framed as a cliff edge. MXL can be introduced one workflow at a time, where the overhead actually hurts, without committing a facility to a rebuild. WHAT TO ASK BEFORE YOU DEPLOY Several questions are worth putting to any vendor claiming MXL support. Which SDK version is supported, and does support mean reading and writing flows today or merely a roadmap slide? How are flows discovered and connected, and what happens at scale? Where does timing come from at the edges of your media function—not just in a demonstration, but in a facility that already has a PTP domain and an ST 2110 core? Several vendors can now give precise answers. That was not true in 2025, and it is a better measure of progress and collaboration.
TVBEUROPE EBOOK 2026 | 27