FAQ

Antworten auf die Fragen, die im Betrieb am häufigsten auftreten: Kompatibilität von SRT mit Software von Drittanbietern und Multicast-Empfang bei hohen Bitraten.

SRT: Autorisierung mit Login und Passwort in Software von Drittanbietern

Zwischen zwei Perfect-Streamer-Knoten wird die SRT-Autorisierung regulär über die Felder von Eingang und Ausgang konfiguriert (SRT). Das Zusammenspiel mit anderer Software ist nicht garantiert: Der Parameter stream ID ist nicht standardisiert und in verschiedener Software unterschiedlich umgesetzt.

Der Kompatibilitätsmechanismus ist überall derselbe: Die empfangende Seite nimmt die stream ID des sich verbindenden Clients und sucht damit ein Konto in der Liste der lokalen Logins (Benutzer: hinzufügen und bearbeiten). Übereinstimmen muss das Feld „Login“ — vollständig mit dem Wert der stream ID. Zum Beispiel bei der URL

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

wird in das Feld „Login“ Folgendes eingetragen

!#::u=1234567890,password=1234567890

Die Syntax der stream ID ist für Perfect Streamer ohne Bedeutung: Die Zeichenkette wird nicht in Teile zerlegt, sondern als Ganzes verglichen. Es gibt drei Ausnahmen — Zeichen, die der Knoten selbst auswertet:

  • | — Trennzeichen: Der Teil der Zeichenkette vor dem ersten solchen Zeichen gilt als Login, der Rest als Passwort des Kontos;

  • * — es ist keine stream ID gesetzt; der Client wird über die Adresse autorisiert, also über ein Konto mit dem Merkmal „IP-Adress-Konto“;

  • @ am Anfang der Zeichenkette ist der dienstinternen Autorisierung zwischen den Knoten einer Meshwork-Domain vorbehalten.

Perfect Streamer begrenzt die Länge der stream ID nicht — die Begrenzung kommt von der SRT-Bibliothek und beträgt 512 Byte einschließlich des abschließenden Nullzeichens. Werte, die länger als etwa 500 Zeichen sind, sollten nicht übertragen werden: Eine zu lange Zeichenkette bricht entweder die Verbindung ab oder wird leer und ohne Fehlermeldung übertragen.

Verschiedene Software bildet die stream ID auf ihre eigene Weise; funktioniert der Empfang über die URL nicht, aktivieren Sie daher am SRT-Ausgang die erweiterte Einstellung „Trace“. Im Protokoll des Streams, der die Verbindung annimmt, erscheinen dann die Adresse des Clients, die empfangene stream ID und der Grund der Ablehnung — an dieser Zeile ist zu erkennen, was die Gegenseite tatsächlich gesendet hat. Anschließend lässt sich die stream ID korrigieren: zum Beispiel überzählige Zeichen am Anfang der Zeichenkette entfernen, die die Übergabe des Werts verhindern.

Empfehlungen für die Arbeit mit UDP-Multicast

Aufgabe. UDP-Multicast mit einer Gesamtbitrate von mehreren hundert Mbit/s (1 Gbit/s und mehr) auf einem einzigen Server stabil empfangen.

Problem. Beim Empfang über Netzwerkkarten mit RJ-45-Schnittstelle setzen mit steigendem Verkehr oberhalb von einigen hundert Megabit zunehmende Verluste von Multicast-Paketen ein. Eine Feinabstimmung der Karte hilft nicht — in aktuellen Versionen der Betriebssysteme werden bereits die optimalen Werte verwendet. Karten mit besseren Chips beseitigen das Problem ebenso wenig, insbesondere jenseits von 500 Mbit/s. Auch das Bonding zweier Karten hilft nicht: Eine Multicast-Gruppe trifft immer auf einer physischen Leitung und in einer Empfangswarteschlange ein, aggregiert wird daher die Gesamtbandbreite und nicht die Reserve eines einzelnen Streams.

Lösung. Die Betriebserfahrung zeigt, dass für den Empfang und die Übertragung von UDP-Multicast 10-Gigabit-Netzwerkkarten mit SFP+-Schnittstelle eingesetzt werden sollten. Eine günstige Karte der Klasse Intel X520-DA1/2 (Intel 82599ES) genügt — in unseren Tests beseitigt sie die Paketverluste bei Multicast-Verkehr oberhalb von 1 Gbit/s. Zusätzlich sinkt die CPU-Last spürbar: Die Verarbeitung der Interrupts und der Empfangswarteschlangen ist auf solchen Karten günstiger.

Beachten Sie bei der Diagnose: Der Zähler der Empfangsfehler recv-err in der Statistik des Eingangs zählt nur Lesefehler des Sockets und den Synchronisationsverlust an der Grenze eines TS-Pakets. Verluste durch einen Überlauf des Empfangspuffers des Kernels erreichen die Anwendung nicht und gehen in diesen Zähler nicht ein — sie sind über den Befehl netstat -su (Zeile RcvbufErrors) und über die Continuity-Fehler im Analysator des Streams sichtbar (Analysator).

Empfehlungen zur Netzwerkkonfiguration für Multicast

Der Abschnitt betrifft die Netzwerkeingänge UDP / RTP und Pro-MPEG. Auf den SRT-Empfang wirken sich diese Parameter nicht aus: Die SRT-Bibliothek legt die Puffergröße selbst fest, während die Verzögerung und die Reserve für die Neuübertragung am Eingang selbst konfiguriert werden (SRT).

Die Größe des Empfangspuffers des Sockets wird über die erweiterte Eingangseinstellung „Socket buffer (bytes)“ festgelegt. Standardmäßig ist sie null — der Knoten fordert nichts an, und der Socket erhält die Puffergröße, die im System über den Parameter net.core.rmem_default vorgegeben ist. Sobald ein Wert ausdrücklich gesetzt ist, greift die Obergrenze net.core.rmem_max: Der Kernel kürzt die Anforderung stillschweigend auf diesen Grenzwert und meldet die Kürzung weder im Protokoll noch in der Statistik. Deshalb wird die Obergrenze angehoben, bevor die Puffergröße am Eingang gesetzt wird.

Die Parameter werden in einer eigenen Datei in /etc/sysctl.d/ festgelegt:

cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF

Anwenden:

sudo sysctl --system

Der Wert rmem_max ist nur eine Obergrenze; Speicher wird dafür nicht reserviert. Der Wert rmem_default gilt für alle UDP-Sockets des Systems; ist eine derart globale Größe unerwünscht, lassen Sie ihn unverändert und setzen Sie „Socket buffer (bytes)“ nur an den Eingängen, die ihn tatsächlich benötigen. Als Richtwert für die Berechnung dient die Bitrate des Streams multipliziert mit der zulässigen Pause bei der Bedienung des Sockets: 8 MB decken etwa 64 ms bei 1 Gbit/s ab.

Flussonic und SRT

Beispiel einer SRT-URL für den Empfang durch die Software Flussonic:

srt://Stream_IP:port?streamid=flussonic

Dabei ist streamid der Login des Clients in der Software Flussonic, der im Abschnitt „Konfiguration — Peer-Einrichtung“ festgelegt wird.

Beim Hinzufügen eines neuen Clients genügt es, nur den Login anzugeben; in der Test-URL ist „flussonic“ angegeben. Die Software Flussonic erzeugt beim Betrieb mit SRT automatisch eine streamID, und wenn in der URL auf der Empfangsseite der Login streamID nicht angegeben wird, wird der Stream nicht empfangen und Perfect Streamer kann ihn nicht ausliefern.

Auf dieselbe Weise lässt sich die streamID im Format aus Login und Passwort festlegen: Legen Sie in Perfect Streamer ein Konto an, dessen Feld „Login“ gleich !#::u=1234567890,password=1234567890 ist, und tragen Sie in Flussonic die folgende URL ein:

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

Die streamID lässt sich bei Perfect Streamer auch im Format einer IP-Adresse angeben — dazu wird beim Konto das Merkmal „IP-Adress-Konto“ aktiviert und in das Adressfeld eingetragen:

  • 192.168.1.1 — eine einzelne IP;

  • 192.168.1.1-192.168.1.254 — ein IP-Bereich.

In beiden Fällen sieht die URL für den Empfang über IP in Flussonic so aus: srt://Stream_IP:port?streamid=*

Der Stream wird an die IP-Adresse des Clients gebunden: Der Empfang über diese URL ist nur von der angegebenen IP-Adresse (oder aus dem angegebenen Bereich) aus möglich.