Streaming ist heutzutage fester Bestandteil unseres Alltags, vor allem wenn es um das Konsumieren von Videos geht. Den klassischen Fernseh-Apparat gibt es nicht mehr und ein TV-Gerät muss schon lange auch Streams empfangen können, um sich erfolgreich am Markt zu behaupten. In der Medienproduktion dagegen kommt Streaming bisher nur selten zum Einsatz, vor allem in Anwendungsbereichen, die Interaktion erfordern und deshalb niedrige Latenzen benötigen. Mit SRT (Secure Reliable Transport) steht ein freies Streaming-Protokoll zur Verfügung, welches sich besonders gut für Remote-Produktionen, Monitoring und Live-Berichterstattungen eignet. Im zurückliegenden Jahr hat es durch die Pandemie enormen Aufschwung erfahren. Im folgenden Artikel wird die Funktionsweise des Protokolls sowie dessen Features erläutert und auf die Herausforderungen im Streaming sowie Fehlersuche im Problemfall detailliert eingegangen
Um Video mit geringer Latenz über IP-basierte Netzwerke zu übertragen, werden typischerweise MPEG-TS über UDP oder das RTP-Protokoll verwendet. Während dies sehr gut in lokalen Netzwerken funktioniert, bei denen etwaige Paketverluste mittels „Forward Error Correction” (FEC) ausgeglichen werden können, so stößt dieses Verfahren bei Übertragungen zwischen zwei Städten, Ländern oder Kontinenten schnell an seine Grenzen. Sind im eigenen Netzwerk Paketverluste kaum ein Thema, können sie im Internet leicht ein- bis zweistellige Prozentwerte erreichen und das Video unbrauchbar machen. Und selbst wenn diese Werte nur sporadisch und kurzzeitig auftreten, ist an eine professionelle Nutzung nicht zu denken. FEC kann maximal Paketverluste von drei bis fünf Prozent kompensieren, in üblicher Konfiguration sogar oft weniger. Allerdings müssen hierfür permanent redundante Daten versendet werden, unabhängig davon, ob Verluste auftreten oder nicht. Daher wird FEC oft nur eingesetzt, wenn kein Rückkanal für Datenübertragungen vorgesehen ist, wie beispielsweise bei Multicast, oder wenn die Latenz der Übertragung sehr hoch ist, wie bei Satellitenverbindungen. Ein weiteres Problem ist die Varianz von Laufzeiten einzelner Datenpakete, Jitter genannt. Insbesondere im Internet können Pakete verschiedene Wege zum Ziel nehmen, wobei manche Routen langsamer und andere schneller sind. Auf Empfänger-Seite kann es daher vorkommen, dass die Pakete nicht in der richtigen Reihenfolge vorliegen und wieder neu sortiert werden müssen. Abhilfe können hier direkte Verbindungen schaffen, wie etwa über Satelliten oder „Multiprotocol Label Switching” (MPLS) Netzwerke. Letztere ermöglichen eine verbindungsorientierte Übertragung in einem verbindungslosen Netz entlang eines zuvor aufgebauten Pfades. Beide Varianten bedürfen allerdings spezieller, kostenintensiver Hardware und müssen in der Regel mit einiger Vorlaufzeit gebucht werden. Auch die Verfügbarkeit am Standort ist nicht immer gegeben, denn Satelliten haben eine Ausleuchtungszone, in welcher es nur eine begrenzte Anzahl von Slots gibt und für MPLS müssen entsprechende terrestrische Kabel von einem Anbieter bereitgestellt werden.
SRT – die quelloffene Alternative im Detail
Das „Secure Reliable Transport” (SRT) Protokoll hat seine Wurzeln im „UDP-based Data Transfer” (UDT) Protokoll [1]. UDT wurde ursprünglich für den schnellen Transfer von Dateien über öffentliche Netzwerke entworfen und war somit nicht optimal für Live-Streaming. Vor zehn Jahren begann die kanadische Firma Haivision mit der Weiterentwicklung von UDT für eine Anwendung im Streaming-Bereich. Haivision ist ein Hersteller von Hardware Video-Encodern und Decodern mit extrem geringer Latenz, doch gab es damals einfach kaum Möglichkeiten, diese Schnelligkeit auch über weite Strecken oder unzuverlässige Netzwerke auszuspielen. Daher war die Zielsetzung klar: niedrigste Latenz, Robustheit gegen Datenverluste und Sicherheit durch AES 256 Bit Verschlüsselung.
Eine alternative Technik zu FEC brachte UDT mit:„Automatic Repeat reQuest” (ARQ). Um die Funktionsweise genauer zu erklären, ist ein kurzer Ausflug in die Transportschicht nötig. UDT sowie SRT nutzen UDP für den Transport und gehören somit in Familie der verbindungslosen Protokolle. Der Sender bekommt auf Protokoll-Ebene keine Rückmeldung darüber, ob die Daten beim Empfänger angekommen sind. Dies muss die entsprechende Anwendung übernehmen. Im Gegensatz dazu wird bei TCP der Empfang jedes einzelnes Paketes bestätigt und der Empfänger meldet ein sogenanntes „Acknowledgement” (ACK) zurück. Die Anwendung braucht sich nicht um die Datenintegrität zu kümmern und kann sich auf das Protokoll verlassen, was allerdings einen erhöhten Overhead an Daten bedeutet. Beispiele für TCP-basiertes Streaming sind RTMP oder HLS. SRT nummeriert jedes einzelne Paket mit einer „Packet Sequence Number” und ermöglicht so, dass fehlende Pakete vom Empfänger mittels NAK (not acknowledged) gemeldet werden können. Nun greift ARQ Mechanismus und die fehlende Sequenz von Paketen wird automatisch nochmals versendet. In Abbildung 1 ist dies exemplarisch dargestellt. Die Pakete 2, 5 und 6 gehen während der Übertragung verloren und werden vom Empfänger mittels eines NAK Reports neu angefordert. Der Sender verschickt diese erneut, gegebenenfalls mehrmals, bis sie per ACK als empfangen bestätigt werden. Das ARQ Verfahren benötigt allerdings zwei Puffer. So muss der Sender bereits verschickte Pakete in einem Zwischenspeicher vorhalten, für den Fall, dass sie erneut angefordert werden. Der Empfänger puffert die angekommenen Daten bevor sie ausgespielt werden, um sie einerseits in die richtige Reihenfolge zu bringen, falls Jitter aufgetreten ist, und um abzuwarten, ob verloren gegangene Pakete eventuell zu einem späteren Zeitpunkt über das ARQ Verfahren eintreffen.
Alles zu seiner (richtigen) Zeit
Die notwendige Pufferung auf beiden Seiten kostet ein wenig Zeit, bringt allerdings neben der Robustheit gegenüber Paketverlusten noch weitere Vorteile mit sich. Bei geringen RTT’s ist SRT jedoch im Vorteil, weil FEC erst die komplette Matrix empfangen und analysieren muss. Doch wieviel Latenz muss man einplanen? Kurz gesagt: 20 Millisekunden ist der minimal einstellbare Wert, welcher aber von der Gesamtlaufzeit der Verbindung abhängig ist. Bestimmt wird diese Verzögerung von der Paketumlaufzeit, im englischen Round Trip Time (RTT). Der SRT „Latency” Puffer sollte mindestens 1,5x so groß sein wie die RTT, damit ein verlorenes Paket wenigstens einmal neu versendet werden kann. Es ist leicht nachzurechnen: die Übertragung eines Pakets braucht eine halbe RTT, das Rückmelden eines NAK Reports eine weite halbe RTT und das erneute Versenden wiederum – Sie ahnen es – eine halbe RTT. Da dies eine idealisierte Rechnung ohne Verluste in der Software oder Schwankungen der RTT ist, sollte der Wert in der realen Welt höher liegen. In der Praxis haben sich Werte von 3x bis 4x RTT bewährt, um genügend Spielraum für mehrmaliges Nachsenden von Paketen zu bieten und Fluktuationen der RTT auszugleichen. Maximal möglich sind 8 Sekunden. Die typische RTT von Deutschland an die US-Ostküste über das Internet beträgt circa 110 ms. Mit SRT sind also Ende-zu-Ende Latenzen von 330 bis 440 ms möglich, was deutlich schneller ist als eine Satellitenverbindung. Dabei sind Encoding und Decoding nicht mit einberechnet. Gleichzeitig können dabei höhere Verlustraten als bei der Verwendung von FEC kompensiert werden. Die Bandbreite, welche SRT zusätzlich für das erneute Versenden von Paketen verwendet darf, ist frei konfigurierbar. Voreinstellung sind 25 Prozent, aber die werden nur in seltenen Fällen benötigt, wenn die Verbindung sehr hohe Paketverlustraten aufweist. Diese Einstellmöglichkeit kann sehr hilfreich sein, wenn die Übertragungsgeschwindigkeit im Netzwerk limitiert ist und man die verfügbare Bandbreite optimal ausnutzen möchte. Für die Berechnung der benötigten Bandbreite (inklusive des SRT Protokoll Overheads) gibt es einen Online-Rechner im SRT CookBook [2].
Die SRT „Latency” wird übrigens während des Verbindungsaufbaus zwischen beiden Parteien ausgehandelt. Der höchste Wert wird übernommen. Das kann sehr praktisch sein, wenn sich die RTT gegenüber einem vorherigen Test zu längeren Laufzeiten hin verändert hat, aber der Operator nur auf eine der beiden Seiten Zugriff hat. Doch nun zu den angesprochenen weiteren Vorteilen und der Antwort auf die Frage: Was passiert eigentlich, wenn ARQ Nachsendungen zu lange brauchen? Hier kommt der Parameter „Too-Late Packet Drop” (TLPKTDROP) ins Spiel. Wie die englische Bezeichnung schon andeutet, werden Pakete, welche nicht innerhalb der gesetzten SRT „Latency” ankommen, verworfen. Das kann natürlich zu Artefakten in der Dekodierung des Streams führen und schlimmstenfalls zu kompletten Bildausfällen, aber die Latenz des Streams bleibt konstant. Und hier liegt der Vorteil versteckt. Der Empfänger hat immer eine konstante Verzögerung und diese kann sich nicht durch Ausfälle über die Zeit aufsummieren – ein besonders wichtiger Aspekt bei Monitoring-Anwendungen und im Bereich der bi-direktionalen Kommunikation.
Der TLPKTDROP Mechanismus kann aber auch deaktiviert werden, wenn Datenintegrität gefordert ist, etwa wenn es um das Übertragen von Dateien geht, was sich neben Live-Streaming auch mit SRT realisieren lässt. In diesem Fall ist ARQ solange aktiv, bis alle Pakete vollständig auf der Empfängerseite eingetroffen sind. Ein weiterer Nutzen, welcher durch die Nutzung der Puffer ermöglicht wird, ist mit dem Parameter „SRT Timestamp-Based Packet Delivery” (TSBPD) verknüpft. Jedes einzelnes Paket enthält nämlich neben der Sequenz-Nummer auch einen Zeitstempel in Mikrosekunden, relativ zum Zeitpunkt des Starts der SRT-Verbindung. Ist TSBPD aktiviert, spielt der SRT-Empfänger die Pakete mit angepasster Verzögerung an die nachfolgende Applikation aus, so dass die Charakteristik des Streams genau der Senderseite entspricht. Die „Play-Time” entspricht dabei dem Zeitstempel des erzeugten SRT-Pakets plus die eingestellte, konstante Latenz. Ein etwaiges driften der Systemuhr des Senders und Empfängers wird dabei kompensiert und unterschiedliche Zeitzonen angepasst. In Abbildung 2 ist dieses Verhalten schematisch dargestellt. Im oberen Teil des Bildes ist zu sehen, wie schwankende Übertragungsbandbreite, Verzögerungen, Jitter und Paketverluste die Stream-Charakteristik regelrecht deformieren. Dies kann zu Problemen beim Decodieren des Videostreams führen, welche sich in Artefakten oder schwankender Frame-Rate äußern oder gar zum Absturz des Decoders führen können. Wird der Stream durch einen SRT-Tunnel übertragen, wie im unteren Teil des Bildes gezeigt, entspricht das Timing der einzelnen Pakete genau der Senderseite, nur um die gesetzte „Latency” verzögert. Besonders vorteilhaft ist dieses Verhalten bei Broadcast-Decodern, welche eine konstante Bitrate (CBR) erwarten. Mit Hilfe des Zeitstempels lassen sich auch mehrere Streams von verschiedenen Encodern auf der Decoder- Seite synchronisieren. Dazu müssen lediglich alle Knotenpunkte auf dieselbe Zeit geeicht sein. Allerdings ist dies keine Funktion des SRT Protokolls, kann aber leicht in der Applikationsebene realisiert werden. Remote Produktionen mit mehreren Kameras werden so leicht realisierbar.
Mit dem Kopf durch die Brandschutzmauer
Wer immer mit dem Kopf durch die Wand will, bekommt meistens Kopfschmerzen. Und so ergeht es auch vielen Streaming-Operatoren, besonders wenn die Start- oder Endpunkte der Streams nicht innerhalb des eigenen Netzwerkes liegen und man sich mit der IT-Administration anderer Unternehmen auseinandersetzen muss. Das Öffnen eines Ports in der Firewall kann eine langwierige Geschichte werden. Wenn es denn überhaupt möglich ist. Das Design von SRT bietet beim Verbindungsaufbau eine große Flexibilität und stellt drei Modi bereit: „Caller”, „Listener” und „Rendezvous”. Ein „Listener” wartet auf einem frei definierbaren UDP Port auf einen Anruf der Gegenseite, die als „Caller” agiert. Die Richtung des Streams spielt dabei keine Rolle und ein Sender kann „Caller” oder „Listener” sein, solange der Empfänger gegensätzlich konfiguriert ist. Der „Listener” sollte dort platziert werden, wo es möglich ist, einen Port in der Firewall zu öffnen. Das kann auch sehr nützlich sein, wenn es vorab nicht bekannt ist, woher die Streams kommen oder wohin sie gehen sollen. Nur der „Caller muss die Adresse und den entsprechenden Port kennen sowie das Passwort, wenn die AES Verschlüsselung aktiviert ist. Sind beide Seiten jeweils hinter einer nicht zu öffnenden Firewall, kann man den „Rendezvous” Modus verwenden. Dabei versenden beide Seiten gleichzeitig Verbindungsanfragen und versuchen so, über den geöffneten Kanal für die Rückantworten eine Datenverbindung aufzubauen. Dieses Verfahren wird auch „Hole- Punching” genannt [3]. Eine weitere Variante besteht darin, eine dritte SRT-Instanz bereitzustellen, welche auf mindestens einem UDP Port erreichbar ist. Diese wird so konfiguriert, dass Eingang sowie Ausgang im „Listener” Modus arbeiten und so eine Proxy-Funktion realisiert wird, da Sender und Empfänger als „Caller” anrufen. Auch „Callback” Szenarien sind umsetzbar, in welchen der „Listener” dazu aufgerufen wird, eine Verbindung als „Caller” aufzubauen. Selbst bei einer Vielzahl von Verbindungen reicht ein einziger UDP-Port, wenn das „Stream- ID”-Feature verwendet wird. Mit diesem können verschiedene SRT-Streams unterschieden werden. So können gleichzeitig mehrere Streams an einen Knotenpunkt gesendet und gleichzeitig auch zum Abruf bereitgestellt werden. Die Funktionsweise ist analog zum „Stream Key” oder „Stream Name” des RTMP-Protokolls.
SRT als Lastesel
Zugegeben: der Vergleich mit einem Esel hinkt etwas und sollte in erster Linie darauf hindeuten, dass SRT agnostisch gegenüber Inhalten ist und mit aller Art von Daten beladen werden kann, die sich über UDP versenden lassen. Dateien können verschickt werden, genauso wie Live-Audio- oder Videostreams [4]. Die Wahl des Codecs ist auch kaum eingeschränkt. Möglich sind H.264, HEVC, JPEG2000 im Video und MPEG-1 Audio Layer II, AAC oder PCM im Audiobereich, um nur einige zu nennen. Über eine SRT-Verbindung lassen sich auch gleichzeitig mehrere Streams in verschiedenen Formaten versenden. Weiterhin können auch andere Stream-Protokolle über SRT getunnelt werden, wie beispielsweise RTP, MPEG-TS oder NDI-HX. Und auch Steuerdaten können übertragen werden. Und anders als beim Esel, welcher oft nur schwer überhaupt in eine Richtung zu bewegen ist, können Datenströme innerhalb von SRT bi-direktional fließen. So werden in zahlreichen SRT-Implementierungen neben Videos parallel auch Daten wie Pan, Tilt, Zoom für PTZ-Kameras, Tally oder Audio-Rückkanäle für Regie-Anweisungen vom Empfänger an den Sender geschickt.
Ein weiteres Highlight ist die Möglichkeit, SRTStreams über „Socket Groups”[5] redundant zu verschicken. Im „Broadcast”-Modus werden SRT-Pakete über zwei (oder mehrere) Netzwerkschnittstellen gleichzeitig versendet. Der Empfänger nimmt einfach das erste ankommende Paket an und verwirft alle anderen mit der gleichen Sequenznummer. Der Ausfall einer Leitung stellt kein Problem dar, solange über die anderen noch Pakete transferiert werden. Da das Ganze auf Paket-Ebene passiert, gibt es keine Unterbrechung im Decoding, denn es ist kein Umschalten zwischen parallelen Streams. Auch ist keine externe „Bonding” Hard- oder Software nötig. Der „Main/Backup” Modus kommt mit weniger Datenvolumen aus, da hier immer nur ein Link aktiv ist. Alle weiteren Verbindungen werden im Sekundentakt auf Vitalität überprüft. Kommt der Main-Link ins Stottern, wird der Datenstrom auf einen der Backup- Links umgeleitet. Beiden Modi ist gemein, dass die langsamste Verbindung die Gesamtlatenz vorgibt. In Planung ist weiterhin ein „Balancing” Modus, mit dem Zweck, mehrere Leitungen für eine höhere Gesamt-Bandbreite zusammenfassen.
Trau keiner (fremden) StatistikWenn etwas nicht funktioniert, ist guter Rat teuer und jeder noch so kleine Hinweis kann des Rätsels Lösung sein. Je mehr Statistiken man zur Verfügung hat, desto besser. Doch können diese auch trügerisch sein. Beispielhaft seien hier Speed-Tests angeführt. Hat man einen Hardware-Encoder, so führt man den Test zur Ermittlung der verfügbaren Bandbreite oft auf einem separaten Rechner aus. Allerdings wird dafür oft das TCP-Protokoll verwendet und nicht UDP. Auch andere Parameter können unterschiedlich sein, wie z. B. ein anderer Switchport oder Netzwerkkabel, Einstellungen für Quality of Service (QoS) oder gar die Route an sich. Besser ist es, die Statistiken des eigentlichen Streams zu verwenden, welche SRT reichhaltig zur Verfügung stellt. In Abbildung 3 sind die SRT-Statistiken eines SRT-Empfängers zu sehen, in diesem Fall ein Haivision SRT Gateway. Anhand dieses Screenshots lässt sich wunderbar die Fehlersuche nachvollziehen. Für ein FKTG-Webinar wurde ein Stream über eine wirklich schlechte DSL-Verbindung zur Verfügung gestellt, um den Troubleshooting-Prozess aufzuzeigen. Die Leitung sollte eigentlich mehr als 3 Mbps Bandbreite bieten, doch selbst ein 2 Mbps Stream kam nicht fehlerfrei durch. Deutlich kann man erkennen, dass in den ersten 2 Minuten die Verlustrate bei über 1 Mbps lag. Testweise wurde die Bandbreite des Encoders auf 300 kbps reduziert und keine Pakete gingen mehr verloren. Danach folgte eine Anhebung auf 1 Mbps mit besseren Resultaten und letztendlich die Reduzierung auf 700 kbps, welche sich als stabil erwies. Selbst für unerfahrene Anwender lässt sich dieser Prozess in weniger als einer Minute bewerkstelligen. Da die Statistikdaten in Echtzeit anfallen, können diese auch von externen Anwendungen genutzt werden, um die Bitrate des Encoders auf die aktuellen Gegebenheiten anzupassen. Auch lassen sie sich als Nachweis verwenden, wenn die bereitgestellte Leitung nicht die Perfomance bietet, die versprochen wurde. In Gruppenarbeit zum StandardNach fünf Jahren im Einsatz als proprietäres Protokoll in zahlreichen Haivision Produkten wurde SRT im Jahr 2017 als Open-Source-Code auf Github veröffentlicht [6]. Es kann frei und ohne weitere Kosten im Rahmen der „Mozilla Public License Version 2.0” verwendet, implementiert, weiterentwickelt und angepasst werden. Die Open-Source-Community nahm SRT mit Begeisterung an und das Protokoll fand sich schnell auch in anderen Projekten wie FFmpeg, libav, VLC, Wireshark, Open Broadcaster Software wieder und gehört zu den Standard-Paketen der Linux Distribution Debian und deren Derivaten. Auch in der kommerziellen Welt der industriellen Hersteller und Solution-Provider ist SRT mittlerweile eine feste Größe. Zeitgleich mit der Veröffentlichung des Source-Codes wurde die SRT Alliance gegründet [7]. Ihre Mission ist es, die Herausforderungen des Video-Streamings mit niedriger Latenz zu überwinden und damit die Art und Weise zu verändern, wie die Welt streamt. Grundlegend für diese Mission ist die Unterstützung eines frei verfügbaren Open-Source-Videotransportprotokolls und -Technologiestacks, der Innovationen durch gemeinschaftliche Entwicklung beschleunigen soll. Die SRT Alliance fördert die branchenweite Anerkennung und Übernahme von SRT als gemeinsamen Standard für Anwendungen des Internet- Streaming mit niedriger Latenz. Die SRT Alliance ist offen für neue Mitglieder und Unternehmen, die sich aktiv am Ausbau des SRT-Ökosystems beteiligen oder einfach der Allianz beitreten möchten, um die SRT-Technologie zu unterstützen. Innerhalb von vier Jahren sind bereits mehr als 500 Firmen und Hersteller der SRT Alliance beigetreten [8]. Regelmäßig finden Kompatibilitäts-Tests im Rahmen des virtuellen „SRT Plugfest” statt, um die verschiedenen Implementierungen auf Interoperabilität zu prüfen. Die Standardisierung ist mit der Einreichung eines „Request for Comments” (RFC) bei der „Internet Engineering Task Force” (IETF) im März 2020 einen weiteren großen Schritt vorangekommen [9]. Die Lektüre dieses Dokumentes ist nicht nur für den versierten Programmierer empfehlenswert, sondern kann jedem Leser dieses Artikels an Herz gelegt werden, dessen Neugier nun erst recht geweckt wurde. FazitSRT ist ein offener Standard, der derzeit von einer Allianz mit einer großen Anzahl aktiver Technologielieferanten unterstützt wird, was für Produktvielfalt sorgt und die Risiken und Kosten eines „Lock-in“ einzelner Anbieter vermeidet. Diese enthusiastische Gemeinschaft fördert nun viele Lösungen, die eine breite Palette von Industrieund Broadcastanwendungen adressieren, einschließlich IP-, PTZ- und Studio-Kameras, Encodern, Decodern, Gateways, OTT-Plattformen und CDNs sowie mobilen Endgeräten. Was SRT nicht leisten kann, ist das millionenfache Streaming zum Zuschauer. Grenzen setzen hier die Skalierbarkeit auf der Serverseite, da das Einfügen der Zeitstempel in jedes einzelne Paket und die individuelle ARQ Fehlerkorrektur für jede einzelne Verbindung bei sehr vielen gleichzeitigen Streams die CPU`s eher auslasten, als das reine Bewegen von Bits über viele parallele 10GE oder 100GE Netzwerkkarten. Weiterhin wäre für einen solchen Anwendungsfall eine native Unterstützung des SRT-Protokolls im Browser unabdingbar, ohne zusätzlich zu installierende Plugins. Aber letzteres kann ja noch werden.
ERROR: Content Element with uid "23470" and type "dce_dceuid2" has no rendering definition!
