Die Broadcast-Branche sucht aktiv nach Lösungen für eine zentrale Herausforderung in der softwaredefinierten Produktion: die Optimierung des Transfers von Video, Audio und Metadaten zwischen verschiedenen Anwendungen. Ziel ist es, Engpässe zu beseitigen, die Latenz zu minimieren und Herstellerbeschränkungen zu überwinden, die diese Prozesse traditionell behindert haben. Der Media Exchange Layer, besser bekannt als MXL, ist eine Brancheninitiative, die dieses Problem direkt angeht und den Zugriff auf gemeinsam genutzten Speicher anstelle herkömmlicher Streaming-Protokolle nutzt.
Das Projekt wurde im April 2025 von der Linux Foundation in Partnerschaft mit der European Broadcasting Union (EBU) und der North American Broadcasters Association (NABA) ins Leben gerufen und hat die Unterstützung von namhaften Sendern wie BBC, CBC/Radio-Canada, France TV und SVT erhalten. Auch Technologieanbieter wie AWS, NVIDIA, Grass Valley, Intel und Lawo beteiligen sich.
„Das Versprechen von MXL ist, dass Benutzer die Herstellerbindung an generische Server vermeiden können, auf denen Verarbeitungsanwendungen verschiedener Hersteller nicht nur nebeneinander laufen, sondern auch Daten über eine sogenannte Shared-Memory-Schicht austauschen, um Latenzprobleme zu vermeiden", sagte Chris Scheck, Leiter Marketing Content bei Lawo.
Miroslav Jeras, CTO bei Pebble, fügte hinzu: „Es gab eine Bremse bei der Einführung breiterer Softwareinfrastrukturen und der Einführung der Cloud: das Fehlen von offenen Standards für Interoperabilität. Initiativen wie MXL sollten Systemarchitekten in die Lage versetzen, Multi-Vendor-Plattformen in virtualisierten Umgebungen zu bauen, ohne dass eine massgeschneiderte Integrationsarbeit erforderlich ist."
MXL ermöglicht es Anwendungen, die auf demselben Server oder einer verbundenen Infrastruktur laufen, Video-Frames, Audio-Samples und Timing-Daten direkt im Speicher gemeinsam zu nutzen. Dies steht im Gegensatz zu bestehenden Methoden wie SMPTE ST 2110 oder NDI, bei denen Medien paketiert, über ein Netzwerk übertragen und am Zielort rekonstruiert werden. Der Hauptvorteil liegt in der Ressourceneffizienz. Traditionelle Streaming-Protokolle benötigen erhebliche CPU-Ressourcen für die Paketierung und Pufferung, was zu Latenzzeiten in jeder Verarbeitungsstufe führt. Frühe MXL-Implementierungen haben Latenzzeiten von weniger als einer Millisekunde pro Übertragung gezeigt, verglichen mit etwa 20 Millisekunden pro Gerät mit ST 2110.
Die Initiative entstand aus praktischen Bedürfnissen, die von Sendern bei der Planung neuer Einrichtungen und Workflows festgestellt wurden. CBC begann beispielsweise mit der Entwicklung des Konzepts während der Planung seines Hauptsitzes in Toronto, mit dem Ziel einer Infrastruktur, die sich an unterschiedliche Produktionsanforderungen ohne Hardwarebeschränkungen anpassen kann.
François Legrand, Senior Director Engineering, CBC/Radio-Canada, erklärte in der MXL-Ankündigung: „Softwaregesteuerte Broadcast-Produktion ist die Zukunft, und der Echtzeit-Medienaustausch ist ein entscheidender Teil dieser Entwicklung. Das MXL-Projekt ist ein entscheidender Schritt hin zu einem offenen, interoperablen Ökosystem, das es Sendern ermöglicht, die Effizienz zu maximieren und gleichzeitig die Komplexität der Infrastruktur zu reduzieren. Wir erwarten, dass der Start mit Software anstelle des Schreibens eines Dokuments den Prozess der Entwicklung der Lösung erheblich beschleunigen wird."
Die BBC stand vor ähnlichen Herausforderungen, da die Ressourcen auf mehrere Standorte in Grossbritannien verteilt waren. Jatin Aythora, Direktor, BBC Research & Development, merkte an: „Da Sender ihre Live-Produktion und ihren Medienbetrieb auf softwarebasierte Infrastrukturen verlagern, die von Cloud-Architekturen inspiriert sind, werden die Konzepte der Dynamic Media Facility-Initiative der EBU die Skalierbarkeit, Flexibilität und Effizienz bieten, die zur Unterstützung zukünftiger Anforderungen erforderlich sind."
Beide Organisationen erkannten die Interoperabilität der Anbieter als eine ständige Hürde. Die meisten bestehenden Memory-Sharing-Lösungen sind proprietär, was die Flexibilität des Systemdesigns einschränkt und eine Abhängigkeit von bestimmten Technologieanbietern schafft. Das System verwendet Ringpuffer im gemeinsam genutzten Speicher, in die Anwendungen Mediendaten schreiben und aus denen sie lesen. Die MXL-Bibliothek bietet APIs, die eine Zero-Overhead-Freigabe über ein Reader/Writer-Modell anstelle einer Sender/Empfänger-Architektur ermöglichen. Dadurch entfällt die Notwendigkeit der Paketierung oder des Kopierens von Speicher, was Bandbreite spart und die CPU-Last reduziert. Medien werden in Flows und Grains organisiert, Begriffe, die von den NMOS IS-04-Spezifikationen abgeleitet sind. Timing-Daten indizieren jedes Grain relativ zur PTP-Epoche, was entscheidend ist, wenn sich Systeme über mehrere Hosts erstrecken. Cloud-Anbieter bieten Zeitsynchronisationsdienste an, die MXL nutzen kann, um die Ausrichtung über verteilte Infrastrukturen hinweg aufrechtzuerhalten.
Die technische Implementierung nutzt auch UNIX-Dateiberechtigungen, um den Zugriff sowohl auf Domain- als auch auf Flow-Ebene zu steuern, wodurch die Sicherheit gewährleistet wird, ohne den Datenpfad zusätzlich zu belasten. Die erste Entwicklungsphase konzentriert sich auf spezifische unkomprimierte Video- und Audioformate, eine bewusste Entscheidung, um gängige Anwendungsfälle zu adressieren, während die Kerntechnologie reift. Video mit variabler Framerate und komplexe Komprimierungsformate werden derzeit nicht unterstützt. Aktuelle Implementierungen arbeiten innerhalb von Single-Host-Umgebungen, aber Technologien wie Remote Direct Memory Access (RDMA), insbesondere RoCEv2, ermöglichen den Speicheraustausch über grössere Bereiche, indem sie es Servern ermöglichen, über IP-Netzwerke auf den Speicher des jeweils anderen zuzugreifen, wobei der Kernel umgangen und CPU-Overhead vermieden wird.
Anstelle traditioneller Standardisierungsprozesse wurde für das Projekt ein Open-Source-Modell gewählt. MXL ersetzt nicht SMPTE ST 2110, das weiterhin an Netzwerkgrenzen und zwischen Einrichtungen verwendet wird. Diese Aufteilung der Rollen platziert ST 2110 an der Peripherie für Ingest und Output, während MXL den internen Medienaustausch innerhalb von Compute-Clustern übernimmt, sodass Sender die Kompatibilität mit bestehender Infrastruktur aufrechterhalten und gleichzeitig die Effizienz innerhalb softwarebasierter Produktionsumgebungen verbessern können.
Im Oktober 2025 gab die EBU eine Partnerschaft mit der Advanced Media Workflow Association bekannt, um die Joint Taskforce on Dynamic Media Facilities zu gründen. Diese Gruppe wird sich mit Fragen der Steuerungsebene befassen, einschliesslich der Erkennung und Verbindung von Anwendungen sowie der Systemorchestrierung über verteilte Infrastrukturen hinweg. Das Projekt zielt auf eine produktionsreife Version 1-Release bis Anfang 2026 ab, wobei die teilnehmenden Organisationen planen, MXL innerhalb dieses Zeitrahmens in kommerzielle Produkte zu integrieren.
Durch die Reduzierung des Overhead beim Medienaustausch ermöglicht MXL, dass mehr Funktionen auf derselben Hardware ausgeführt werden können, reduziert die Latenz in mehrstufigen Workflows und eliminiert herstellerspezifische Verbindungsabhängigkeiten. Die Migration von Kernmedienfunktionen auf eine MXL-basierte Architektur bietet operative Vorteile. Da Container Fixed-Function-Hardware ersetzen, lassen sich Produktionsumgebungen einfacher über On-Premises-Server oder Cloud-Infrastruktur skalieren. Diese Soft Provisionierung ersetzt das Investitionsmodell der Hardwareerweiterung. Die herstellerunabhängige Natur des Open-Source-SDK ermöglicht es Sendern, Workflows aus internen, Anbieter- oder Open-Source-Komponenten zu erstellen. MXL gewährleistet die Interoperabilität zwischen diesen Elementen ohne umfangreiche Vortests oder kundenspezifische Integrationsarbeiten für jede Werkzeugkombination.
Memory-Layer-Messaging vereinfacht auch die Fehlersuche. Traditionelle IP-Workflows erfordern das Verfolgen von Paketen über Netzwerke, um Probleme zu lokalisieren. Mit MXL sind Diagnoseinformationen sofort auf der Speicherebene verfügbar und bieten eine klare Sicht auf den Zustand des Medienflusses. Die Architektur bereitet Sender auch auf neue Technologien wie KI-gesteuerte Medienfunktionen, Echtzeit-Analysen und Edge-basierte Verarbeitung vor, indem sie eine Grundlage für die Integration dieser Funktionen auf modulare, zusammensetzbare Weise bietet. Die Technologie ermöglicht auch asynchrone Workflows, bei denen die Verarbeitung schneller als in Echtzeit erfolgen kann, sodass Funktionen abgeschlossen und Ergebnisse sofort verfügbar gemacht werden können, wenn die Rechenkapazität die Echtzeit-Wiedergabebeschränkungen übersteigt. Dies kommt Organisationen zugute, die variable Workloads oder mehrere gleichzeitige Produktionen verwalten, da sie Ressourcen dynamisch basierend auf der Nachfrage und nicht auf festen Hardwarekonfigurationen zuweisen können.
Weiterentwicklungsbedarf besteht in Bereichen wie Audio-Grain-Sizing, der Steuerungsebene für die Anwendungserkennung und Verbindungsherstellung sowie Orchestrierungssystemen für die Verwaltung von MXL-basierten Workflows über komplexe Infrastrukturen hinweg. Das Projekt steht auch vor der praktischen Herausforderung der branchenweiten Akzeptanz. Während sich grosse Sender und Anbieter zu MXL bekannt haben, hängt der Erfolg davon ab, dass es sich in Produktionsumgebungen bewährt, bevor es zu einem Standard wird. Der unmittelbare Fokus liegt weiterhin auf der Vervollständigung des Timing-Modells und der Finalisierung der Spezifikationen der Steuerungsebene, die für das zuverlässige Funktionieren von MXL über verteilte Infrastrukturen und mehrere Anbieterimplementierungen hinweg unerlässlich sind.
MXL ist eine technische Lösung, die den ineffizienten Medienaustausch zwischen Softwareanwendungen adressiert. Die breite Akzeptanz hängt von der Leistung in Produktionsumgebungen und einer konsistenten Anbieterimplementierung ab. Der Open-Source-Ansatz und die breite Branchenbeteiligung deuten auf eine solide Grundlage für beide Ergebnisse hin.