MXL and the next step in software-defined broadcast workflows

Strategic message

BBright’s approach is to make broadcast infrastructure more open through interoperability, while keeping the core media path stable, deterministic and fully under operational control.

Broadcast infrastructures are entering a new stage of software transformation. SMPTE ST 2110 has already moved the industry away from monolithic baseband systems toward IP-based, essence-separated media flows. At the same time, broadcasters are looking at software-based processing, artificial intelligence, metadata enrichment, compliance automation, monitoring, and dynamic content adaptation as practical ways to improve operations and create new services.

The opportunity is significant, but so is the architectural risk. A live broadcast chain is not a generic IT pipeline. It has to preserve frame-accurate timing, predictable latency, synchronization between video, audio and metadata, and continuous operation under load. Adding software functions to that environment is not simply a matter of connecting APIs or deploying containers. The challenge is to introduce flexibility without weakening the reliability of the core broadcast system.

This is where the Media eXchange Layer (MXL), developed within the EBU Dynamic Media Facility initiative, becomes particularly interesting. MXL proposes a standardized way to exchange media between software functions. Instead of requiring every software module, AI engine or third-party processing service to understand the full complexity of a broadcast infrastructure, MXL can act as a controlled interoperability boundary between the real-time media domain and the software processing domain.

For BBright, this boundary is central to the next generation of broadcast appliances and solutions. The strategic objective is not to replace the stable broadcast core with a collection of loosely coupled software services. It is to keep ST 2110 ingest, egress, synchronization, buffering, fallback and operator supervision under broadcast-grade control, while allowing external media functions to be deployed, updated, isolated and orchestrated as software services.

In other words, the value proposition is dual: interoperability on the software side, core stability on the broadcast side. MXL can provide the interface that allows these two requirements to coexist. This opens the door to more modular and intelligent infrastructures, but it also creates engineering challenges that must be addressed carefully.

Figure 1 – MXL as an interoperability boundary between deterministic broadcast infrastructure and software services.

Figure 2 – The three engineering challenges that must be addressed in MXL-based architectures.

1. Preserving deterministic media behavior across a software boundary

The first challenge is to preserve deterministic media behavior while opening the system to external software functions. This is the core architectural tension. Broadcasters want the agility of software, but they cannot accept a media path that becomes unpredictable, opaque or difficult to supervise.

Many software functions come from a very different execution world. File-based workflows, cloud services and AI frameworks often assume buffering, elastic processing and asynchronous execution. AI-based tools are a good example. They typically consume decoded image buffers, perform inference, and return metadata such as labels, object coordinates, confidence scores or segmentation masks. These tools can be extremely valuable, but they do not naturally behave like deterministic broadcast devices.

MXL should therefore not be presented as a mechanism that makes software magically deterministic. Its role is more precise and more useful: it provides a structured media exchange layer where timing, media identity, grain structure and metadata can be preserved across the boundary. The real-time responsibilities remain with the broadcast platform. The platform continues to handle ST 2110 ingest and output, synchronization, signal compliance, buffering strategy, fallback and operator supervision.

This distinction is important for BBright’s positioning. Interoperability must not mean handing control of the media path to uncontrolled third-party components. It must mean creating a well-defined extension zone in which software services can operate safely. The broadcast core remains stable; the software layer becomes more open.

In practical deployments, this requires a clear separation between the media data path, the control and orchestration path, and the fallback path. The media path must carry payloads and timed metadata with the lowest possible disturbance. The control path must allow services to be configured, monitored, started, stopped, updated or bypassed. The fallback path must guarantee continuity if a software component fails, becomes too slow, or produces invalid output.

When this separation is respected, broadcasters can add new capabilities without redesigning the entire infrastructure. A compliance engine, an AI inference service, a metadata enrichment module or a rendering function can be introduced as a modular service, while the appliance remains responsible for the deterministic behavior expected in a live facility.

BBright takeaway

The stable broadcast core must remain the authority for timing, synchronization, compliance and fallback. MXL creates the interoperability layer that lets software innovate around that core without destabilizing it.

2. Avoiding unnecessary copies in UHD and HDR workflows

The second challenge is data movement. In professional media systems, moving video frames is often more expensive than the processing itself. A UHD 3840 x 2160 10-bit 4:2:2 frame represents a large memory payload. At 50 or 60 frames per second, unnecessary copies quickly become one of the dominant costs in the system. This becomes even more critical in HDR, multi-channel or appliance-based deployments where several flows may be processed simultaneously.

The risk is easy to underestimate. A naive integration can copy the same frame several times: from the input process to a plugin, from the plugin to an AI framework, from CPU memory to GPU memory, and then back to the output process. Each copy adds latency, consumes memory bandwidth and reduces scalability. In a laboratory prototype this may be acceptable. In a production appliance, it becomes a limiting factor.

MXL is attractive because it is designed around shared media exchange. The objective is to move references, timing information and metadata wherever possible, rather than duplicating full-frame payloads repeatedly. For BBright, this is not only a performance optimization. It is part of the strategic model: interoperability should not be achieved by adding inefficient bridges between systems. It should be achieved through a disciplined exchange layer that respects the economics of real-time media.

BBright recently evaluated this question on an internal UHD v210 passthrough benchmark. The test used uncompressed UHD video at 3840 x 2160, v210, 50 Hz, with a grain size of approximately 21.1 MiB. Three deployment modes were compared: in-process execution, separate native host processes, and a host plus Docker container sharing the MXL domain through tmpfs and host IPC.

The passthrough stage applied an actual byte-level transformation to the payload. It was not a no-op. This point matters because the purpose was to validate that the full frame was read, modified, written and checked. The results are encouraging. The Docker-based deployment showed an average end-to-end latency of approximately 1.23 ms, with no measurable penalty compared with the native modes. Payload integrity was preserved, with zero mismatch over more than 10^10 verified bytes in the Docker run. The measured DRAM read bandwidth was approximately 1.5 GB/s, indicating that the shared-memory architecture and CPU cache behavior significantly reduced pressure on main memory.

These measurements do not yet validate a complete AI processing chain. They validate the MXL and containerized media-exchange baseline on top of which AI inference, format conversion and GPU rendering can be added. That baseline is important because it shows that low-latency UHD media exchange across process and container boundaries is realistic when the media path is designed correctly.

Figure 3 – Internal BBright measurements on UHD-1 v210 50p media exchange across native and Docker deployment modes.

Engineering implication

Containerization is not the problem by itself. Uncontrolled data movement is the problem. An MXL-ready architecture must minimize copies and keep the media payload on a predictable path.

3. Treating containers as an operational tool, not just a deployment format

The third challenge is operational. Containerization is one of the most promising tools for software-defined broadcast infrastructure, but it must be used for the right purpose. Containers are valuable because they provide isolation, reproducibility, dependency management and lifecycle control. They allow a media function to bring its own runtime, model dependencies, GPU libraries and update cycle without being linked directly into the core broadcast process.

This is especially important for AI and advanced media processing. AI software stacks evolve quickly. They may rely on Python runtimes, deep learning frameworks, GPU acceleration libraries and model-specific dependencies. Asking those components to behave like native ST 2110 devices would create unnecessary complexity. A cleaner model is to place them behind an MXL boundary, where they can consume and return media-related data through a controlled interface.

However, containers must not become hidden media transport layers. If frames are routed through network overlays, copied through intermediate buffers or serialized through unsuitable APIs, the container boundary will appear expensive. In that case the issue is not the container itself, but the way the media path has been designed.

In BBright’s UHD MXL passthrough test, the Docker container shared the host IPC namespace and mounted the same tmpfs-backed MXL domain. There was no network overlay in the media path, no proxy buffer and no additional memory virtualization layer. Under those conditions, latency, jitter, DRAM bandwidth and payload integrity were indistinguishable from the native co-located process.

This leads to a practical design principle for future broadcast appliances: the container should be an operational isolation boundary, not a transport mechanism for media payloads. It should help with deployment, crash isolation, lifecycle management, cybersecurity, update control and service supervision. It should not introduce opaque copies or uncontrolled timing behavior into the media path.

For production systems, this implies a broader operational model. CPU and GPU resources must be allocated deliberately. Shared-memory access must be controlled. Images must be signed and scanned. Health checks must be connected to supervision logic. Most importantly, deterministic bypass must remain available if a containerized function fails. This is where BBright’s message becomes concrete: open interoperability must be paired with a stable, supervised and resilient broadcast core.

Operational principle

Containers should make media functions easier to deploy, isolate and update. They should not redefine how the real-time media path behaves.

Why this matters for AI in broadcast

MXL is not only relevant for simple media filters. It is also a strong candidate for integrating AI services into broadcast infrastructures. AI-based processing is powerful precisely because it can bring capabilities that traditional broadcast systems were not designed to provide: object detection, logo recognition, compliance analysis, content segmentation, automated quality control, metadata enrichment and context-aware monitoring.

But AI also introduces new operational risks. Models may have variable execution times. Inference frameworks may depend on rapidly changing software stacks. Results may require confidence thresholds, editorial policies and human supervision. A broadcast system cannot allow these variables to compromise the real-time media path. This is why the MXL boundary is strategically important: it allows AI to be connected to the workflow without forcing the AI service to become the timing authority of the system.

A real-time compliance workflow illustrates the model. The broadcast platform receives and synchronizes an ST 2110 input. MXL exposes the relevant video grains and metadata to a containerized AI service. The AI service detects objects, logos or sensitive visual elements and returns confidence values, coordinates or segmentation masks. A controlled rendering stage applies masking, blurring or replacement. The processed output then returns to the broadcast platform, where fallback or bypass remains available if the AI module fails or exceeds its operating envelope.

This architecture does not remove the need for editorial policy, AI validation or operator supervision. On the contrary, it makes those requirements easier to enforce because the AI service is connected through a defined boundary. The AI component becomes a service within a controlled workflow, not an uncontrolled dependency inside the core media path.

Figure 4 – Example of an AI-assisted compliance workflow using MXL as a controlled exchange boundary.

The road ahead

The first measurements are promising, but they are only the beginning. The complete latency of an AI-enabled broadcast workflow depends on much more than media exchange alone. Format conversion, inference cadence, GPU occupancy, rendering strategy, buffering, fallback policy and operational supervision all contribute to the final result.

The next engineering steps are therefore to measure the additional contributors in a complete AI-enabled workflow. YCbCr 10-bit 4:2:2 to RGB or tensor conversion must be quantified. Containerized inference must be evaluated with selected models. GPU blur and mask rendering must be validated in UHD and HDR. Long-duration runs must be used to characterize stability, tail latency and rare events. Multi-flow stress tests must determine how the architecture scales on a multi-channel appliance.

Still, the MXL passthrough results establish an important foundation. A containerized media function can exchange UHD v210 50p payloads through MXL with low latency and without measurable Docker penalty when the architecture is correctly designed. This does not mean that every software function will automatically meet broadcast constraints. It means that the exchange layer itself can be compatible with those constraints.

For BBright, this confirms the relevance of an MXL-ready appliance model: a broadcast-grade host managing deterministic ST 2110 ingest and egress, combined with a controlled software extension zone where media functions can be deployed as standard containers. This is a practical path toward more open, modular and intelligent broadcast infrastructures.

MXL will not remove the engineering discipline required by live media systems. But it can provide the boundary that makes software innovation compatible with broadcast reliability. That is the strategic direction: interoperability where the ecosystem needs openness, and core stability where the broadcast operation needs trust.

Summary

MXL can help BBright articulate a differentiated architecture: open enough to connect software and AI services, disciplined enough to preserve deterministic media behavior, and operational enough to support real broadcast deployments.