Kurz gesagt: Eine Remote Production Hybrid Cloud verteilt die Aufgaben der Medienproduktion: Latenzkritische Live-Signale werden in einem Rechenzentrum in Metro-Nähe verarbeitet, skalierbare und weniger zeitkritische Aufgaben laufen in der Public Cloud. Die Architektur richtet sich an Broadcaster, Produktionsdienstleister und Streaming-Anbieter, die Live-Inhalte über mehrere Standorte hinweg produzieren. Die Version 2 der Referenzarchitektur „Dynamic Media Facility“ der European Broadcasting Union (EBU) vom April 2026 beschreibt Medienfunktionen in Containern, die im eigenen Haus, an einem entfernten Standort oder in der Public Cloud laufen können. Der Grund für den Metro-Hub ist technisch: Unkomprimierte SMPTE-ST-2110-Signale und eine Zeitsynchronisation per Precision Time Protocol (PTP) brauchen verwaltete, latenzarme Netze. Public-Cloud-Mediendienste übernehmen Videosignale in der Regel nur komprimiert.
Von Lars Sommerfeldt, Geschäftsführer der NMMN GmbH · Stand: November 2026
Remote Production Hybrid Cloud: Warum All-Cloud für Live-Produktion an Grenzen stößt
Eine hybride Remote Production bringt jede Produktionsfunktion an den Ort, der zu ihren Anforderungen an Latenz, Bandbreite und Kosten passt. Ob eine Funktion in die Cloud gehört, wird so zu einer Architekturentscheidung und hängt nicht mehr von einer Grundsatzfrage ab.
Auf der IBC 2026 vom 11. bis 14. September in der RAI Amsterdam war softwaredefinierte Produktion wieder eines der Hauptthemen. Den fachlichen Rahmen dafür setzt die EBU mit Version 2 ihrer Dynamic Media Facility Reference Architecture vom April 2026. Darin laufen Medienfunktionen als containerisierte Microservices im eigenen Haus, an einem entfernten Standort oder in der Public Cloud. Verbunden sind sie über einen gemeinsamen Media eXchange Layer. Für die Praxis bedeutet das: Das Modell legt bewusst nicht fest, wo eine Funktion laufen muss. Vier Gründe sprechen dafür, latenzkritische Teile in Metro-Nähe zu betreiben:
- Laufzeit: Rückkanäle wie Talkback, Tally und Kamerasteuerung reagieren empfindlich auf jede zusätzliche Verzögerung.
- Bandbreite: Unkomprimierte Videosignale brauchen pro HD-Signal mehrere Gbit/s.
- Timing: Die Synchronisation per PTP setzt ein kontrolliertes Netz voraus.
- Kosten: Datenabfluss aus der Cloud und dauerhaft belegte Rechenleistung lassen sich bei 24/7-Kanälen schwer planen.
Latenz in der Medienproduktion: Physik, Codec und Puffer
Die Gesamtlatenz setzt sich aus Signallaufzeit, Codierung und Fehlerkorrektur-Puffer zusammen. In Metro-Nähe fällt die Signallaufzeit kaum ins Gewicht.
Licht braucht in der Glasfaser rund 5 Mikrosekunden pro Kilometer. Auf einer Metro-Strecke von 50 Kilometern sind das etwa 0,25 Millisekunden in eine Richtung. Mehr Verzögerung entsteht meist durch Codecs und Puffer. Ein Beispiel ist SRT (Secure Reliable Transport), das Haivision 2017 als Open Source veröffentlicht hat. Das Protokoll gleicht Paketverluste im Internet durch erneutes Senden aus und arbeitet dafür mit einem konfigurierbaren Latenzpuffer. Je unzuverlässiger die Strecke ist, desto größer muss dieser Puffer sein. SRT eignet sich sehr gut für die Zuführung aus dem Feld. Für die Signale innerhalb einer Regie ist das Protokoll nicht gedacht.
SMPTE ST 2110 über Glasfaser: Was zwischen Standorten realistisch ist
SMPTE ST 2110 ist für verwaltete IP-Netze definiert. Zwischen Standorten funktioniert der Standard daher am zuverlässigsten über eigene Glasfaserstrecken oder dedizierte Wellenlängen und nicht über das öffentliche Internet.
Die Normenreihe trennt Video, Audio und Zusatzdaten in einzelne Ströme. ST 2110-10 regelt die Synchronisation per PTP, ST 2110-20 unkomprimiertes Video, ST 2110-22 komprimiertes Video mit konstanter Bitrate und ST 2110-30 Audio. Für komprimierte Strecken hat sich JPEG XS nach der VSF-Empfehlung TR-08 durchgesetzt. Deren Fassung von 2026 ergänzt unter anderem Temporal Differential Coding.
Wo die Grenze zur Cloud liegt, zeigt die Dokumentation von AWS Elemental MediaConnect. Der Dienst transportiert ST 2110-22 mit JPEG XS, unterstützt unkomprimiertes ST 2110-20 aber nicht. Für die Zuführung empfiehlt AWS eine private Direktverbindung. Die Grenze zur Cloud ist damit auch die Grenze, ab der komprimiert werden muss. Alles, was unkomprimiert bleiben soll, gehört in den Metro-Hub.
Architekturmuster Remote Production im Vergleich
In der Praxis haben sich vier Muster bewährt, die sich danach unterscheiden, wo das Bildmischpult und die Signalverarbeitung liegen.
| Muster | Was läuft wo | Transport | Geeignet für | Grenzen |
|---|---|---|---|---|
| All-Cloud | Encoder am Spielort, Produktion und Ausspielung in der Cloud | SRT über das Internet | Pop-up-Kanäle, Streams, kleinere Events | Puffer-Latenz, Jitter, schwer planbare Abflusskosten |
| Metro-Hub mit Cloud-Burst | Produktionskern in einer Colocation, Encoding, Distribution und Archiv in der Cloud | ST 2110 über Glasfaser, JPEG XS oder Mezzanine-Formate über eine Direktverbindung zur Cloud | Regelbetrieb, Sport, Nachrichten | Hardware im Hub muss betrieben und gewartet werden |
| Edge-Venue plus Metro-Hub | Kleine Edge-Einheit am Spielort, Regie im Rechenzentrum | JPEG XS über Standleitung, SRT als Backup | Wiederkehrende Spielorte wie Arenen und Studios | Leitungsbau am Spielort nötig |
| Cloud-native mit Metro-Ingest | Signale werden in der Metro gebündelt und komprimiert, die Produktion läuft in der Cloud | JPEG XS beziehungsweise ST 2110-22 über eine private Cloud-Anbindung | Skalierende Mehrkanal-Produktionen | Kein unkomprimierter Workflow in der Cloud |
Public Cloud Connect für Broadcaster: die Übergabe planbar machen
Mit einer privaten Direktanbindung an die Public Cloud werden Bandbreite, Latenz und Ausfallsicherheit an der Übergabe zur Cloud planbar.
Statt Mediensignale über das Internet in die Cloud zu senden, wird die Verbindung zur Cloud im Rechenzentrum oder an einem Internetknoten wie DE-CIX übergeben. Das senkt den Jitter und erlaubt redundante Wege. Außerdem bleiben die Schnittstellen nachvollziehbar, über die Daten die Cloud verlassen. Planen Sie die Übergabe immer doppelt: zwei physisch getrennte Wege und zwei Übergabepunkte.
Colocation für Medienproduktion: Anforderungen an den Metro-Hub
Ein Metro-Hub für Medienproduktion braucht genug Strom und Kühlung für dicht bestückte Racks, kurze Wege zur Glasfaser und eine stabile Zeitreferenz.
- High-Density-Racks für Media-Server, GPU-Systeme und Switches mit Unterstützung für ST 2110
- Zeitreferenz: Klären Sie mit dem Anbieter, ob eine GNSS-Antenne für den PTP-Grandmaster montiert werden kann.
- Redundante Wegeführung zum Spielort, zum Studio und zur Cloud-Übergabe
- Storage für Proxys und Archiv, zum Beispiel S3-kompatibler Object Storage auf Ceph-Basis
- Virtualisierung mit Augenmaß: Echtzeitfunktionen mit ST 2110 laufen häufig auf Bare Metal mit spezialisierten Netzwerkkarten. Orchestrierung, Monitoring und Media-Asset-Management lassen sich dagegen gut auf Plattformen wie Proxmox betreiben.
In sechs Schritten zur hybriden Produktionsarchitektur
- Ordnen Sie jede Produktionsfunktion nach ihrem Latenzbudget: Rückkanal, Live-Bild, Nachbearbeitung.
- Legen Sie die Grenze für die Komprimierung fest: Was bleibt unkomprimiert, was wird mit JPEG XS übertragen, was mit SRT?
- Wählen Sie den Standort für den Metro-Hub nach Glasfaserwegen zu Spielorten und Studios.
- Planen Sie die Übergabe zur Cloud als private, redundante Direktanbindung.
- Gestalten Sie die PTP-Architektur mit Grandmaster und Boundary Clocks über alle Standorte hinweg.
- Testen Sie Ausfälle, also den Wechsel von Leitung, Übergabepunkt und Cloud-Region, bevor Sie live gehen.
Wie NMMN hybride Produktionsarchitekturen unterstützt
NMMN betreibt seit 1999 eigene Rechenzentren und ein eigenes Glasfasernetz, das NMMN City-Netz in Hamburg. Mit Glasfaser Hamburg lassen sich Standorte, Studios und Rechenzentren direkt verbinden. Im City-Netz bietet NMMN redundante, physisch getrennte Glasfaserwege für Standortverbindungen an. Außerdem sind im Hamburger City-Netz Dark Fibre und WDM-Wellenlängen erhältlich, also die eigenen Glasfaserstrecken und dedizierten Wellenlängen, die ST 2110 zwischen Standorten braucht. Für den Metro-Hub bietet NMMN Colocation Hamburg und weitere Colocation-Standorte an, darunter Ahrensburg (Tier 3+), Norderstedt, Berlin-Moabit, Düsseldorf, Leverkusen und Stuttgart. Ob eine GNSS-Antenne für den PTP-Grandmaster montiert werden kann, prüft NMMN im Einzelfall je nach Standort. Die Übergabe zur Cloud deckt Public Cloud Connect ab. NMMN ist DE-CIX DirectCloud Partner. Über Public Cloud Connect sind alle Cloud-Anbieter erreichbar, die über DE-CIX DirectCloud angebunden sind. Für Funktionen ohne Echtzeitanforderung eignen sich die Private Cloud Proxmox und S3 Object Storage. NMMN ist nach ISO 27001 und ISO 14001 zertifiziert. Warum Datenhoheit dabei eine Rolle spielt, erklärt der Ratgeber zur souveränen Cloud. Für Ihre Architekturfragen erreichen Sie das Team über den Kontakt.
Häufige Fragen
Was ist eine hybride Remote Production?
Bei einer hybriden Remote Production laufen latenzkritische Live-Funktionen in einem Rechenzentrum in Stadtnähe, skalierbare Aufgaben wie Encoding, Distribution und Archiv dagegen in der Public Cloud. Beide Bereiche sind über Glasfaser und eine private Cloud-Anbindung verbunden.
Kann man SMPTE ST 2110 unkomprimiert in die Public Cloud übertragen?
In der Regel nicht. AWS Elemental MediaConnect unterstützt zum Beispiel ST 2110-22 mit JPEG XS, unkomprimiertes ST 2110-20 aber nicht. Unkomprimierte Workflows bleiben deshalb meist im eigenen oder angemieteten Rechenzentrum.
Wie viel Latenz entsteht durch die Glasfaser in einer Stadt?
Licht braucht in der Glasfaser rund 5 Mikrosekunden pro Kilometer, auf 50 Kilometern also etwa 0,25 Millisekunden in eine Richtung. Codecs und Puffer verursachen meist deutlich mehr Verzögerung als die Strecke selbst.
Wann ist SRT die richtige Wahl für Remote Production?
SRT eignet sich für die Zuführung über das Internet oder als Backup-Strecke, weil das Protokoll Paketverluste durch erneutes Senden ausgleicht und Verschlüsselung unterstützt. Dafür braucht SRT einen Latenzpuffer und ist deshalb weniger für Rückkanäle innerhalb einer Regie geeignet.
Was beschreibt die EBU Dynamic Media Facility?
Die Dynamic Media Facility ist eine Referenzarchitektur der European Broadcasting Union für softwaredefinierte Medienproduktion. Version 2 erschien im April 2026 und beschreibt containerisierte Medienfunktionen, die im eigenen Haus, an einem entfernten Standort oder in der Public Cloud laufen können.
Welche Anforderungen hat ein Rechenzentrum für Broadcast-Workloads?
Wichtig sind High-Density-Racks, redundante Glasfaserwege, eine private Anbindung an die Public Cloud und eine Möglichkeit für eine präzise Zeitreferenz, etwa per GNSS-Antenne für PTP. Klären Sie diese Punkte vor Vertragsabschluss mit dem Colocation-Anbieter.
Quellen und weiterführende Links
- RAI Amsterdam – IBC 2026 (Veranstaltungskalender)
- EBU – The Dynamic Media Facility: Reference Architecture
- EBU – Version 2 of the Dynamic Media Facility Reference Architecture
- SMPTE – ST 2110 Standard Overview
- SMPTE OV 2110-0:2018 – Overview Document
- VSF TR-08:2026 – Transport of JPEG XS Video in ST 2110-22
- AWS Elemental MediaConnect – Media streams
- AWS Elemental MediaConnect – Use case: contribution for CDI flows
- Haivision – SRT: Everything You Need to Know
Über den Herausgeber: Die NMMN GmbH, Haferweg 46, 22769 Hamburg, betreibt seit 1999 eigene Rechenzentren und ein Glasfasernetz in Hamburg, ist offizieller Proxmox Silver Partner und Mitgründer der Hamburg-Cloud. Kontakt aufnehmen