MXL SDK Integration
Port Your Broadcast Product to MXL.Stay Relevant in Software-Defined Production
Your customers — broadcasters and media operators — are moving to software-defined, vendor-neutral production on Dynamic Media Facility (DMF) architectures. However strong your current SDI, ST 2110, or NDI product is, it risks being locked out of the next generation of multi-vendor workflows running on shared COTS hosts and cloud compute.
Promwad ports existing media function products into MXL-native software components. We integrate the open-source MXL SDK, preserve sub-frame latency through shared-memory and RDMA data paths, and ship multi-arch, Kubernetes-ready builds your customers can drop straight into their DMF stack.
What YouAchieve
The MXL Moment: Why This Window,Why Now
In June 2025, the EBU, the Linux Foundation, and NABA launched the open-source Media eXchange Layer (MXL) SDK — a C++20 library that lets professional media functions exchange video, audio, and ancillary data natively in software, with the latency broadcast demands. From kickoff to first public release on GitHub, the project moved in under seven months.
The Technical Steering Committee reads like the customer base and competitive set of every broadcast vendor: the EBU, CBC/Radio-Canada as User-Chair, the BBC, Grass Valley as Implementor-Chair, Riedel, Lawo, NVIDIA, and AWS.
EBU CTO Antonio Arcidiacono has framed MXL as the enabler for vendor-neutral live production on modern IT infrastructure — which is another way of saying that broadcaster RFPs will increasingly require it.
The question for product CTOs is no longer whether to integrate MXL. It is how fast, how cleanly, and with whom.
Why Promwad
We are a European R&D partner built for product companies: when a vendor hands us a shipping broadcast product, we treat it as engineering IP to be preserved and extended, not rewritten for its own sake.
Discuss your product with our broadcast team!
Vadim Shilov, Head of Broadcasting & Telecom at Promwad
Our Tech Stack
Mapped to the layers of a modern broadcast product, so your engineering lead can match it to your internals at a glance.
MXL & interoperability core
MXL SDK (C++20), flow and grain data model, ring-buffer media buffer, continuous-buffer audio model, shared-memory abstraction (libfabric), RDMA/RoCEv2, AWS EFA, memory-locality awareness across host RAM, GPU, and accelerators, futex/mmap/tmpfs primitives for hypervisor-friendly operation.
Cloud and DevOps
AWS, Azure, GCP, CI/CD pipelines, observability with Prometheus, Grafana, and OpenTelemetry, SBOM generation, and security hardening pipelines designed for regulated customers.
Media standards and protocols
SMPTE ST 2110 (-20, -30, -40), ST 2022-6/7, SDI, NDI, SRT, MPEG-TS, AES67, RIST, WebRTC, JT-NM Reference Architecture.
Control, discovery, and timing
AMWA NMOS IS-04, IS-05, IS-07, IS-08, IS-09, BCP-002-*, SDP, PTP (IEEE 1588 and SMPTE ST 2059).
Platform and runtime
Linux with PREEMPT_RT and low-latency tuning, Docker, Kubernetes and Helm, multi-arch builds for x86_64 and aarch64, GStreamer, FFmpeg, CUDA, and NVIDIA Rivermax.
Application Areas: Product Categories We Port and Build
If your product fits one of the categories below, MXL integration is directly on your roadmap — and is exactly the kind of work we scope and deliver.
Video switchers and
vision mixers
Audio mixers and audio processors (AES67, ST 2110-30/-31)
Multiviewers and monitoring
tools
ST 2110, SDI, and NDI gateways and converters
Graphics rendering engines
and CG systems
Clip record and playback
servers
Camera control units and CAM shading applications
Transcoders, encoders,
and decoders
SRT, WebRTC, and cloud
contribution tools
General signal processing and conversion applications
Product Transformation Path: From Hardware-Anchored to MXL-Native
What actually changes when you port to MXL
| Dimension | Before (SDI / appliance / single-platform) | After (MXL-native, DMF-aligned) |
| Product form factor | Dedicated hardware or single-purpose appliance | Multi-arch container image |
| Deployment model | Customer buys hardware per site | Customer licenses software on shared COTS: on-prem or cloud |
| Media I/O | SDI / ST 2110 ingress and egress only | MXL shared-memory flows, with ST 2110, SRT, and NDI gateways at the edge |
| Latency profile | Per-hop packet serialization and copy | Sub-frame shared-memory exchange, asynchronous and faster than real time |
| Interop story | "Works with our other boxes" | Interoperates with any MXL-compliant vendor in a DMF stack |
| Revenue model | Capex hardware | Opex, subscription, or burst licensing |
Promwad's 5-Step Port
Whether you are hardening a shipping product or building a new one secure-by-design, the path is the same shape — a short, concrete engineering engagement, not an open-ended consulting track.
Product audit and gap analysis
We map your current media paths, timing model, driver dependencies, and certifications against the MXL SDK and the DMF Reference Architecture — and deliver a written gap analysis with scoped options.
MXL integration proof-of-concept
We isolate one media path — typically video first, then audio, then A/V sync — bring up MXL flows, and benchmark latency and CPU cost against your current pipeline. Usable outcome in two to four weeks.
Full SDK integration and decoupling
We remove hardware and appliance assumptions from the media engine, restructure the code into MXL-native components using the flow, grain, and ring-buffer model, and retain legacy I/O (SDI, ST 2110, NDI) at the edges where your customers still need it.
Multi-arch packaging and orchestration wiring
x86_64 and aarch64 builds, bare-metal and container variants, NMOS IS-04/IS-05 registration, Kubernetes manifests, and security hardening — production-grade, not demoware.
Interop validation and customer pilot support
We test your product against mainline MXL SDK releases, validate it against peer-vendor implementations, and support your first broadcaster pilot all the way through handover to your own sustaining team.
Our Case Studies
Pain → Solution → Result. Anonymized at client request.
Porting an SDI-anchored vision mixer to MXL-native software
Pain
A tier-one mixer vendor was losing RFP points for lacking a credible cloud and multi-vendor story. The product's media engine was tightly coupled to an FPGA pipeline and a proprietary chassis.
Solution
Promwad led the MXL SDK integration. We decoupled the media engine from the FPGA, re-homed it in MXL-native C++20 code using the flow and grain model, and kept SDI and ST 2110 I/O as edge adapters for backward compatibility.
Result
Sub-frame internal latency on COTS hardware, Kubernetes-ready container image on x86_64 and aarch64, two broadcaster pilots signed within one quarter of the first public demo.
Bringing a ST 2110 multiviewer into a DMF-aligned workflow
Pain
A multiviewer product was tied to a bespoke appliance with no realistic path to shared COTS hosts. Customers running DMF proofs-of-concept were requesting MXL support that did not exist.
Solution
Promwad implemented MXL flow consumers for the GPU-accelerated rendering path, added NMOS IS-04 and IS-05 control, and split the build for x86_64 and aarch64 so the product could run on the customer's chosen infrastructure.
Result
Interop tested with three peer vendors at an industry demo event, unlocked two existing customers' DMF adoption roadmaps, and opened a new software-licensing revenue line for the vendor.
Audio processor moving from AES67 appliance to MXL continuous-buffer flows
Pain
An audio processing product serving live events and studio playout was facing a new generation of software-first customers who would not deploy appliances.
Solution
Promwad implemented the MXL audio-specific continuous-buffer model (non-interleaved multichannel, grain rate equal to sample rate) and built A/V sync across mixed granular and continuous flows — the toughest challenge in current MXL work.
Result
Predictable latency under 10 ms on standard servers, cloud-deployable on AWS with EFA, ready for multi-vendor DMF integration, and a new product variant shipping under an Opex licensing model.
How We Ensure Quality
Broadcast is a low-tolerance environment. A two-frame glitch is visible on every screen in a stadium. Our quality process reflects that.
Engineering process
V-model and Agile hybrid, with stage gates calibrated to broadcast risk tolerance — requirements traceability, formal reviews at integration points, and pre-release freeze windows aligned with your shipping cadence.
MXL interop lab
PTP-locked ST 2110 reference clocks, multi-vendor MXL test matrices, packet capture and timing analysis, and fault-injection rigs for network and compute failures. We test what the standard says and what the real world does.
Performance engineering
Latency-budget tracking at every pipeline stage, NUMA-aware tuning, CPU and GPU profiling, RDMA path validation, kernel-bypass verification, and A/V sync measurement under load — not just at idle.
Security
Threat modeling for media pipelines, container hardening, SBOM generation, and secure build pipelines suitable for customers with regulatory oversight.
Compliance
ISO 9001 and ISO/IEC 27001 for process and information security, IPC standards for any hardware work, and functional-safety discipline imported from our automotive and industrial practice.
Open-source stewardship
Where it benefits your product, we contribute upstream to MXL and adjacent projects — so your product stays on stable mainline rather than aging on a private fork.
Trusted by Product Companies in Broadcasting, Telecom, and Beyond
Promwad engineers have shipped products with OEMs and technology vendors across broadcasting, telecom, automotive, and industrial automation. Our work is trusted by companies whose own customers demand guarantees on latency, reliability, and long-term support.
Get Your Product onto the MXL Platform Before Your Customers' RFPs Demand It
The MXL SDK is moving fast. Vendors who move first will set the integration patterns their competitors have to match.
You do not need to commit to a multi-year transformation on day one. Start with a two-week MXL integration proof-of-concept on one media path of your product.
FAQ
What is the MXL SDK, and who is behind it?
Why should a vendor with a proven ST 2110 product invest in MXL now?
Does MXL replace ST 2110 and NDI in our product, or sit alongside them?
How does Promwad approach porting a legacy media function to MXL?
What is the typical timeline and team shape for an MXL integration project?
How do you protect our IP during development?
Can MXL-integrated products run on both x86_64 and aarch64, on-prem and in the cloud?
Is the MXL SDK production-ready today, and when will it stabilize?