Skip to content
Amira Labs

MXL Explained: What Broadcasters Need to Know About the Media eXchange Layer Before IBC 2026

August 14, 2026

Here is a thing that happens in a modern software-defined facility, and it should bother you.

You have a switcher, a multiviewer, and a graphics engine. All three are containers. All three are running on the same server, on the same CPU, inches of copper apart. To move a frame of 1080p video from the switcher to the multiviewer, that frame gets chopped into RTP packets, handed to the kernel, pushed out a NIC, looped back in, reassembled, and buffered. Roughly 20 milliseconds and several thousand CPU cycles later, it arrives at a process that was sitting in the same block of RAM the whole time.

SMPTE ST 2110 was designed to move video between devices across a facility, and it does that job well. Then the devices became software, and the industry kept using a facility transport to move frames between processes sharing a motherboard.

The Media eXchange Layer fixes that inefficiency. Fixing it is the mechanism, though, not the mission. The EBU and the project's own documentation are specific about the goal: an open, non-proprietary exchange layer, required by the Dynamic Media Facility Reference Architecture, that lets software media functions from different vendors work together inside the same compute. Broadcasters did not fund this work to save CPU cycles. They funded it so that choosing a production switcher would not also mean choosing your graphics engine, your audio mixer, and your replay system.

What is MXL?

MXL (Media eXchange Layer) is an open-source SDK that lets software media functions running on the same host exchange uncompressed video, audio, and ancillary data through shared memory instead of over the network. It is licensed Apache-2.0, hosted by the Linux Foundation, and driven by the EBU together with NABA and AMWA. Version 1.0.0 shipped on 26 February 2026.

The simplest accurate analogy: ST 2110 is a courier service. MXL is a shared whiteboard.

With a courier, the sender copies the content, packages it, hands it off, and the recipient unpacks it. That is the right model when the two parties are in different buildings. With a whiteboard, the writer writes once and every reader looks at the same surface. Nothing is copied, nothing is packaged, and the only coordination needed is "don't read the corner I'm currently writing in."

MXL is the whiteboard. A writer process places a frame directly into a shared memory region. Reader processes map that same region read-only and access the pixels in place. No serialization, no kernel transit, no duplication per consumer. BBright measured average end-to-end latency of about 1.23 ms on a UHD 50p passthrough inside a Docker container, with no measurable penalty against native performance and zero payload-integrity failures across more than 10 billion verified bytes.

That is the whole idea. The rest is engineering detail.

What MXL is not

This matters more than the definition, because most of the confusion in the market comes from people assuming MXL is something it isn't.

MXL is not a network transport. Version 1.0 works on a single host only. Cross-host movement exists as a separate Fabrics API, still in beta.

MXL is not a replacement for ST 2110. You still need 2110 (or SDI, or SRT, or whatever) to get signals into and out of your compute. MXL handles what happens between the edges.

MXL is not a codec. It carries native uncompressed essence. There is no compression layer.

MXL is not an orchestration or discovery system. It does not tell you what flows exist, where to put a function, or how to connect A to B. That is NMOS and the wider DMF work, deliberately kept out of scope.

MXL is not a media framework. It is a thin library with a small API. Your application logic stays yours.

Why does MXL exist?

Because the people who have to actually build these facilities got tired of waiting.

The origin is unusually well documented, and it is a user-led story rather than a vendor one. Félix Poulin at CBC/Radio-Canada laid out the problem publicly at VSF VidTrans in February 2025. CBC faces a multi-year brownfield rebuild of the Toronto Broadcast Centre. They want production spaces that can be reconfigured for any production type, and they want cheap regional live production without stationing infrastructure in every region. When they surveyed the market, they found plenty of vendors selling capable "studio-in-a-box" software, and not one that covered every workflow they run.

That leaves two options. Pick one vendor and accept lock-in across your entire production estate, or find a way to make multiple vendors' software functions cooperate inside the same compute.

In November 2024 the EBU convened an industry alignment meeting in Geneva. Broadcasters presented requirements. Seven invited vendors, later nicknamed the Tiger Team, committed to building a common solution. According to the ACM Mile High Video paper written by participants from AWS, Grass Valley, the EBU, and BBC R&D, the room reached roughly 90 percent consensus. A follow-up session ran at CBC Toronto on 18 and 19 March 2025.

The strategy chosen was code first, standardize later. Ship a working prototype, iterate in public, formalize once the shape is known. Fifteen months from that first meeting to a stable 1.0 is fast by any standard in this industry, and it happened because nobody spent two years arguing in a committee before writing code.

How MXL actually works

Four concepts, and they map cleanly onto things you already know.

Domain. A namespace, implemented as a directory on a RAM-backed filesystem (typically /dev/shm/mxl). Everything inside one domain can see everything else. Think of it as the shared memory equivalent of a facility subnet.

Flow. One unidirectional stream, identified by UUID. On disk it is a directory containing a small memory-mapped header, a flow_def.json describing the flow, and a grains/ folder. The JSON deliberately borrows NMOS IS-04 vocabulary, so if you know NMOS you already know how to read it.

Grain. One unit of media. For video, one frame. For audio, samples in a continuous per-channel ring buffer.

Ring buffer. Video and ancillary data use discrete ring buffers, audio uses continuous ones. Writers commit grains, readers index into them.

Two implementation choices are worth calling out because they tell you the engineering is serious. First, grains are indexed against the SMPTE ST 2059-1 / TAI epoch, which means there is no sequence-number negotiation between writer and reader. A reader asks for the grain at a given moment in time and gets it. Second, readers map memory PROT_READ, so a compromised or crashed reader physically cannot corrupt the media. Signalling uses Linux futexes rather than POSIX mutexes, precisely because readers have no write access.

There is also slice-level access. mxlFlowReaderGetGrainSlice() lets a consumer read part of a frame before the whole frame is committed, which opens the door to sub-frame latency processing chains.

Supported essence in 1.0 is intentionally narrow: video/v210 (10-bit 4:2:2), video/v210a (v210 with alpha, for fill and key), audio/float32 at 48 kHz, and video/smpte291 for ancillary data. That is a small set of operating points, chosen so that interop actually works rather than becoming a matrix of optional features.

MXL vs ST 2110: the comparison broadcasters keep asking for

This is not a scoreboard. These two things are stacked, not competing.

  • Scope. ST 2110: between devices, across a facility. MXL: between processes, within a host.
  • Mechanism. ST 2110: RTP/UDP over IP. MXL: POSIX shared memory (mmap, tmpfs).
  • Data copies. ST 2110: multiple — user to kernel to NIC and back. MXL: zero.
  • Latency. ST 2110: around 20 ms per device hop. MXL: under 1 ms per transfer.
  • Timing. ST 2110: PTP required, PTP-aware switches. MXL: NTP sufficient on a single host.
  • Network. ST 2110: engineered multicast fabric, PTP-aware. MXL: standard Linux, no special fabric.
  • Model. ST 2110: sender pushes to receiver. MXL: writer publishes, readers access.
  • Discovery. ST 2110: NMOS IS-04 / IS-05. MXL: NMOS IS-04 / IS-05 via AMWA BCP-007-03.
  • Multi-host. ST 2110: native. MXL: Fabrics API, still beta.

The 20 ms and sub-1 ms figures come from TAG Video Systems' MXL technical guide, authored by their VP of Product Strategy. Treat them as indicative rather than independently standardized, but the direction is not controversial.

A realistic 2027 signal chain looks like this: ST 2110 or SRT arrives at the edge of your compute cluster. A receiver function writes it into an MXL flow. Six software functions read that flow with near-zero latency, doing production switching, multiviewer rendering, graphics compositing, loudness monitoring, caption generation, and QC. An output function reads the result and emits ST 2110 back onto the facility network. Appear demonstrated exactly this hybrid pattern at IBC 2025.

The efficiency gain is easiest to see in the bandwidth math. On a single host, those six functions all read the same 5.27 MiB HD frame from the same memory. Under 2110, each of those six paths would consume its own 2.2 Gbit/s of NIC and switch capacity. Six streams becomes one memory region.

NMOS is the bridge between the two worlds. AMWA BCP-007-03 defines a new transport type, urn:x-nmos:transport:mxl, with mxl_domain_id and mxl_flow_id parameters and no transport file. Your existing NMOS controller concept survives the transition. That specification is still in development, which is one of the reasons full production deployment is not a today conversation.

Who is actually using MXL?

Be careful reading vendor press releases here. "Supports MXL" and "runs MXL in 24/7 production" are very different claims, and almost everything in the market today is the first one.

Broadcasters involved: BBC, CBC/Radio-Canada, Bell Media, Dome Productions, France Télévisions, Olympic Broadcasting Services, RTÉ, SRG SSR, SVT, Sveriges Radio, SWR/ARD, VRT. CBS/Paramount presented via NABA at NAB 2026.

Vendors and implementers: Appear, AWS, Grass Valley, Intel, Lawo, Matrox, NVIDIA, Riedel, and Telos Alliance as founding participants, joined since by TVU Networks, Sony, NetOn.Live, Zoom, TAG Video Systems, Techex, Ross Video, Cisco, Skyline, BBright, Qvest Digital, Wavelet Beam, SSL, and Imagine Communications.

The Technical Steering Committee is co-chaired by CBC/Radio-Canada on the user side and Grass Valley on the implementer side, with BBC, Riedel, Lawo, NVIDIA, and AWS.

Where adoption actually stands: experiments, proofs of concept, and early product integration. Matrox ORIGIN ships MXL support. Grass Valley has it in AMPP. TVU has MediaMesh, NetOn.Live has LiveOS, SSL has the Virtual Tempest Engine. CBC ran a proof of concept for selected Milano-Cortina 2026 Olympic workflows. AWS hosted an 11-vendor interop at NAB 2026, pushing toward multi-host.

What does not exist yet, publicly, is a full 24/7 production chain running on MXL. Worth noting the counterexample: SVT's Neo platform won the EBU Technology and Innovation Award 2026 after delivering 800+ hours and 150+ productions across ten parallel environments at the Winter Olympics. Neo is the flagship software-defined production success story, and it is not documented as MXL-based. Software-defined production is already working. MXL is about making it work across vendors.

Geographically, the center of gravity is EBU-member Europe and North America. APAC involvement is lighter, mostly on the vendor side. The initiative is explicitly global, not regional.

What do you actually use MXL for?

Live production and switching. The core case. Multiple software functions on shared compute.

Remote and regional production. CBC's stated driver. Their example splits a contribution decoder, video processing, audio, and graphics across vendors and compute nodes.

Multiviewer, monitoring, and QC. The natural first pilot, because a monitoring path is a read-only consumer. If it breaks, nothing goes to air wrong. TAG has been vocal here for a reason.

Graphics and compositing. The existence of v210a for fill and key tells you keying was designed in from the start, not bolted on.

AI inference on live essence. This is where MXL gets genuinely interesting, and it is the part most people underrate. Captioning, translation, audio classification, video quality analysis, and content moderation all need frame-accurate access to pixels and samples, and all of them are latency-sensitive. Under a 2110-only model, every inference function is another 20 ms hop and another full-bandwidth stream. Under MXL, an inference worker becomes a read-only consumer of a flow that is already in memory. That is the pattern Amira Labs intends to use: consume MXL as a Sense tap source, so monitoring and inference attach as readers instead of as another network hop. It is the difference between AI functions being expensive add-ons and being cheap to attach.

Replay, ingest, and faster-than-live file work. The API is asynchronous by design, so nothing forces processing to run at 1x.

What does MXL cost?

The SDK is free. Apache-2.0, no license fee, no per-seat cost, no royalty. The EBU describes MXL and the surrounding specifications as "the rails for an ecosystem, and their use is free of charge."

That is the easy part. The real costs are:

Engineering labor. Integration, porting functions, and building the surrounding orchestration. This dominates everything else today. Third parties including Qvest and Promwad now sell MXL integration services, which tells you how substantial this line item is.

Hardware and RAM. Uncompressed essence in memory is not free. Budget generously.

Cloud networking. Compute is cheap. Moving data is not. Egress and cross-availability-zone traffic will surprise you.

Vendor products. Anything embedding MXL still carries its own price tag.

The ROI number worth memorizing

AWS published primary research across more than ten live production organizations. For a 90-minute cloud production, compute cost runs to about $15. Configuration and labor cost runs to about $890.

Sit with that ratio. The infrastructure is already nearly free. Almost sixty times more money goes into humans wiring things together than into the machines doing the work. That is the actual target of the whole Dynamic Media Facility effort, and it is the honest ROI case for MXL: not saving money on servers, but collapsing the setup labor that makes flexible production economically unattractive today.

Be equally honest about what is not yet quantifiable. Whole-facility ROI depends on layers that are unfinished. Anyone presenting you a confident MXL TCO model in 2026 is selling something.

What do you need to run it?

Operating system. Linux, with a RAM-backed tmpfs mount for the domain. The SDK includes mxlIsTmpFs() specifically to stop you from accidentally running on disk. macOS builds, but the support is basic.

Runtime. Docker and Kubernetes are both supported. Domains reach into containers via volume bind mounts. Notably, containers do not need to share an IPC or process namespace, which keeps the security model sane.

Hardware. Commodity x86 or ARM servers. GPUs where you need them, and NVIDIA's Holoscan for Media integrates for GPU-accelerated and AI functions. For multi-host: RDMA-capable NICs using RoCEv2 or InfiniBand, or AWS EFA in cloud.

Toolchain. C++20, CMake with vcpkg, and a devcontainer if you want to skip dependency wrangling. There is a C API, Rust bindings, a Go binding from Qvest, and GStreamer plugins as of the 1.1 beta. Diagnostic tools include mxl-info and mxl-data-probe.

Timing. NTP is enough on a single host. Multi-host synchronization is still being specified by the JT-DMF working group, and this is a real gap.

Bandwidth: the numbers your architecture team will ask for

The key shift in thinking is that MXL's bandwidth requirement is a memory bandwidth question, not a network one. Same essence, same volume, different bus.

For v210, which packs six pixels into sixteen bytes with 128-byte line alignment:

  • HD 1920×1080 v210. 5,529,600 bytes (5.27 MiB) per frame, 2.212 Gbit/s at 50 fps.
  • UHD 3840×2160 v210. 22,118,400 bytes (21.1 MiB) per frame, 8.85 Gbit/s at 50 fps.

Audio at float32 48 kHz runs 192 kB/s per channel, so 1.536 Mbit/s. Sixteen channels is 24.576 Mbit/s, which is noise next to the video on either bus.

Two details engineers will catch. First, v210 in RAM is about 6.7 percent larger than tightly-packed ST 2110-20 active essence for the identical signal, because v210 wastes two bits per 32-bit word and pads lines. HD 1080p50 over 2110 is roughly 2.143 Gbit/s versus 2.212 Gbit/s for the same picture in an MXL flow. Second, and far more important, that overhead is charged once. Additional readers cost essentially nothing, because they map the same pages read-only. Under 2110, every additional consumer is another full stream on the wire.

On-prem, cloud, or hybrid?

All three, with different mechanics.

Same host, anywhere. Pure shared memory via tmpfs. This is where MXL is production-ready today.

Multi-host on-prem. RDMA over RoCEv2, through the Fabrics API. Beta.

Multi-host in cloud. AWS EFA or equivalent, with a TCP provider available for development and testing.

The Fabrics design preserves grain indices, flow IDs, and ring buffer geometry across hosts, so a reader does not need to know whether the writer is local. Qvest's open-source mxl-k8s adds automated cross-node transport as a Kubernetes cluster feature using an operator plus agent and gateway DaemonSets. Their public demo runs a ten-flow test pattern writer on one node feeding a nine-tile compositor and viewer on another, across the gateway fabric on managed Kubernetes.

Cloud adds complications that on-prem does not have: hypervisor virtual switches, overlay networks, availability zone hops, and region boundaries. AWS has been candid that getting signals in and out of cloud compute remains the unsolved part, which is the gap products like TVU MediaMesh are aiming at.

The honest limitations

If you take one section to your CTO, make it this one.

Single host in 1.0. Cross-host is beta. Plan accordingly.

Narrow essence support. No compressed formats. No explicit HDR or wide-gamut signalling beyond what the flow JSON carries. Uncompressed only means a large memory footprint.

Missing surrounding layers. Discovery and connection management depend on BCP-007-03, still in development. Orchestration is out of scope. Cross-host synchronization is an open JT-DMF work item. You will build or buy these yourself in 2026.

Security is UNIX file permissions. Domain and flow level, nothing more. Read-only reader mapping is a genuinely good property, but there is no built-in encryption or authorization. A JT-DMF security workgroup proposed by Ross Video is addressing this. It is not addressed yet.

Linux and tmpfs required. No multicast, since the Fabrics layer is primarily unicast.

Small support ecosystem. There is no MXL support SLA. When it breaks at 02:00, you are calling the vendor whose product embeds it, an integrator, or reading GitHub issues. Documentation is improving and still described by the project itself as maturing.

Repository scale, for calibration. As of 14 August 2026: roughly 152 stars, 61 forks, and 48 open issues. Vincent Trussart of Grass Valley manages releases, with frequent contributions from Jonas Ohland and Sithideth Viengkhou at Riedel, Gareth Sylvester-Bradley at NVIDIA, and Qvest. This is a healthy, focused project with real vendor engineering behind it. It is not a large open-source ecosystem, and you should not plan as though it were.

Where MXL and DMF are heading

MXL releases. 1.0.0 in February 2026, 1.0.1 in May, 1.1.0 Beta 1 on 9 June adding the Fabrics inter-host API, GStreamer plugins, and the data probe tool. Full 1.1 is targeted for Q3 2026, which means it may land right around IBC.

DMF Reference Architecture v2.0 published 15 April 2026, adding orchestration as an explicit cross-cutting function.

JT-DMF, the joint EBU and AMWA task force, kicked off in Geneva in Q4 2025 with around 110 participants on site and online. Four workgroups are running: End-to-End Synchronisation, Compute Resource Management, Flow Connection, and Business and Governance, with a Security workgroup proposed. Face-to-face meetings ran in New York and Geneva in the first half of 2026.

Read the workgroup list carefully, because it is a map of what is missing. Synchronization, resource management, and connection management are exactly the three things standing between MXL working in a lab and MXL running your facility. Track those four groups and you will know when to move.

MXL at IBC 2026

IBC runs 11 to 14 September 2026 at the RAI in Amsterdam. Here is what is confirmed as of mid-August.

The VSF and AIMS IP Showcase on the Water, Sunday 13 September, departing from Strandzuid. Sessions 1 and 2 are both titled "MXL and Dynamic Media Facilities," with speakers from AWS, Appear, BFE, Grass Valley, Imagine Communications, Lawo, Matrox, NSI2 Consulting, NVIDIA, PlexusAV, Skyline, intoPIX, and Ross Video. Two consecutive sessions on one topic, on a boat, with thirteen organizations on the speaker list. That is the single highest-density MXL conversation of the show.

The EBU DMF group lists a DMF-MXL demonstration at IBC 2026 as a Q3 deliverable, currently in progress.

Qvest is running a live DMF and MXL demo at booth 10.C24, including Wavelet Beam's IRIS video denoising as an MXL function, plus a guided "Hitchhiker's Guide to MXL" tour and an explainer session with Willem Vermost of the EBU.

Matrox is showing ORIGIN with its MXL-compatible media fabric. SSL is showing the Virtual Tempest Engine and µVTE alongside Techex TX Darwin.

What is reasonable to expect but not yet published in detail: an expanded multi-vendor interop, very likely the first serious public multi-host demonstration now that Fabrics is in beta, an EBU stand presence continuing from IBC 2025, and a wave of vendor announcements timed to the 1.1 release. Treat that paragraph as trajectory, not fact.

What to ask vendors on the floor. Four questions, and the answers will separate marketing from engineering fast.

  1. Is your MXL support single-host only, or have you tested cross-host with the Fabrics API?
  2. Which essence formats do you actually read and write? v210 only, or v210a and ANC too?
  3. What are you using for discovery and connection today, and are you tracking BCP-007-03?
  4. When a flow stalls in production, what is your support path?

Who should care, and who should not

Start now if you are a mid-to-large broadcaster or production house with real IT and DevOps capability, running a facility rebuild or a cloud production mandate, deliberately trying to avoid single-vendor lock-in, or building media functions as a vendor. Public service broadcasters, live sports operations, and rights-holders at Olympic scale are the natural early adopters, which is exactly who is on the participant list.

Wait if you are running a small operation without engineering staff, happy with a hardware and 2110 plant and under no software transition pressure, or unable to accept a technology with no support SLA. There is no shame in the second column. MXL will still be there, more mature, in eighteen months.

The one thing everyone should do regardless: put MXL and DMF alignment language into your RFPs now. It costs nothing. It signals to vendors where the market is going. And it preserves your ability to change your mind later, which is the actual thing you are buying.

Your next 90 days

A staged plan, with triggers rather than dates, because dates in an emerging spec are fiction.

Phase 1, now through six months. Build a lab and skills. Clone the MXL repository. Run the CBC/Radio-Canada hands-on workshop, four exercises from a single writer through to audio and video in a GStreamer-based DMF ecosystem, authored by Félix Poulin, Mathieu Rochon, Anthony Royer, and Sunday Nyamweno. It runs on WSL, Ubuntu, Alma, or a Mac with Docker and a RAM disk. Assign one engineer to track JT-DMF and BCP-007-03 as a standing responsibility. Total cost: staff time.

Trigger to move on: a real software-defined or cloud production initiative appears on your roadmap.

Phase 2, six to eighteen months. Pilot something that cannot hurt you. Pick a read-only workflow. A multiviewer, a monitoring and QC path, a caption or metadata generator running in parallel with your existing chain. Single host or single cloud node. Use vendor products that already embed MXL rather than writing your own functions on day one.

Trigger to advance: MXL 1.1 stable with Fabrics, a working NMOS controller supporting BCP-007-03, and at least two of your strategic vendors shipping production MXL.

Phase 3, eighteen to thirty-six months. Multi-host, then production. RDMA on-prem or EFA in cloud, orchestrated under Kubernetes. Evaluate mxl-k8s rather than building your own cross-node transport. Keep ST 2110 at the edges with MXL gateways.

Trigger to full production: JT-DMF synchronization and resource management outputs published, a security model beyond UNIX permissions, and a support path you would actually stake a live show on.

What would change this plan. If Fabrics is still beta past 2027, defer multi-host production and keep 2110 doing more work than you hoped. If a vendor you depend on declines to support MXL, weight your architecture toward their fabric and revisit. If discovery and connection management stall, add engineering headcount to your integration budget, because you will be building it.

The takeaway

MXL is real, it is moving faster than almost anything else in broadcast standardization, and version 1.0 does exactly one thing well: it removes the network from conversations that never needed one. That is a smaller claim than the marketing around it, and a more useful one.

The gap between MXL working and a Dynamic Media Facility working is not in MXL. It is in synchronization, discovery, orchestration, and security, all of which are actively being built and none of which are finished. Broadcasters who spend 2026 building skills and running low-risk pilots will be ready when those layers land. Broadcasters who wait for a turnkey product will be integrating in 2028 at a consultant's day rate.

The SDK is free. The labs exist. There is no reason not to have someone on your team who has actually run it.

Sources

Get startedBook a demoPre-order hardware