What Is MXL? From SDI and ST 2110 to Software-Based Broadcast

Summary

• SDI: the deterministic physical signal world for carrying baseband video/audio between devices
• ST 2110: a standards suite for carrying separate video, audio, and ancillary essence flows over an IP fabric
• MXL: a high-performance media exchange layer between software media functions inside the EBU Dynamic Media Facility (DMF)
• Core idea: MXL does not replace ST 2110; it aims to share media more directly inside compute clusters after ST 2110 has brought media to the facility or edge
• Why it matters: entering and leaving stream formats such as ST 2110 or NDI at every processing step creates packetization, serialization, buffering, and sync overhead
• Practical model: ST 2110 for ingest/output, MXL for exchange between graphics, AI, mixer, encoder, and other software functions

Note: This article follows naturally from ST 2110 television campus, NMOS control plane, ST 2110 monitoring, and the FFmpeg/GStreamer decision guide. The goal is to position MXL not as a codec or a new video format, but as a media exchange layer for software-defined production.

1. The Problem: We moved from SDI to IP, but what happens inside software?

The big broadcast infrastructure transition is often simplified like this:

1. SDI era: physical cables, baseband video, deterministic device-to-device behavior.
2. ST 2110 era: the same live media essences move as separate flows across an IP network.
3. Software-defined production era: media no longer moves only device-to-device; it also moves between many software functions inside a compute cluster.

ST 2110 solves the second step very well: carrying video, audio, and data over a managed IP network. But modern production chains are not made only of physical devices. One video signal may pass through these functions in the same server cluster:

• ingest
• frame sync
• graphics
• vision mixing
• AI/ML analysis
• audio processing
• caption/subtitle insertion
• encoding
• monitoring

If every step converts media back into a stream, packetizes it, buffers it, and reconstructs it again, latency and compute cost grow. This is exactly where MXL enters the story.

2. SDI, ST 2110, and MXL are not the same thing

It is useful to think about these three concepts together, but they do not live at the same layer.

In one sentence:

• SDI was the language of the cable world.
• ST 2110 became the language of the IP media fabric.
• MXL tries to standardize the media exchange language inside software production clusters.

3. What does ST 2110 solve?

SMPTE ST 2110 is a standards suite for transporting professional media over managed IP networks. The key idea is to split the video/audio/ANC structure that traveled together in SDI into separate essence flows in IP:

• ST 2110-20: uncompressed active video
• ST 2110-30: PCM digital audio
• ST 2110-40: ancillary data
• ST 2110-10: system timing model, RTP timestamps, and PTP relationship

This model is powerful in broadcast facilities:

• sources and destinations connect across an IP fabric instead of a physical router
• audio/video/data can be routed independently
• multicast allows one source to feed many destinations
• control planes such as NMOS can manage discovery and connections

But ST 2110 was not mainly designed for one software process to share frames with another software process through the same memory space. ST 2110 is a network transport approach.

4. What does MXL solve?

MXL means Media eXchange Layer. It is one of the core components in the EBU Dynamic Media Facility (DMF) reference architecture. Its goal is to let media processing functions exchange media in a vendor-neutral, high-performance way.

It is better to think of MXL this way:

• it is not a codec
• it is not a container
• it is not an ST 2110 replacement
• it is not an internet streaming protocol
• it is an exchange layer approach for cloud-native/software production

MXL focuses on this question:

How can different vendor applications in the same compute environment share video frames, audio chunks, and timed metadata with low overhead?

The key point in this diagram: after media enters the cluster, every function may not need to receive and generate ST 2110 streams again. MXL aims to standardize the exchange inside the cluster.

5. Why not just continue with ST 2110 everywhere?

ST 2110 can be an excellent facility/network standard, but using ST 2110 between every software function inside a cluster is not always efficient.

5.1 The cost of a streaming approach

In ST 2110 or similar streaming approaches, media is:

1. prepared as frames or audio blocks
2. split into RTP packets
3. sent through the network stack
4. buffered on the receiving side
5. reconstructed with timestamps and sync
6. handed to application memory

This makes sense between devices and network endpoints. But if it happens again and again between several software functions on the same server or compute cluster, the cost grows.

5.2 Software production needs more fan-out

In live production, the same media can be consumed by many functions at the same time:

• program output encoder
• clean feed encoder
• graphics compositor
• compliance recorder
• AI highlight detector
• multiview generator
• waveform/vector scope

If each function uses separate stream input/output, this fan-out model increases latency and resource usage.

So the story is not “ST 2110 is bad, MXL is good.” The right story is:

ST 2110 is strong for the network edge and facility fabric; MXL is designed for more efficient exchange between software media functions.

6. Where MXL fits inside DMF

The EBU Dynamic Media Facility approach aims to make broadcast infrastructure more modular, software-first, and vendor-neutral. DMF should be read as a reference architecture, not as a single product.

A simplified layer model looks like this:

In this model:

• ST 2110 talks to the outside world and the real-time media fabric
• MXL provides media exchange between software functions
• orchestration decides which functions work on which media objects
• observability, timing, and security matter across every layer

7. Thinking about SDI, ST 2110, and MXL together

Real facilities are not built on one technology only. They remain hybrid for a long time.

Example end-to-end chain:

1
2
3
4
5
6
7

SDI Camera
  -> SDI/ST 2110 Gateway
  -> ST 2110 IP Fabric
  -> Ingest Function
  -> MXL inside processing cluster
  -> Graphics + AI + Mixer + Encoder
  -> ST 2110 back to facility / SRT to cloud / HLS to OTT

In this chain, MXL does not sit between SDI and ST 2110 like a physical converter. It is more like the layer that lets ST 2110-delivered media be processed in software without repeatedly becoming a stream again.

8. What questions does MXL raise?

MXL points in an important new direction, but these questions must be part of any production design:

• Timing model: how does PTP time from the ST 2110 side map to MXL media object timing?
• Metadata: how are frame metadata, audio metadata, ANC, and application metadata related?
• Memory ownership: who creates, reads, and modifies a buffer?
• Fan-out: how many functions can consume the same media object at once?
• Security: which applications inside the cluster can access which media?
• Observability: how are frame drops, latency, queue depth, and function health measured?
• Vendor interoperability: how do different vendor functions behave on the same MXL exchange?
• Fallback: how do non-MXL functions connect through ST 2110, NDI, SRT, or file-based intermediates?

These questions do not weaken MXL; they show why the topic matters. When moving from SDI to ST 2110, PTP, multicast, and NMOS became critical. When moving to software-based production, exchange models, memory, metadata, and orchestration become critical.

9. Where to use it, and where not to

It is important not to misplace MXL:

• You do not replace an ST 2110 router with MXL.
• You do not replace an SDI gateway with MXL.
• You do not use MXL for internet streaming.
• You think of MXL as the exchange layer between software media functions.

10. Conclusion

SDI, ST 2110, and MXL are different stages of the same transition story:

• SDI carried broadcast signals reliably over cables.
• ST 2110 moved those signals onto a managed IP fabric.
• MXL aims to make media sharing inside software-defined production more efficient and vendor-neutral.

So MXL should not be read as “an alternative to ST 2110.” It is better understood as a layer that fills the software production gap after ST 2110.

Short version:

ST 2110 brings media into the IP fabric. MXL aims to let that media move between software functions without becoming a stream again and again.

The next architecture debate in broadcast will probably not be only “SDI or IP?” It will be:

How does media enter the facility, how is it processed inside software, and how does it leave again?

MXL is one of the most current candidate answers to that second question.

References

• EBU MXL
• EBU: Ready for production: Media eXchange Layer v1.0.0 published
• EBU: open-source MXL SDK for software-based Media Exchange
• EBU: Dynamic Media Facility Reference Architecture v2
• SMPTE: ST 2110 Suite of Standards
• Related posts: ST 2110 campus, NMOS, ST 2110 monitoring, FFmpeg/GStreamer