Callaba SRT Server

Was ist ein SRT-Server?

Ein SRT-Server ist der Endpunkt, der SRT-Verbindungen annimmt oder verwaltet. Er kann einen Live-SRT-Stream von einem Encoder empfangen, an ein anderes System weiterleiten oder als kontrollierter Übergabepunkt zwischen einer entfernten Quelle und einer Produktionsplattform dienen.

In einem typischen Live-Workflow erfüllt der SRT-Server vier praktische Aufgaben:

• Livefeed empfangen: Ein Kamera-Encoder, OBS, vMix, FFmpeg, Larix oder eine andere Quelle sendet Video an den Server.
• Contribution-Pfad schützen: SRT kann verlorene Pakete wiederherstellen und die Transportsitzung verschlüsseln.
• Live-Statistiken bereitstellen: Operatoren überwachen Bitrate, RTT, Paketverlust, Neuübertragungen und Verbindungsstatus.
• Stream nachgelagert übergeben: Der Server routet den Feed in Aufzeichnung, Transcoding, Restreaming, Umschaltung oder Wiedergabe.

Damit bildet der SRT-Server die Grenze zwischen Quell- und Plattformseite. Wenn ein Remote-Team sagt, es sende, prüfen Sie dort, ob das Signal wirklich ankommt, stabil ist und nachgelagert verwendet werden kann.

SRT-Server und SRT-Protokoll im Vergleich

Das SRT-Protokoll ist die Transportmethode. Der SRT-Server ist der System- oder Softwareendpunkt, der dieses Protokoll zum Empfangen oder Senden von Livestreams verwendet.

Was ist ein SRT-Liveserver?

Ein SRT-Liveserver ist ein SRT-Server für Live-Video-Contribution in Echtzeit oder nahezu Echtzeit. Er empfängt den Stream während der Veranstaltung und leitet ihn an Live-Produktion, Aufzeichnung oder Verteilung weiter.

Teams verwenden SRT-Liveserver für Remote-Event-Contribution, Cloud-Ingest von Kameras und Encodern, Studio-zu-Cloud-Transport, Partnerübergaben, Backup-Pfade, Remote-Produktion und Restreaming an mehrere Ziele.

Das Wort „live“ ist wichtig, weil SRT anders als Dateiübertragung abgestimmt wird. Der Server muss Verzögerung und Wiederherstellung ausbalancieren. Ist die Latenz für den echten Netzwerkpfad zu klein, kann der Stream trotz Verbindung bei Paketverlust oder Jitter abbrechen.

So funktioniert ein SRT-Server

Ein SRT-Server empfängt codiertes Audio und Video über eine SRT-Verbindung. Die Medien sind bereits vor dem Transport codiert. Häufig trägt SRT einen gemuxten MPEG-TS-Stream; der genaue Container hängt von Sender und Workflow ab. Typisch sind H.264 oder H.265/HEVC, AAC-Audio und gelegentlich Metadaten.

1. Ein Encoder erzeugt den Live-Audio- und Videostream.
2. Der Encoder sendet den Stream an einen SRT-Server.
3. Der SRT-Server empfängt den Stream und überwacht den Verbindungszustand.
4. Bei Paketverlust kann SRT eine Neuübertragung anfordern, solange die Pakete noch nutzbar sind.
5. Der Server übergibt den Stream an den nächsten Schritt: Recorder, Transcoder, Restream, Switcher, API-Workflow oder Wiedergabesystem.

Caller-, Listener- und Rendezvous-Modi

SRT besitzt drei Verbindungsmodi. Der Modus bestimmt, welche Seite die Verbindung beginnt und wie die Sitzung Firewalls und NAT passiert.

• Listener: wartet auf eine eingehende SRT-Verbindung an einem bekannten UDP-Port. Das ist der typische Modus für Cloud-Ingest-Server oder Rechenzentrumsendpunkte.
• Caller: startet die Verbindung zu einem Listener. Üblich für Feld-Encoder, OBS, vMix, FFmpeg, mobile Apps und Remote-Quellen.
• Rendezvous: beide Seiten initiieren die Verbindung. Das kann in manchen NAT-Fällen helfen, muss aber vor der Produktion sorgfältig getestet werden.

SRT-Server-Ports und Firewall-Regeln

SRT verwendet UDP. Deshalb muss der richtige UDP-Port in Cloud-Sicherheitsgruppe, Host-Firewall, Router oder Netzwerkrichtlinie geöffnet sein.

• Der Server hat eine öffentliche IP oder erreichbare Netzwerkadresse;
• der richtige UDP-Port ist geöffnet;
• der Encoder verwendet den richtigen Caller-/Listener-Modus;
• die Stream-ID entspricht der Routing-Regel, sofern verwendet;
• die Passphrase stimmt auf beiden Seiten überein, sofern Verschlüsselung aktiv ist;
• der empfangende Workflow ist der richtigen nachgelagerten Ausgabe zugeordnet.

Ein häufiger Fehler ist, nur die Anzeige „verbunden“ am Encoder zu prüfen. Eine Verbindung reicht nicht: Medien müssen ankommen, die Bitrate muss stabil sein und das nachgelagerte System muss den Stream verwenden können.

Beispiel für die SRT-Server-Einrichtung

Dies ist eine praktische Konfiguration für den ersten Test. Ersetzen Sie Host, Port, Stream-ID und Passphrase durch Ihre eigenen Werte.

Server side:
mode: listener
UDP port: 10080
latency: 200 ms
stream ID: event-main
passphrase: optional, same on both sides

Sender side:
srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=event-main

Rolle von SRT-Servern in Live-Streaming-Workflows

SRT ist meist auf der Contribution-Seite am stärksten, auf der der Livefeed von der Quelle zur Plattform gelangt.

Kamera oder Encoder → SRT-Server → Transcoder / Recorder / Restream / Player-Workflow

Nach dem Empfang kann die Plattform den Stream für Restreaming, Aufzeichnung, Transcoding, Wiedergabe, Routing, Failover, API-Workflows oder Produktionsmonitoring vorbereiten.

SRT-Server im Vergleich zu RTMP, HLS, WebRTC und NDI

SRT ersetzt nicht jede Videotechnologie, sondern löst einen bestimmten Teil des Workflows.

Für einen Vergleich auf Protokollebene lesen Sie SRT vs. RTMP.

SRT-Server bereitstellen

Die genaue Einrichtung hängt von Software, Cloud-Anbieter und Workflow ab; die Bereitstellungslogik ist meist gleich.

1. Server oder Cloud-Instanz erstellen mit genügend CPU, Netzwerkkapazität und Speicher für den Workflow.
2. Erforderlichen UDP-Port öffnen in Cloud-Sicherheitsgruppe und Host-Firewall.
3. SRT-Listener erstellen der den eingehenden Stream empfängt.
4. Regeln für Stream-ID und Passphrase festlegen wenn Routing und Verschlüsselung benötigt werden.
5. Encoder verbinden als SRT-Caller und den Stream an den Listener-Endpunkt senden.
6. Live-Statistiken prüfen etwa Bitrate, RTT, Paketverlust, Neuübertragungen und Verbindungsstatus.
7. Stream nachgelagert routen zu Aufzeichnung, Restreaming, Transcoding oder Wiedergabe.

SRT-Server in Callaba verwenden

In Callaba dient ein SRT-Server normalerweise als kontrollierter Ingest-Punkt. Eine entfernte Quelle sendet an Callaba; Callaba stellt den Stream für den nächsten Workflow-Schritt bereit.

Typische Callaba-Workflows:

• SRT-Encoder zu Callaba, danach Restream zu Twitch oder YouTube;
• OBS über SRT zu Callaba, danach Stream aufzeichnen;
• vMix über SRT zu Callaba, danach Feed an ein anderes Ziel routen;
• Mobile App über SRT zu Callaba, danach Restream zu sozialen Plattformen;
• Remote-Veranstaltungsort zu Callaba, danach für Browserwiedergabe paketieren;
• SRT-Eingang zu Browser-Multiview, Recorder, API-Routing und kontrollierter Player-Auslieferung.

SRT-Server überwachen

Eine verbundene SRT-Sitzung bedeutet nicht immer einen gesunden Stream. Überwachen Sie Transport- und Medienzustand.

Transportsignale

• Verbindungsstatus: Verbunden, getrennt, Wiederverbindung oder fehlgeschlagen.
• Eingangsbitrate: ob Medien weiterhin mit der erwarteten Rate fließen.
• RTT: Round-Trip-Zeit zwischen Sender und Empfänger.
• Paketverlust: wie viele Daten auf dem Pfad verloren gehen.
• Neuübertragungen: wie oft SRT fehlende Pakete wiederherstellen muss.
• Jitter: wie stark die Paketzeitpunkte schwanken.
• Druck im Empfangspuffer: ob die Verbindung zu nahe an ihrer Wiederherstellungsgrenze läuft.

Mediensignale

• Schwarzes oder eingefrorenes Video, fehlendes oder stummes Audio;
• falscher Codec, falsche Bildrate, Auflösung oder Audioformat;
• fehlerhafte Zeitstempel, fehlende Keyframes oder inkompatibles Stream-Mapping.

Häufige SRT-Server-Probleme

Die SRT-Verbindung startet nicht

Prüfen Sie Verbindungsmodus, UDP-Port, öffentliche IP, Firewall-Regeln, Stream-ID und Passphrase. Die meisten fehlgeschlagenen SRT-Handshakes entstehen durch falschen Modus, blockiertes UDP, falschen Port oder abweichende Sicherheitseinstellungen.

Der Stream verbindet sich, aber das Video ist instabil

Prüfen Sie RTT, Jitter, Paketverlust, Neuübertragungen und Latenz. Ist die Latenz für den Netzwerkpfad zu knapp, kann SRT verlorene Pakete nicht rechtzeitig wiederherstellen.

Der Stream verbindet sich, aber Audio fehlt

Prüfen Sie zuerst den Encoder: Audioquelle aktiviert, richtiges Gerät gewählt, Audiocodec mit dem nächsten Schritt kompatibel und Audiospur für die Empfangsanwendung lesbar.

Bestätigen Sie vor der SRT-Server-Diagnose, dass Audio an der Quelle vorhanden ist. Nutzen Sie lokales Monitoring in OBS, vMix, am Hardware-Encoder, per Kopfhörer oder Gerätevorschau.

Die SRT-Statistiken sind gut, Zuschauer haben dennoch Probleme

Ist die SRT-Verbindung gesund, aber die Wiedergabe stockt oder zeigt Artefakte, liegt das Problem möglicherweise nachgelagert. Prüfen Sie Transcoding, Packaging, Origin, CDN, Player und Ausgabeformat, bevor Sie den SRT-Server verantwortlich machen.

Self-Hosted oder verwalteter SRT-Server

Sie können einen SRT-Server selbst betreiben oder eine verwaltete Plattform nutzen. Die Wahl hängt davon ab, wie viel operative Kontrolle Ihr Team übernehmen will.

Callaba kann als Cloud- oder Self-Hosted-SRT-Workflow-Plattform eingesetzt werden. Starten Sie es auf AWS oder installieren Sie es auf Ihrem Server, erstellen Sie SRT-Ingest-Punkte und verbinden Sie Streams mit Restreaming, Aufzeichnung, Routing, Browser-Vorschau, Multiview, Player-Auslieferung und API-Workflows.

Checkliste für den Veranstaltungstag

• IP-Adresse oder Hostname des Servers bestätigen.
• Prüfen, ob der UDP-Port geöffnet ist.
• Caller-/Listener-/Rendezvous-Modus auf beiden Seiten bestätigen.
• Stream-ID bestätigen, sofern verwendet.
• Verschlüsselungs-Passphrase bestätigen, sofern verwendet.
• Erwartete Bitrate, Codec, Bildrate, Auflösung und Audioformat bestätigen.
• Stream starten und Eingangsbitrate prüfen.
• RTT, Paketverlust, Neuübertragungen und Jitter prüfen.
• Tatsächliches Video und Audio prüfen, nicht nur den Verbindungsstatus.
• Nachgelagerte Route bestätigen: Aufzeichnung, Restreaming, Transcoding oder Wiedergabe.
• Zeitsynchronisierung bestätigen: Server und Encoder sollten NTP oder eine konsistente Zeitquelle verwenden, damit Logs und Aufzeichnungen bei der Diagnose korreliert werden können.
• Backup-Pfad vor Veranstaltungsbeginn testen.

Offizielle Quellen und weiterführende Inhalte

Verwenden Sie diese Quellen für SRT-Details auf Protokollebene, Callaba-Einrichtung oder verwandte Workflow-Anleitungen.

• SRT-Protokollentwurf
• Haivision-Dokumentation zu SRT Live Transmit
• Was ist das SRT-Protokoll?
• SRT-Streaming in OBS Studio starten
• SRT-Stream in OBS Studio empfangen
• SRT-Stream mit vMix senden und empfangen
• Die richtige Latenz für Ihre SRT-Konfiguration finden
• API-Dokumentation für SRT-Server

FAQ

Was ist ein SRT-Server?

Ein SRT-Server ist ein Live-Video-Ingest- oder Relay-Endpunkt, der SRT-Streams empfängt, sendet oder routet. Er transportiert Livefeeds von Encodern, Kameras, entfernten Veranstaltungsorten, Studios, Mobilgeräten oder Partnersystemen in einen kontrollierten Medienworkflow.

Was ist ein SRT-Liveserver?

Ein SRT-Liveserver dient der Live-Video-Contribution in Echtzeit. Er empfängt das Video während der Veranstaltung und übergibt es an Aufzeichnung, Restreaming, Transcoding, Umschaltung, Routing oder Wiedergabe.

Ist ein SRT-Server dasselbe wie ein Streamingserver?

Nicht immer. Ein SRT-Server übernimmt meist Live-Ingest oder Transport zwischen kontrollierten Endpunkten. Eine vollständige Streamingplattform kann außerdem Transcoding, Aufzeichnung, Zuschauerwiedergabe, Analytics, Zugriffskontrolle, API-Workflows und CDN-Auslieferung übernehmen.

Verwendet ein SRT-Server UDP?

Ja. SRT läuft über UDP. Deshalb muss der richtige UDP-Port in Server-Firewall, Cloud-Sicherheitsgruppe, Router oder Netzwerkrichtlinie geöffnet sein.

Welchen Port verwendet ein SRT-Server?

SRT erfordert keinen universellen festen Port. Der Port wird in der Serverkonfiguration festgelegt. In der Produktion reservieren Teams einen klaren UDP-Port oder Portbereich für SRT-Ingest und dokumentieren, welche Feeds, Mandanten oder Veranstaltungen ihn verwenden.

Soll der SRT-Server Listener oder Caller sein?

Für die meisten Cloud-Ingest-Workflows ist der SRT-Server Listener und der Encoder Caller. Das funktioniert gut mit öffentlicher IP oder DNS, bekanntem UDP-Port und klaren Firewall-Regeln.

Kann OBS an einen SRT-Server senden?

Ja. Mit einer SRT-Ausgabe-URL kann OBS Video an einen SRT-Server senden. Der Server empfängt und routet den Stream zu Aufzeichnung, Restreaming, Transcoding oder Wiedergabe.

Kann vMix an einen SRT-Server senden?

Ja. vMix unterstützt SRT und kann Streams senden oder empfangen. Häufig sendet vMix SRT an Callaba, während Callaba Monitoring, Routing, Aufzeichnung oder Restreaming übernimmt.

Ist SRT besser als RTMP?

Für Contribution über instabile, verlustbehaftete oder lange Netzwerkpfade ist SRT meist besser als RTMP. RTMP bleibt für einfaches Publishing und Plattform-Ingest verbreitet. Viele Workflows nutzen SRT für Contribution und RTMP/RTMPS für die finale Auslieferung an soziale Plattformen.

Können Browser SRT direkt abspielen?

In normalen Web-Workflows spielen Browser SRT nicht direkt ab. Ein SRT-Server empfängt zuerst den Stream; die Plattform konvertiert oder paketiert ihn anschließend in ein Zuschauerformat wie HLS oder WebRTC.

Warum verbindet sich mein SRT-Stream, zeigt aber kein Video?

Die SRT-Transportverbindung kann funktionieren, obwohl die Mediennutzlast fehlerhaft ist. Prüfen Sie Codec, Container, Zeitstempel, Keyframes, Audiospuren, Stream-Mapping, nachgelagerte Kompatibilität und ob tatsächlich Bitrate am Server ankommt.

Wie erhöhe ich die Zuverlässigkeit eines SRT-Servers?

Verwenden Sie einen stabilen Server, öffnen Sie die richtigen UDP-Ports, wählen Sie realistische Latenz, überwachen Sie RTT und Neuübertragungen, halten Sie Bandbreitenreserve vor, prüfen Sie die Mediennutzlast und testen Sie vor der Veranstaltung einen Backup-Endpunkt.

Transportiert SRT normalerweise MPEG-TS?

In Live-Video-Workflows trägt SRT häufig MPEG-TS mit gemuxtem Audio und Video. Der genaue Container hängt von Sender und Workflow ab. Der Server sollte die Nutzlast prüfen, nicht nur die SRT-Verbindung.

Welche SRT-Server-Kennzahlen sollte ich zuerst beobachten?

Beginnen Sie mit Eingangsbitrate, RTT, Paketverlust, Neuübertragungen und Verbindungsstatus. Unter guten Bedingungen liegt RTT oft bei 20–60 ms. Bei dauerhaft über 150 ms oder mehr als 1–2 % Paketverlust erhöhen Sie die Latenz, senken die Bitrate oder verbessern den Netzwerkpfad.

Nächste Schritte

• Was ist das SRT-Protokoll?
• SRT vs. RTMP
• SRT-Streaming in OBS Studio starten
• SRT-Stream in OBS Studio empfangen
• SRT-Stream mit vMix senden und empfangen
• Die richtige Latenz für Ihre SRT-Konfiguration finden
• API-Dokumentation für SRT-Server

Zuletzt aktualisiert: 22. Juli 2026