Kurzantwort: Wählen Sie das Protokoll, das die empfangende Seite tatsächlich akzeptieren kann. SRT ist eine Contribution-Option, wenn beide Enden es unterstützen und der Weg konfiguriert ist; RTMP bleibt eine verbreitete Übergabe von Encoder zu Plattform oder Ingest-Server. Zuschauer-Wiedergabe und Auslieferung bleiben separat konfigurierte nachgelagerte Aufgaben.
Mit dem Empfänger beginnen, dann die Übergabe wählen
| Entscheidungspunkt | SRT-Weg | RTMP-Weg |
|---|---|---|
| Empfänger | Ein SRT-fähiger Contribution-Empfänger, den Sie kontrollieren oder der Ihnen zugewiesen wurde | Ein RTMP-Ingest-Endpunkt oder eine für Publishing bereitgestellte Plattform-URL |
| Transport | UDP-basierte SRT-Sitzung; der Live-Modus enthält Zeit- und Neuübertragungssteuerungen | TCP-basierte RTMP-Sitzung zum konfigurierten Endpunkt |
| Netzwerkfrage | Können sich die Peers erreichen, und stimmen Modus, Latenz und Passphrase überein? | Erreicht der Encoder den Host, und entsprechen URL/Key dem Endpunktvertrag? |
| Codec-Frage | Akzeptierten Container und Codecs des Empfängers getrennt prüfen | Akzeptiertes Audio-/Video-Profil des Ziels getrennt prüfen |
| Nützliche nächste Aufgabe | Contribution in einen Betriebs- oder Produktionsworkflow | Publishing zu einem Ingest-Service oder konfigurierten RTMP Server |
Drei häufige Entscheidungen
- Die Plattform liefert nur URL und Stream-Key: Publizieren Sie RTMP mit diesem Vertrag.
- Ihr Team kontrolliert einen SRT-Empfänger: Verwenden Sie SRT, wenn Modus, Host:Port, Latenz und eine eventuelle Stream ID/Passphrase auf beiden Seiten vereinbart sind.
- Die SRT-Contribution endet an einer RTMP/RTMPS-Plattform: Prüfen Sie SRT-Contribution und die Plattform-Publishing-Übergabe getrennt.
Der SRT-Live-Modus basiert auf einem konfigurierten Latenzfenster und Empfänger-Feedback; ein größeres Fenster kann mehr Zeit für Wiederherstellung geben, bleibt aber eine Deployment-Entscheidung und kein Versprechen eines besseren Bildes. RTMP-Kompatibilität ist ebenso endpunktspezifisch. Eine Plattform, die eine RTMP- oder RTMPS-URL verlangt, bestimmt die finale Übergabe, auch wenn ein anderer Contribution-Abschnitt SRT verwendet.
Was sich operativ ändert
| Vor der ersten Verbindung | Dokumentieren |
|---|---|
| SRT | Caller-/Listener-/Rendezvous-Modus; Host:Port; Latenz; bei Verwendung Stream ID oder Passphrase; Container sowie Video-/Audio-Codecs. |
| RTMP | Vollständige Ingest-URL, Anwendung/Pfad und Key; das vom Empfänger deklarierte Profil, oft H.264/AAC, sofern der Endpunkt dies verlangt; sowie dessen Stream-Health-Check. |
Halten Sie Zugangsdaten aus Screenshots, Chat-Protokollen und Testaufzeichnungen heraus.
SRT-Verschlüsselung und RTMPS beantworten unterschiedliche Transportsicherheitsfragen: SRT kann mit Verschlüsselung konfiguriert werden, während RTMPS RTMP über TLS transportiert. Ein RTMPS-Ziel beschreibt nicht die Ingest-Optionen eines separaten RTMP Server.
Einen Contribution-Weg testen
Verwenden Sie für beide Tabs dieselbe vorbereitete Quelle: Programmformat festlegen, Video- und Audio-Codec-Einstellungen notieren und dem Publisher Zugriff auf den gewählten Testendpunkt geben. Starten Sie eine Protokollsitzung, bestätigen Sie den Publisher-Status, prüfen Sie die Vorschau und verifizieren Sie anschließend die nachgelagerte Ausgabe, falls der Workflow sie nutzt.
PROTOKOLL-DEMOS
Ein zu testendes Protokoll wählen
Jede Demo wird manuell gestartet und behält ihre eigene temporäre Laufzeit. Verwenden Sie beim Vergleich von Workflows übereinstimmende Quelleinstellungen; diese Seite führt keinen kontrollierten Latenz-Benchmark aus.
Live-SRT-Demo
Live-SRT-Verbindung testen
Erstellen Sie eine temporäre Verbindung für eine Stunde. Senden Sie Ihren Feed im Caller-Modus an die Publisher-Adresse, mit leerer Stream-ID. Sehen Sie ihn unten in Multiview an oder verbinden Sie Ihren Receiver im Caller-Modus mit der Receiver-Adresse.
Das Ergebnis bestätigt, dass die gewählte Quelle diesen temporären Weg und seine Vorschau erreicht hat. Es ist eine Einrichtungsprüfung, kein Vergleichsbenchmark; es stuft daher Latenz, Qualität oder Zuverlässigkeit nicht ein. Wiederholen Sie eine geänderte Konfiguration als neuen Test und bewahren Sie Empfängerprotokolle oder für Operatoren sichtbare Verbindungsdaten auf.
Wo Callaba passt
Callabas RTMP Server kann Publishern und Empfängern getrennte Zugriffsregeln geben und für Operatoren sichtbare Aktivität anzeigen. Ein Guest RTMP Server kann stattdessen ohne vordefinierte Zugriffsregeln offen sein. Sein SRT Server ist die entsprechende Contribution-Ressource für einen kompatiblen SRT-Workflow. Browser-Beobachtung und Zuschauer-Wiedergabe verwenden separat konfigurierte Module; eine RTMP-Publish-URL ist keine im Browser abspielbare URL.
Nächste Schritte
- Für einen konfigurierten RTMP-Listener lesen Sie RTMP Server und dessen Zugriffs-/Lebenszyklussteuerungen.
- Für einen SRT-Contribution-Empfänger lesen Sie SRT Server.
- Für eine explizite Brücke verwenden Sie den dokumentierten Weg RTMP-Contribution-Gateway erst nach Bestätigung beider Endpunkte.
