Übertragungsprotokolle

Wie ein Stream von einem Knoten auf einen anderen oder zu Fremdgeräten gelangt. Hier steht, welches Protokoll Sie wählen, was es an Bandbreite und Latenz kostet, welche Ports es belegt und wie es verschlüsselt wird.

Fällt nicht die Strecke aus, sondern die Quelle, das Netz oder der Knoten — Redundanz: was wovor schützt.

Peer-Protokolle für zuverlässige Übertragung

Für die Übertragung zwischen Sender und Empfänger stehen vier Peer-Protokolle zur Verfügung. Sie gliedern sich nach dem Prinzip der Verlustkompensation in zwei Klassen:

• ARQ (Automatic Repeat reQuest) — verlorene Pakete werden auf Anforderung des Empfängers erneut übertragen. Erfordert einen Rückkanal und einen Puffer auf dem Empfänger; die Wiederherstellungstiefe ist konfigurierbar. Zu dieser Klasse gehören PS1, SRT und RIST.

• FEC (Forward Error Correction) — dem Stream werden fortlaufend redundante Daten hinzugefügt, mit denen sich Verluste ohne Rückkanal wiederherstellen lassen. Zu dieser Klasse gehört Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2).

PS1 (Perfect Stream)

Ein selbst entwickeltes Protokoll auf UDP-Basis. Es arbeitet nach dem ARQ-Prinzip mit selektiver Neuübertragung. Es zeichnet sich durch geringen Ressourcenverbrauch aus und überträgt Streams mit hoher Bitrate, einschließlich eines vollständigen MPTS.

• Verbindung. Die Verbindung initiiert der Empfänger, daher ist NAT auf seiner Seite kein Hindernis, und eine Portweiterleitung auf dem Empfänger ist nicht nötig. Der Sender lässt den Empfänger als Peer zu — per Login und Passwort oder per IP.

• Latenz — der Puffer des Empfängers: das Fenster für Jitter-Beseitigung und Neuübertragung. Der Puffer des Senders muss größer sein als die Puffer der Empfänger (Latenz).

• Wechsel der Quelle auf dem Sender unterbricht die Verbindung nicht: Die Lücke schließt die übliche Neuübertragung.

PS1 ist ein proprietäres Protokoll und funktioniert nur zwischen Perfect-Streamer-Knoten. Es eignet sich am besten für eine Punkt-zu-Mehrpunkt-Konfiguration: ein Sender und viele Empfänger.

SRT

Ein offenes Protokoll auf UDP-Basis (auf Grundlage des Protokolls UDT). Es ist weit verbreitet und kompensiert Paketverluste gut. Es unterstützt die Modi listener und caller und ist dadurch kompatibel mit SRT-Geräten von Drittanbietern und Cloud-Diensten.

Im listener-Modus auf dem Sender verbinden sich mehrere Empfänger mit einem einzelnen Stream; zur Autorisierung werden Empfänger als Peer eingetragen, eine Autorisierung per IP ist möglich. Die initiierende Seite (caller) kann sich sowohl auf dem Empfänger als auch auf dem Sender befinden. Die Bandbreitenreserve für die Neuübertragung wird in Prozent über der Stream-Bitrate festgelegt.

Auf einem Empfangsknoten mit einer großen Anzahl von SRT-Eingängen im caller-Modus kann der Puffer des SRT-Empfängers (TSBPD, Auslieferung nach den Zeitstempeln des Senders) abgeschaltet werden: Die Synchronisation übernimmt der Jitter-Puffer des Knotens (Synchronisation), und die CPU-Last sinkt spürbar.

RIST

Ein offenes Protokoll auf RTP/RTCP-Basis. Es arbeitet nach dem ARQ-Prinzip mit NACK: Der Empfänger meldet nur Verluste. Es verwendet Unicast und Multicast.

Die Profile Simple und Main sind implementiert: Simple belegt zwei aufeinanderfolgende UDP-Ports (der Basisport muss gerade sein), Main multiplext die Daten in einen einzelnen Port. Mehrere Pfade (Peers) mit gewichteter Lastverteilung werden unterstützt — für Redundanz und Aggregation. Bei Multicast können es viele Empfänger sein, mit Autorisierung per IP.

Pro-MPEG FEC

Übertragung von MPEG-TS über RTP mit Vorwärtsfehlerkorrektur (FEC), ohne Rückkanal. In Perfect Streamer ist eine zweidimensionale FEC-Matrix implementiert (Zeilen und Spalten, SMPTE 2022-2).

Der Strom von RTP-Paketen wird in eine Matrix vorgegebener Größe gruppiert, entlang deren Zeilen und Spalten FEC-Pakete gebildet werden. Je kleiner die Matrix, desto besser die Wiederherstellung, aber desto höher der konstante Overhead. FEC-Kanäle belegen zwei zusätzliche Ports (port+2 und port+4), was bei der Platzierung mehrerer Streams auf einem Host oder in einer Multicast-Gruppe zu berücksichtigen ist.

Die Vorteile sind niedrige feste Latenz und Kompatibilität mit professioneller Sendetechnik. Die Nachteile sind konstanter zusätzlicher Verkehr und schwache Wiederherstellung bei hohen Verlusten (über ~0,2 %), daher ist das Protokoll für verwaltete Kanäle mit geringen Verlusten und nicht für das „schwere“ öffentliche Internet ausgelegt.

Wichtig

Betaversion 2.1. Das hier Beschriebene gibt es nur in der Betaversion 2.1: Sie wird aus dem Beta-Repository und nur mit einer Lizenz installiert; die stabile Version 2.0.2 und die Demoversion enthalten es nicht. Die Betaversion wird ohne Gewähr ausgeliefert, Support gibt es nach Möglichkeit (Betatestprogramm).

In Version 2.1 entspricht die FEC von Eingang und Ausgang SMPTE ST 2022-1:

• Standardempfänger stellen damit Verluste wieder her;

• der Eingang nimmt FEC nur über Spalten (1D) sowie über Spalten und Zeilen (2D) an, mit einer Matrix beliebiger Größe;

• der Ausgang kann nur FEC über Spalten senden: Bei einer Matrix 5 × 10 beträgt der Mehraufwand 10 % statt 30 %, aber die Wiederherstellung ist schwächer;

• Pro-MPEG lässt sich mit dem zweiten Weg nach SMPTE ST 2022-7 und mit der Hot-Standby-Reserve der Ausgänge kombinieren (Redundanz: was wovor schützt).

Latenz durch das Warten auf FEC — Planung von Bandbreite, Latenz und Ports.

Auswahl des Übertragungsprotokolls

Kurz gesagt.

• ein Kanal zwischen Perfect-Streamer-Knoten, hohe Bitrate oder vollständiges MPTS, Punkt-zu-Mehrpunkt-Verteilung — PS1;

• Kompatibilität mit Geräten von Drittanbietern oder Cloud, Neuübertragungsreserve in Prozent über der Bitrate — SRT;

• ein offener RTP-basierter Transport, Multicast, Lastverteilung über mehrere Pfade — RIST;

• ein verwalteter Kanal mit geringen Verlusten, minimale Latenz ohne Rückkanal, professionelle Sendetechnik — Pro-MPEG FEC.

Im Einzelnen:

Protokoll	Prinzip	Rückkanal	Latenz	Kompatibilität
PS1	ARQ über UDP	erforderlich	konfigurierbar	nur zwischen Perfect-Streamer-Knoten
SRT	ARQ über UDP (UDT)	erforderlich	konfigurierbar	offen; SRT-Geräte von Drittanbietern und Cloud
RIST	ARQ (NACK) über RTP/RTCP	erforderlich	konfigurierbar	offen; RIST-Geräte von Drittanbietern; Unicast und Multicast
Pro-MPEG FEC	FEC über RTP	nicht erforderlich	niedrig, fest	offen (SMPTE 2022-1/2); professionelle Sendetechnik

Planung von Bandbreite, Latenz und Ports

ARQ-Protokolle (PS1, SRT, RIST). Verluste werden durch Neuübertragung kompensiert, daher ist Folgendes vorzusehen:

• einen Rückkanal vom Empfänger zum Sender;

• eine Bandbreitenreserve über der nominalen Bitrate — Verlustspitzen verursachen Spitzen im Neuübertragungsverkehr;

• einen Puffer auf dem Empfänger für die Kanallatenz. Je größer der Puffer, desto tiefer die Verlustwiederherstellung, aber desto höher die Ende-zu-Ende-Latenz; als Richtwert dienen mehrere RTT-Werte. Streams mit niedriger Bitrate erfordern einen zeitlich größeren Puffer, damit genügend Pakete in das Wiederherstellungsfenster passen.

FEC-Protokoll (Pro-MPEG). Redundante Pakete werden fortlaufend übertragen, unabhängig von den tatsächlichen Verlusten, daher ist der Overhead fest und hängt von der Größe der FEC-Matrix ab. Ein Rückkanal ist nicht erforderlich, die Latenz ist niedrig und fest, aber die Wiederherstellung ist begrenzt, daher eignet sich dieser Transport für Kanäle mit geringen Verlusten. Die Wiederherstellung per FEC fügt beim Empfang Latenz hinzu: Solange ein verlorenes Paket auf die FEC seiner Matrix wartet, verzögert der Eingang die Ausgabe. Je größer die Matrix und je niedriger die Bitrate, desto länger das Warten — bei großer Matrix und niedriger Bitrate sind es Sekunden, und der Jitter-Puffer des Eingangs muss sie abdecken (FEC-Wartegrenze).

Ports. Jeder lauschende Endpunkt benötigt einen eindeutigen UDP-Port innerhalb des Hosts oder der Gruppe. Beachten Sie zusätzlich, dass das RIST-Simple-Profil zwei aufeinanderfolgende Ports belegt (den geraden Basisport und den nächsten) und Pro-MPEG den Basisport plus zwei FEC-Ports (port+2 und port+4). In einem Meshwork-Netz hilft ein gemeinsamer Katalog belegter Adressen und Ports, Kollisionen zu vermeiden (siehe Meshwork).

Stream-Verschlüsselung

Die AES-Verschlüsselung wird durch eine gemeinsame Passphrase aktiviert, die auf beiden Seiten der Verbindung festgelegt wird; die Phrasen müssen übereinstimmen. Eine leere Phrase bedeutet Betrieb ohne Verschlüsselung. Die Verschlüsselung ändert die Bitrate des Streams nicht.

Unterstützung und zulässige Länge der Phrase unterscheiden sich je nach Protokoll:

Protokoll	Länge der Passphrase	Besonderheiten
PS1	10–64 Byte	—
SRT	10–79 Byte	Zusätzlich wird die Schlüssellänge gewählt: 128, 192 oder 256 Bit. Eine Phrase außerhalb der zulässigen Länge hält den Eingang oder Ausgang mit einer eindeutigen Fehlermeldung an.
RIST	wird nicht geprüft; verwendet werden die ersten 127 Byte	Nur im Profil Main. Im Profil Simple hat die Passphrase keine Wirkung.
Pro-MPEG	10–64 Byte	Eine nicht standardisierte Erweiterung: Bei ihrer Aktivierung wird die Kompatibilität mit Software und Geräten von Drittanbietern nicht garantiert.

Die Länge der Phrase wird in Byte gezählt, nicht in Zeichen: Ein kyrillischer Buchstabe belegt zwei Byte.

Weitere Eingänge und Ausgänge

Neben den Peer-Protokollen stehen Standardtransporte für Empfang und Übertragung zur Verfügung:

Protokoll	Eingang	Ausgang	Anmerkung
UDP	ja	ja	Unicast/Multicast, SSM, Schnittstellenauswahl; bis zu 7 TS-Pakete pro Datagramm
RTP	ja	ja	Wiederherstellung der Reihenfolge vertauschter Pakete
TCP	ja	—	Client-Modus; Empfang dort, wo UDP blockiert ist
HLS / HTTP	ja	ja	Eingang nur für SPTS; aus der adaptiven Wiedergabeliste wird die Variante nach Nummer gewählt (standardmäßig die erste)
RTSP	ja	—	IP-Kameras und RTSP-Server; Auto-Remux zu MPEG-TS; nur für SPTS
RTMP / RTMPS	ja	ja	Veröffentlichung an RTMP-Empfänger von Drittanbietern; H.264 und HEVC; nur für SPTS
file / device	ja	ja	Aufnahme in eine TS-Datei und MPEG-TS-Ausgabe an ein Gerät (zum Beispiel ASI); Schleifenwiedergabe aus einer Datei
pipe (FIFO)	ja	ja	Brücke zu einem externen Prozess über eine benannte Pipe
std (externe Anwendung)	ja	ja	Brücke zu nicht standardmäßigen Protokollen über eine Konsolenanwendung

Veröffentlichung und Empfang von RTMP sind in RTMP-Veröffentlichung und -Empfang beschrieben; RTSP, HLS/HTTP-Eingang, Dateien und Geräte, benannte Pipes und externe Anwendungen — in Sonstige Ein- und Ausgänge. Detaillierte Einstellungen jedes Transports finden sich im Abschnitt Weboberfläche. Die OTT-Auslieferung (HLS, LL-HLS, DASH) ist gesondert in OTT und DVR beschrieben.

Anforderungen an den Eingangsstream

• Konformität mit ISO/IEC 13818-1, Single Program (SPTS) oder Multi Program Transport Stream (MPTS).

• Die Zusammensetzung der Spuren richtet sich nach dem gewählten Inhaltstyp des SPTS-Streams, siehe SPTS-Streams.

• Verwürfelte (verschlüsselte) Streams werden unterstützt, siehe SPTS-Streams.

• Zur Synchronisation muss der Stream gültige PCR-Marken enthalten.

Filterung, Modifikation und Bitratenmodi des Eingangsstreams sind in SPTS-Streams beschrieben, die Besonderheiten des Multiplex in MPTS-Streams.