Beschäftigt man sich mit IP-basierten Videoübertragungen, kommt man heute kaum noch um NDI, SRT & Co. herum. Was steckt dahinter, welches Protokoll gehört in welches Netzwerk und was kann es dort leisten?
Gegenwehr ist zwecklos: IP-basierte Videoübertragung wird der neue Standard für eine Vielzahl von Anwendungen. Auch wenn Konferenzen, Konzerte & Co. wieder als Präsenzveranstaltung abgehalten werden (können), wird der Online-Part nicht mehr gänzlich wegzudenken sein. Doch nicht nur für den Übertritt ins WAN müssen wir Streaming-Protokolle verstehen lernen: Auch für die Verteilung im LAN finden IP-Lösungen immer mehr Anklang – und das zu Recht! Welches Protokoll in welches Netzwerk gehört und welche Aufgaben es dort erfüllt, versuchen wir kompakt zusammenzufassen.
Bei einer Veranstaltung mit Konferenzschaltung, Bauchbinden per NDI, Stream-Auslieferung an YouTube und Zuschauern, die auf dem Handy zuschauen, sind bereits vier Streaming-Protokolle im Einsatz. Protokolle und deren Eigenschaften zu verstehen, hilft uns bei der Planung von Events und ermöglicht ein besseres Reagieren auf Kundenanforderungen. Zum Beispiel spielt die Latenz für Live-Wetten eine andere Rolle als für eine Produktvorführung. An manchen Stellen haben wir keinen Einfluss auf das Protokoll, andernorts stellen wir mit dem Einsatz von IP-basierten Videofeeds ganze Technikkonzepte infrage.
Wenn wir uns ein Streaming-Event mit sechs Konferenz-PCs vorstellen, zwei Kameras, einem Videozuspiel und zwei Powerpoint-PCs, kann man schon nachdenklich werden, wenn man Signallaufpläne vergleicht: Eine Softwarelösung mit NDI ist hier viel schlanker und kosteneffizienter als der konventionelle Einsatz von Bild- und Datenmischern. Für Veranstaltungen, bei denen Kamerabilder auf Projektionen oder LED-Wände im Saal übertragen werden, wird man wohl selten SDI-Signale auf NDI wandeln und NDI zurück auf HDMI. Aber auch bei diesen Events kann man sich vorstellen, an Flexibilität zu gewinnen, wenn Vorschaubildschirme und Computerzuspieler IP-basiert gemischt und geschaltet werden.
Ein IP-basierter Workflow ermöglicht auch das dezentrale Produzieren komplexer Veranstaltungen: Virtuelle Rechner schicken auf dem AWS-Cloud-Server die Bildinhalte per ST 2110 oder NDI hin und her und der Softwaremixer von Vizrt mischt das fertige Bild und setzt den Stream direkt in der Cloud aus. Die Operatoren arbeiten von Zuhause aus und lediglich das Kamerateam muss noch an den Ort des Geschehens reisen. In Deutschland sind wir durch den eher dürftigen Internetausbau noch etwas limitiert, aber derartige Produktionen finden bereits statt und werden auch in Zukunft nicht wegzudenken sein.
Das Potenzial, unsere Arbeitsabläufe gänzlich zu revolutionieren, hat aktuell nur NDI. Die Kombination mit Tally, PTZ, KVM und weiteren Signalen deckt einfach zu viel ab. Der Einstieg fällt durch die verhältnismäßig einfache Bedienung leichter als bei den Standards der SMPTE. Dabei spielt es keine große Rolle, ob und wann NDI abgelöst wird. Die Grundsteine in Sachen Netzwerktechnik müssen jetzt gelegt werden. Der Kostendruck wird nicht nachlassen und Softwarelösungen auf potenten, günstigen PCs machen unserer bewährten Hardware ernstzunehmende Konkurrenz. Nach Wochen und Monaten verpixelter Videokonferenzen haben sich Kunden zugleich an ein anderes Qualitätsniveau gewöhnt. Kompression spielt keine große Rolle, wenn am Ende der Sendekette das Zoom-Webinar steht und Zuschauer 360p-Streams auf dem Tablet schauen. Trotzdem kann es nicht schaden, eine hochwertigere Alternative für die Anbindung eines Satellitenstudios anbieten zu können und diese per SRT zu realisieren, anstatt mit Teams oder Skype.
Protokolle regeln die Art und Weise, wie Daten zwischen Kommunikationssystemen ausgetauscht werden. In der IT fügen sich Protokolle in das OSI-Modell. Das OSI-Modell beschreibt die sieben Schichten, in denen Informationen transportiert werden. Dabei sind die Schichten nicht beliebig gewählt, sondern erfüllen bestimmte Aufgaben:
Die wesentlichen Unterschiede der hier betrachteten Protokolle finden sich in den Eigenschaften der Host-Schichten 4–7.
NDI, SRT & Co.: Welches Protokoll gehört in welches Netzwerk und welche Aufgaben erfüllt es dort? Um diese eingangs gestellten Fragen zu beantworten, ordnen wir nachfolgend die verschiedenen Protokolle ein und erklären ihre Herkunft und Funktion:
1. Aus der Branche geboren: NDI, ST2022, ST2110, SRT
NDI, NDI|HX, NDI|HX2 – Network Device Interface
NDI erfreut sich seit der ersten Messevorstellung 2015 stetig wachsender Beliebtheit. Das Transportprotokoll ist kein Standard, sondern ein proprietäres Werk von NewTek. Diese Tatsache ist Fluch und Segen zugleich. Mit einer zentralisierten Entwicklung, die sich nicht durch Standardisierungsprozesse quälen muss, können in einer hohen Geschwindigkeit Features implementiert werden. Tatsächlich sind wir in den knapp fünf Jahren seit V1.0 bereits bei Version 4.6. Dafür ist der Code von NDI aber auch unter Verschluss.
NDI ist für den Videotransport in lokalen Netzwerken vorgesehen, tritt aber stellenweise bereits in den Bereich des WAN über. Neben der Übertragung von Audio und Video können ebenfalls Tally-Signale, PTZ-Steuersignale oder auch Maus- und Tastaturbefehle übertragen werden. Das Protokoll ermöglicht also eine bidirektionale Kommunikation zwischen Hard- und/oder Softwarekomponenten. Zusätzlich bietet das Protokoll Möglichkeiten für Entwickler, noch weitere Metadaten zu transportieren – so entstanden schon Implementierungen mit MIDI oder Untertiteln als Closed Captions. Die Entwicklung des Protokolls ist zwar NewTek vorbehalten, aber das SDK steht zur freien Verfügung.
NewTek hat ein großes Interesse an einer breiten Akzeptanz und Adaption von NDI. Dieses Interesse führte schnell zur Entwicklung von NDI|HX: Eine NDI-Variante mit geringerer Datenrate, höherer Latenz und H.264-Codec anstelle von NewTeks SpeedHQ. Der Vorteil ist, dass sich NDI|HX per Firmware auf vielen Geräten mit H.264-fähigen Chipsätzen nachrüsten lässt und selbst das Smartphone per App zur Kamera- oder Screensharing-Quelle werden kann. 2019 fügte NewTek mit NDI HX2 dann die dritte Variante hinzu.
NDI ist also nicht gleich NDI und wer Investitionen plant, sollte die Komponenten genau auf Kompatibilität überprüfen. Gerade NDI HX unterscheidet sich nicht nur in der Datenrate, Latenz und Kompression, sondern auch in der Art, wie Signale im Netzwerk erkannt werden. Während NDI und NDI HX2 per Bonjour (mDNS) im Netzwerk auffindbar werden, nutzt NDI HX eigene Treiber.
NDI besticht durch die verhältnismäßig einfache Bedienung und insbesondere durch die Möglichkeit, bereits in 1-Gbit-Netzwerken eine Vielzahl an Streams verfügbar machen zu können. Die breite Implementierung in Software und Hardware machen NDI zur aktuell verbreitetsten Lösung des Videotransports im LAN (für Event-Applikationen). Mit der Installation erhält man eine nützliche Auswahl an Tools zum Capture von Desktops, Monitoring, Bereitstellung von Streams als virtuelle Webcam und mehr. Es existieren sehr viele Softwarelösungen, die NDI unterstützen, z. B. vMix, Mitti, Millumin, Resolume, Wirecast, OBS, aber auch Webkonferenzlösungen wie Teams oder Skype for Content Creators bieten NDI-Schnittstellen.
In Medienservern ist NDI ebenfalls eine übliche Option zum Empfangen und Senden von Videosignalen. Hinzu kommen viele PTZ-Kameras, aber auch die ersten Minikameras oder Camcorder, die mit NDI-Schnittstellen ausgestattet sind. Ein einzelnes CAT-Kabel kann dank NDI und PoE die einzige Zuleitung zu einer Kamera sein. Strom, Video, Tally, Intercom – alles erledigt. Die Preise für Wandler zwischen HDMI, SDI und NDI starten im mittleren dreistelligen Bereich. Ein System zu erweitern oder umzustellen ist also überschaubar.
ST 2022 und ST 2110 – SMPTE-Standards
Die Anforderungen an IP-basierte Videoübertragung liegen im professionellen Broadcast besonders hoch. Unkomprimiert und latenzfrei muss es sein. Man kann zwar darüber streiten, ob es nötig ist einen Beitrag, der in 720p50 per AVC Intra aufgezeichnet und anschließend geschnitten und in AVCHD gerendert wurde, wirklich unkomprimiert und ohne Latenz durch ein Studio transportiert werden muss, aber diese Diskussion sollen andere führen.
Die „Society of Motion Picture and Television Engineers“ (SMPTE) hat bereits 2007 erste Teile des 2022-Standards veröffentlicht. Die entstandenen Protokolle basieren auf MPEG-2 komprimierten Videosignalen und lassen sich auch in Gigabit-Netzwerken implementieren. Eine Weiterentwicklung ist ST 2022-6:, eine unkomprimierte Alternative zu SDI. Das SDI-Signal wurde hierzu lediglich in eine neue „Transportbox“ gepackt, um über Netzwerke übertragen werden zu können. Das hat für ST 2022-6 hohe Datenraten und die Limitierung auf Videoauflösungen zur Folge. Dennoch kamen und kommen die Varianten von ST 2022 noch vielerorts zum Einsatz. Die komprimierte Variante hat eine gute Kompatibilität zu Softwarelösungen und ein fortlaufender Ausbau dieses Standards wäre wünschenswert gewesen.
Schließlich wurde ST 2110 entwickelt, eine unkomprimierte Übertragungstechnologie mit Latenzen unter einem Frame. ST 2110 nutzt nur sehr kleine Buffergrößen und erreicht so die geringen Latenzen. Die Folge ist eine hohe Frequenz, in der Datenpakete gesendet und verarbeitet werden, was wiederum besondere Anforderungen an die Netzwerkinfrastruktur stellt: Ein 1080p-Stream bei 60 Hz hat eine Datenrate von etwa 3 Gbit/s. Selbst bei 1080i liegt die Datenrate noch bei ca. 1,5 Gbit/s. Ein normales Gigabit-Netzwerk könnte also nicht einmal einen einzelnen Full-HD-Stream transportieren. Da Video, Audio und Zusatzdaten getrennt transportiert werden, sind zusätzliche Tools und Protokolle (z. B. PTP, NMOS) notwendig, um exakte Timings und die Abrufbereitschaft der Streams im Netzwerk sicherzustellen.
Der Standard ST 2110 findet Anwendung bei der Installation neuer Studios größerer TV-Produktionssender, in den Eventalltag wird dieses Protokoll jedoch nicht so schnell vordringen. Nicht nur liegt den Signalen in vielen Fällen ohnehin noch eine Wandlung von SDI auf ST 2110 zugrunde, auch gibt es bisher nur wenig Hardware und noch weniger Software, welche unseren Veranstaltungssektor sinnvoll dienen kann. ST 2110-basierte Systeme sind weit weg von einer Plug-and-Play-Lösung und schon deshalb werden die Schnittstellen zwischen Broadcast und Event vorerst noch per SDI oder vielleicht NDI überbrückt werden.
Mit der Erweiterung ST 2110-22 ist es zwar auch möglich, JPEG XS und anders komprimierte Videodaten zu übertragen, das High-Level-Netzwerkmanagement bleibt jedoch bestehen. Der Einsatz von ST 2110 ist dem LAN und Cloud Computing vorbehalten.
Die Entwicklung und Implementierung von Standards ist zäh und langwierig. IT-Switches und Server, die hunderte Gigabit pro Sekunde verwalten können, existieren zwar und werden allmählich günstiger, für unsere Branche ist mit ST 2110 jedoch kein Anreiz zur Investition geschaffen. Aus den Augen verlieren sollte man die Entwicklung dennoch nicht, schließlich ist eine Vereinheitlichung über Standards wünschenswert und generell nachhaltiger als unter Verschluss gehaltene Quellcodes proprietärer Protokolle.
SRT – Secure Reliable Transmission
SRT ist ein Open Source Protokoll, welches ursprünglich von Haivision entwickelt wurde, um Videoübertragungen über das Internet zu verbessern. Übertragungen über das Internet sind anfälliger für den Verlust von Datenpaketen. SRT bedient sich der ARQ-Technologie zur Wiederherstellung verlorengegangener Datenpakete. Dabei fordert der Empfänger fehlerhafte oder verlorene Pakete erneut an. Da nur erneut gesendet wird, was nicht gelesen werden konnte, bleibt die Datenrate schmal und die Qualität dennoch hoch. SRT passt die Buffergrößer der Netzwerkumgebung an und stellt somit sicher, dass auch bei schlechten Verbindungen eine Übertragung möglich ist.
SRT ist aber auch in der Lage, eine Ausfallsicherheit per FEC zu ermöglichen, was eine höhere Datenrate, aber kein erneutes Senden von Paketen zur Folge hat. Mit einer stabilen Internetverbindung kann man Latenzen von etwa einer Sekunde erreichen. SRT bietet sich deshalb für Live-Schalten zu anderen Standorten einer dezentralen Online-Konferenz an oder auch für die Verbindung zu Berichterstattern. Es wundert also nicht, dass man SRT-Streams als Quelle in vMix, TriCaster, OBS, Wirecast und anderer Software findet. Gleichermaßen sind viele Software- und Hardwareencoder in der Lage, SRT-Streams zu erzeugen. SRT ist Codec-agnostisch und nicht in Auflösungen beschränkt.
SRT-Streams können Peer-2-Peer oder auch über dedizierte Server gesendet werden. Für direkte Verbindungen über das WAN muss man die eigene, öffentliche IP kennen und Portweiterleitungen für den entstehenden UDP-Traffic einrichten. Bei der Weiterleitung über Server kann auf diesen Schritt verzichtet werden, hier entsteht jedoch wieder mehr Latenz und nicht jeder hat einen Server zur Weiterleitung parat oder möchte den Service bei Drittanbietern einkaufen. SRT-Streams sind Ende-zu-Ende verschlüsselt. Auch in LAN-Strukturen kann SRT ein guter Begleiter sein, wenn es nicht ganz Echtzeit sein muss.
Im Zusammenhang mit SRT hat Haivision die SRT Alliance gegründet: ein Verband aus Technologieträgern im Hard-und Softwarebereich. Der Schritt von Haivision SRT zu einem Open-Source-Projekt zu machen ist lobenswert und Grundlage für die breite Akzeptanz und Unterstützung des Codecs seitens namhafter Hersteller. Allerdings warten wir noch auf die großen CDNs und Videoportale. Videostreams per SRT an Server zu übertragen, wäre eine gute Alternative zu RTMP.
2. Vom Internet zum Empfangsgerät: WebRTC, RTMP, HLS
WebRTC – Web Real-Time Communication
Unter WebRTC wird eine Sammlung aus Standards, Protokollen und JavaScript-APIs zusammengefasst. Es ist mehr als nur ein Protokoll zur Übertragung von Video- und Audiodaten. WebRTC ist die schnellste Form der Internetübertragung in unserer Aufstellung, mit Latenzen von bis zu unter 500 ms. WebRTC ermöglicht es, allein mit dem Browser zum Klienten für Video-over-IP-Kommunikation zu werden. Die meisten browserbasierten Konferenztools bedienen sich dieser Technologie, entweder komplett oder in Teilen.
Der Fokus liegt hier natürlich klar auf der Anwendung im Internet. Da es sich um eine Lösung zur Videokonferenz handelt, ist WebRTC nicht unbedingt beliebig skalierbar. Aus diesem Grund sehen wir keine großen, öffentlichen Veranstaltungen, die auf dieser Technologie beruhen. Wo WebRTC aber sehr wohl zum Einsatz kommt, ist bei der Anbindung von Gästen in virtuellen Veranstaltungen. Ob nun WebEx, vMix Call, OBS Ninja, Jitsi oder Big Blue Button. Kaum eine Lösung, die den Browser zum Einstiegspunkt für Talkrunden macht, kommt ohne WebRTC aus.
RTMP – Real Time Messaging Protocol
RTMP ist ein Streaming-Protokoll aus dem Hause Adobe. Es war ursprünglich zum Streaming zwischen Servern und dem Adobe Flashplayer gedacht. Lange Zeit war dieses Protokoll der Standard für Live- und On-Demand-Streams. Obwohl der Adobe Flashplayer abgekündigt ist, so ist RTMP noch immer das Protokoll, welches wir regelmäßig für die Einspeisung von Livestreams in das Internet nutzen. YouTube, Facebook, Akamai, Vimeo – jedes CDN nimmt nach wie vor RTMP-Streams entgegen.
Für die Weiterverteilung im Internet und die Übergabe an Endgeräte hat RTMP allerdings ausgedient. CDNs und Videoplattformen wandeln in der Regel in HLS-Streams oder DASH um. Dieser zusätzliche Protokollwechsel erhöht erneut die Latenz zwischen Sender und Empfänger. RTMP hält sich hartnäckig, da es sehr einfach zu konfigurieren ist und sich noch keine Alternative deutlich genug hervorheben konnte.
HLS – HTTP-Livestreaming
Das Protokoll von Apple dient vor allem der Auslieferung von Streams an Endgeräte. Wir selbst senden selten in diesem Protokoll. Wenn es jedoch darum geht, einen Stream in mehreren Auflösungen gleichzeitig bereitzustellen, kann HLS auch im LAN interessant werden. Multibitrate Encoding gehört für HLS zum guten Ton. Fast alle Endgeräte und Browser sind in der Lage, HLS-Streams wiederzugeben. Aus diesem Grund ist es auch von Videoplattformen und CDN-Diensten das geläufigste Protokoll für die Auslieferung von Streams zum Empfangsgerät. Einige Portale bieten bereits die Möglichkeit, Streams per HLS anzuliefern. Diese Lösung ist für feste Häuser in Erwägung zu ziehen. Für den mobilen Einsatz ist diese Variante nicht sehr gut geeignet, da diese Option basierend auf der Absender-IP beim Anbieter freigeschaltet werden muss.
Alle behandelten Protokolle gibt es hier auch nochmal in einer kompakten Übersichtstabelle (zum Vergrößern bitte anklicken):
Video over IP begegnet uns jetzt in allen Abläufen einer Veranstaltung. In der Verwaltung unserer Quellen, bei der Anbindung von Gesprächsteilnehmern, bei der Verknüpfung von Spielstätten und der Auslieferung an Zuschauer. Während es vor kurzem noch möglich war, nur das Nötigste zum RTMP-Streaming zu wissen, wird dieser Ansatz nicht mehr lange ausreichen. Wir können versuchen, weiter die großen Screen-Managementsysteme und Bildmischer auf kleine Online-Konferenzen loszulassen, aber es wird nicht lange dauern, da hat die Crew von 2-3 Personen mit leistungsstarken Desktop-PCs, gut konfigurierten IT-Switches und einer Handvoll Konvertern klar die Nase vorn in Sachen Preis/Leistung. Es gilt also, die Arbeitsabläufe zu hinterfragen und das Berufsbild des Videotechnikers um die Eckpfeiler der IT zu erweitern. Wer hier nicht dran und flexibel bleibt, droht langfristig auf der Strecke zu bleiben.