Media eXchange Layer (MXL) erklärt: Die virtuelle Verkabelung der Software-Produktion
Der Media eXchange Layer (MXL) ist mit Version 1. 0. 0 produktionsreif: Was der offene EBU-Standard für softwarebasierte Produktion leistet – und warum er ST 2110 ergänzt statt ersetzt.
Der Media eXchange Layer (MXL) ist seit Anfang 2026 produktionsreif: Mit der Veröffentlichung von Version 1. 0. 0 hat das Projekt den Schritt vom Konzept zum einsetzbaren Code vollzogen. Für die Branche beantwortet MXL – nicht zu verwechseln mit dem Datenformat XML – eine Frage, die mit jeder softwarebasierten Produktionsumgebung drängender wird: Wie tauschen Softwarefunktionen verschiedener Hersteller auf derselben Infrastruktur Medien aus, ohne dass jeder Übergang eine Konvertierung, eine proprietäre Schnittstelle oder eine Herstellerabhängigkeit kostet? Dass die Antwort darauf als Open-Source-Projekt entsteht und nicht als Produkt eines einzelnen Anbieters, ist die eigentliche Nachricht. Vier Funktionen, zwei Welten: Ohne MXL braucht jede Herstellerkombination eine eigene Schnittstelle – mit MXL teilen sich alle Funktionen denselben Speicher. MXL ist ein quelloffenes Software Development Kit für den Austausch von Video, Audio und Metadaten zwischen Medienverarbeitungsfunktionen, die in virtualisierten Umgebungen laufen – in Containern auf eigenen Servern ebenso wie in der Cloud. Der technische Kern: Die beteiligten Funktionen teilen sich den Arbeitsspeicher. Statt Medien zwischen Prozessen zu kopieren oder über Netzwerk-Stacks zu schicken, greifen Mischer-, Grafik- oder Audiofunktion auf dieselben Speicherbereiche zu – sogenannte Zero-Copy-Workflows. Das SDK legt fest, wie Video-, Audio- und Datenpayloads im Shared Memory repräsentiert werden und wie ihr Timing definiert ist. Ebenso wichtig ist, was MXL nicht ist: kein Netzwerkprotokoll, kein Transportstandard, kein Streamingformat. Wer Signale zwischen Standorten oder Geräten bewegen will, braucht weiterhin andere Werkzeuge. MXL adressiert die Ebene darunter – den Moment, in dem mehrere Softwarefunktionen auf demselben System zusammenarbeiten sollen. Genau diese Ebene war bislang das ungelöste Problem der Software-Produktion: Innerhalb der Plattform eines Herstellers funktionierte der Austausch, über Herstellergrenzen hinweg endete er an proprietären Schnittstellen. AnzeigeDMF: Die Referenzarchitektur der EBU hinter MXLDie European Broadcasting Union ist Ideengeber der DMF und dementsprechend auch von MXL ©EBUMXL ist die Schlüsselkomponente derDynamic Media Facility (DMF), einer Referenzarchitektur der European Broadcasting Union. Die DMF beschreibt eine Produktionswelt, in der Medienverarbeitung nicht mehr in dedizierten Hardware-Boxen stattfindet, sondern in virtuellen Containern – skalierbar auf eigener Infrastruktur oder auf gemieteten Rechenressourcen, je nach Bedarf der Produktion. In diesem Bild ist MXL die virtualisierte Verkabelung: die Schicht, die in der Hardware-Welt aus SDI-Kabeln, Steckfeldern und Kreuzschienen bestand und die in der Software-Welt bislang schlicht fehlte, sobald mehr als ein Hersteller beteiligt war. Die Konsequenz dieses Ansatzes reicht weiter, als der technische Begriff vermuten lässt. Wenn die Austauschschicht offen und herstellerneutral ist, konkurrieren Anbieter nicht mehr über das Ökosystem, sondern über die Qualität der einzelnen Funktion – ein Strukturwandel, den die Branche von der ST-2110-Migration kennt, nur eine Abstraktionsebene höher. Wer hinter dem MXL-Projekt stehtGetragen wird das MXL-Projekt von der EBU gemeinsam mit der nordamerikanischen Rundfunkvereinigung NABA, die Governance liegt bei der Linux Foundation – ein bewusst gewähltes Modell, das die Weiterentwicklung von Einzelinteressen entkoppelt. Auf Anwenderseite beteiligen sich unter anderem BBC, CBC/Radio-Canada, France Télévisions, Olympic Broadcasting Services, SVT, VRT sowie aus dem deutschsprachigen Raum SWR/ARD und die SRG SSR. Auf Herstellerseite stehen unter anderem AWS, Grass Valley, Intel, Lawo, NVIDIA, Riedel und Telos Alliance hinter dem Projekt – eine Liste, die quer durch sonst konkurrierende Lager reicht. Das Projekt verfolgt einen Implement-first-Ansatz: Statt jahrelang Spezifikationen zu verhandeln, entsteht der Standard durch Implementierung. DasSDK liegt öffentlich auf GitHub, inklusive Beispielen für Docker und Kubernetes – wer evaluieren will, kann heute anfangen, ohne Mitgliedschaft und ohne Lizenzverhandlung. Für eine Branche, die ihre Standards traditionell in Gremien reift, ist dieses Tempo selbst Teil der Botschaft. Vom Konzept zum Code in 15 MonatenDie Geschwindigkeit des Projekts ist bemerkenswert. Zur NAB 2025 kündigte die Linux Foundation die Gründung des MXL-Projekts an, Grass Valley zeigte dort bereits eine lauffähige Implementierung. Im Juni 2025 folgte die erste Alpha-Version des SDK, Anfang 2026 der Release Candidate, im März 2026 das stabile Release 1. 0. 0. Vom Start bis zur produktionsreifen Version vergingen rund 15 Monate. Mit dem finalen Stand der Schnittstellen können Hersteller MXL-Support nun in Produkte integrieren, ohne nachträgliche Umbauten fürchten zu müssen. Zur NAB 2026 war die Technologie entsprechend präsent: Eine ganze Reihe von Herstellern demonstrierte Implementierungen auf Basis von Version 1. 0. 0, und mitTAG Video Systems erklärte zuletzt ein weiterer Monitoring-Spezialist seinen Beitritt zur MXL-Interoperabilitätsinitiative. MXL neben ST 2110, NDI und TAMS: Ergänzung, nicht ErsatzDie häufigste Verwechslung zuerst: MXL ersetzt SMPTE ST 2110 nicht. ST 2110 definiert, wie unkomprimierte Medienströme über IP-Netzwerke zwischen Geräten und Standorten transportiert werden – Essenz auf dem Kabel beziehungsweise im Netz. MXL definiert, wie Softwarefunktionen auf demselben System Medien im Arbeitsspeicher teilen – Essenz innerhalb der Maschine. In einer realen Produktionsumgebung werden beide koexistieren: ST 2110 bringt die Signale ins Rechenzentrum, MXL verteilt sie dort zwischen den Verarbeitungsfunktionen. Ähnliches gilt für NDI, das als netzwerkbasiertes Protokoll mit eigener Kompression eine andere Ebene bedient. (siehe auchSMPTE 2110 vs NDI: Vergleich zweier IP-Video-Protokolle)Auch zumTime Addressable Media Store (TAMS)lohnt die Abgrenzung, weil beide Projekte aus demselben Umfeld softwarebasierter Produktion stammen und die BBC an beiden maßgeblich beteiligt ist. TAMS beantwortet die Speicherfrage: Medien liegen zeitadressiert in einem Store und sind über eine offene API segmentgenau abrufbar – etwa für Schnitt während der Aufzeichnung. MXL beantwortet die Echtzeitfrage: der Austausch zwischen laufenden Funktionen im Moment der Produktion. Vereinfacht arbeitet TAMS mit dem Gespeicherten, MXL mit dem Jetzt – zwei Schichten derselben Architekturidee, die sich eher ergänzen als überschneiden. Die spannendste Grenze liegt allerdings in MXL selbst: Bislang ist der Austausch auf Funktionen innerhalb eines Hosts ausgelegt. Als nächster großer Punkt steht Interhost-Kommunikation auf der Roadmap – der Medienaustausch über verteilte Systeme hinweg. Spätestens dann wird sich zeigen, wie sich MXL und die etablierten Transportstandards zueinander verhalten, wenn die Grenze der einzelnen Maschine fällt. Vom Demo-Status zur KaufentscheidungFür Entscheider bei Broadcastern und Dienstleistern ist MXL 2026 noch kein Beschaffungskriterium, aber bereits ein Ausschreibungsthema. Wer jetzt in softwarebasierte Produktionsinfrastruktur investiert, sollte Hersteller nach ihrer MXL-Roadmap fragen – die Antwort verrät viel darüber, ob ein Anbieter auf offene Interoperabilität oder auf Ökosystem-Bindung setzt. Zur IBC 2026 dürfte sich abzeichnen, wie schnell aus den Demonstrationen der NAB kaufbare Produkte werden. Die Beteiligtenliste spricht dafür, dass es diesmal schneller geht als bei früheren Interoperabilitätsanläufen der Branche – am offenen Code lässt sich schwerer vorbeientwickeln als an einem Papierstandard.