RTMP, SRT oder WHIP: das richtige Ingest-Protokoll wählen

Vor dem Vergleich: Der Fehler, der viele ihre erste Stunde kostet, steckt in der SRT-URL – und er erzeugt keine Fehlermeldung. Lesen Sie den nächsten Abschnitt, selbst wenn Sie alles andere überspringen.

Der Fehler, bei dem scheinbar nichts passiert

Eine SRT-Ingest-URL enthält eine streamid, die so aussieht: #!::r=live/sk_srt_…,m=publish. Genau diese Zeichen – #, !, :, , – kodiert ein sorgfältiger Mensch aus Gewohnheit per Prozent-Encoding. Tun Sie das nicht. Die SRT-Bibliothek dekodiert die streamid nicht; sie leitet die Bytes wörtlich an den Server weiter. Eine kodierte streamid kommt deshalb als Stream-Name an, der mit %23 beginnt, der Server behandelt die Verbindung als Wiedergabe- statt als Publish-Anfrage, und Ihnen wird nichts gemeldet. Ihr Encoder zeigt eine gesunde Verbindung. Die Stream-Karte zeigt kein Signal. Nirgends gibt es einen Fehler.

Fügen Sie die SRT-URL genau so ein, wie die API sie zurückgibt. dcast liefert sie in ihrer wörtlichen, sendefähigen Form unter data.ingest.srt bei GET /api/v1/streams/:id und denselben Wert unter data.ingest.srtDisplay, das nur als Alias für ältere Integrationen existiert. Beide gehören ohne jede Umschreibung direkt in Ihren Encoder.

Was dcast annimmt

Eine Stream-Karte lässt sich über jeden dieser Wege speisen. Sie entscheiden pro Karte, und die Wahl ändert nichts an dem Bild, das Ihre Zuschauer bekommen.

Der Hostname ist immer a.dcast.pro – der Einstiegspunkt des Routing-Pools, nie der Name eines einzelnen Servers. Das ist Absicht: So funktioniert die Adresse, die Sie einmal eingerichtet haben, weiter, wenn der Stream auf einer anderen Maschine landet.

RTMP: das, was immer funktioniert

RTMP ist alt, und genau darin liegt sein ganzer Vorteil. Jeder Encoder, jede Kamera mit Streaming-Modus, jede Handy-App und jedes Gerät, das man Ihnen vor Ort in die Hand drückt, kann RTMP senden – ohne weitere Konfiguration als einen Server und einen Schlüssel. Wenn Sie aus einem stabilen Netz streamen und kein konkretes Problem lösen müssen, ist RTMP die richtige Wahl, und Sie können hier aufhören zu lesen.

Seine Schwäche zeigt sich, wenn das Netz nicht stabil ist. RTMP läuft über TCP, und TCP begegnet Verlusten, indem es neu sendet und wartet. Auf einer guten Leitung merkt man davon nichts. Auf einer Leitung mit echtem Paketverlust schon: Der Stream baut Latenz auf, die er nie wieder abgibt, oder er bleibt hängen, und wie er sich erholt, reicht je nach Encoder von elegant bis zum Verbindungsabbruch.

Wenn Ihr Encoder Server und Schlüssel getrennt haben will, teilen Sie die URL am letzten Schrägstrich: Server rtmp://a.dcast.pro/live, Schlüssel sk_rtmp_…. (Stream-Schlüssel tragen als Präfix das Protokoll, für das die Karte angelegt wurde – sk_rtmp_, sk_srt_, sk_webrtc_ –, der eingefügte Schlüssel sollte also zu der Tür passen, an die Sie klopfen.)

SRT: das für schlechte Netze

SRT gibt es für den Fall, mit dem RTMP schlecht zurechtkommt: eine Leitung mit Paketverlust, die Sie nicht reparieren können – in der Praxis Mobilfunknetze, öffentliches WLAN am Veranstaltungsort und alles, was eine große Entfernung überbrückt.

Die Idee ist ein festes Latenzbudget. Statt so lange neu zu senden, bis das Paket ankommt, egal wie lange das dauert, hält SRT einen Puffer gewählter Größe vor und fordert verlorene Pakete nur so lange nach, wie noch Zeit bleibt, sie an die richtige Stelle zu setzen. Pakete, die es nicht rechtzeitig schaffen, werden verworfen, statt alles dahinter aufzuhalten. Das Ergebnis ist ein Stream mit vorhersehbarer Verzögerung und sanfter Verschlechterung bei Verlusten statt unvorhersehbarer Verzögerung und Hängern.

Dieser Puffer ist der Parameter latency, angegeben in Millisekunden. Die URLs, die dcast ausgibt, enthalten 500 ms, und Sie können den Wert bis auf 7000 erhöhen. Der Tausch ist direkt, eine clevere Einstellung gibt es nicht: Ein größerer Wert übersteht stärkere Verluste und fügt genau so viel Verzögerung hinzu. Verliert Ihr Stream Pakete, erhöhen Sie ihn.

Ihn unter 500 zu senken ist das Einzige, was nicht funktioniert, und es lohnt sich, den Grund zu kennen, statt ihn selbst herauszufinden. Unser Ingest deklariert selbst 500 ms, und eine SRT-Verbindung einigt sich auf den größeren der beiden Werte – ein Encoder, der 80 ms verlangt, bekommt also trotzdem 500. Die Zahl ist eine Untergrenze, nicht nur ein Standardwert.

Zwei weitere SRT-Einstellungen sollten Sie kennen. Modus – dcast gibt caller-URLs aus, das heißt, Ihr Encoder baut die Verbindung nach außen auf; das funktioniert hinter einem Router ohne Portweiterleitung. listener und rendezvous gibt es für Setups, die sie brauchen. Und Passphrase – SRT kann die Leitung verschlüsseln; wenn Sie eine setzen, muss sie mindestens zehn Zeichen lang sein.

WHIP: das aus dem Browser

WHIP ist der Weg, über den eine WebRTC-Quelle sendet. Statt einer Stream-URL schicken Sie ein SDP-Offer an einen HTTPS-Endpunkt, und eine Peer-Verbindung wird aufgebaut. dcast gibt diesen Endpunkt zusammen mit den anderen auf der Stream-Karte zurück.

Nutzen Sie es, wenn Ihre Quelle ein Browser ist – ein Gast, der nichts installiert hat, eine webbasierte Bedienoberfläche, eine Bildschirmfreigabe – oder wenn Sie eine geringere Zuspiel-Latenz brauchen, als ein segmentierter Weg bieten kann. Encoder mit WHIP-Unterstützung bieten es als Streaming-Dienst an, in den Sie die zurückgegebene URL unverändert einfügen; ein separates Feld für den Stream-Schlüssel gibt es nicht, weil der Schlüssel schon in der URL steckt.

Seine Einschränkung: WebRTC ist anspruchsvoller im Betrieb als ein TCP-Push. Es reagiert empfindlicher auf restriktive Netze und wird von Hardware-Encodern weniger flächendeckend unterstützt als RTMP.

Die Protokollwahl ändert Ihr Bild nicht

Dieser Teil erspart vielen eine Menge Tests. Egal über welches Protokoll Ihr Stream ankommt, er wird vor allem anderen in eine einheitliche interne Form gebracht, und die Encoding-Leiter, die danach läuft, ist identisch. Dieselben Stufen, dieselben Bitraten-Obergrenzen, dasselbe Keyframe-Intervall von 2 Sekunden, dieselben 4-Sekunden-Segmente mit je zwei Keyframes.

Das heißt: Ein SRT-Stream und ein RTMP-Stream mit derselben Quelle und derselben Bitrate ergeben dasselbe Ergebnis. SRT verschafft Ihnen kein besseres Bild, und RTMP kostet Sie keins. Entscheiden Sie danach, wie sich Ihr Netz verhält – das ist das Einzige, worauf die Wahl tatsächlich Einfluss hat.

Auch die Bildrate legen wir auf unserer Seite fest, nicht das Protokoll, und zwar für alle drei gleich: Zum Zeitpunkt des Schreibens wird die Live-Leiter mit 30 fps kodiert, egal was Sie senden.

Bauen Sie die Ingest-URL nicht von Hand

Jede Ingest-Adresse, die dcast Ihnen gibt, stellt die API für eine bestimmte Stream-Karte aus, und jeder ihrer Bestandteile hat eine Aufgabe. GET /api/v1/streams/:id liefert sie alle zusammen unter data.ingest, und der richtige Ablauf ist, sie jedes Mal von dort zu kopieren, statt eine URL in einem Dokument aufzubewahren und darin den Schlüssel zu ändern.

Der Hostname ist der Einstiegspunkt des Pools und kein Maschinenname, er bleibt also gültig, auch wenn Ihr Stream nächste Woche von woanders ausgeliefert wird. Der Schlüssel identifiziert Ihre Karte. Bei SRT trägt die streamid zusätzlich den Modus – m=publish macht die Verbindung zu einem Publish statt zu einer Wiedergabe –, und genau deshalb ist der Kodierungsfehler vom Anfang dieses Artikels so leise: Wer die streamid beschädigt, schickt keine fehlerhafte Anfrage, sondern eine völlig gültige Anfrage, einen Stream anzusehen, den es nicht gibt.

Zwei Gewohnheiten verhindern fast alles davon. Kopieren Sie die ganze URL, einschließlich allem nach dem ?, in einem Zug. Und wenn ein Encoder auf getrennten Feldern für Server und Schlüssel besteht, teilen Sie am letzten Schrägstrich und fügen beide Hälften ein, statt eine davon abzutippen.

Wenn Sie integrieren statt von Hand zu konfigurieren, fragen Sie die Ingest-Ziele erst im Moment der Nutzung ab, statt sie zu cachen – aus demselben Grund: Der Wert, den Sie bekommen, ist jetzt korrekt, und erneut zu fragen kostet wenig.

Die Leitung verschlüsseln

SRT kann den Stream zwischen Ihrem Encoder und uns mit einer Passphrase verschlüsseln. Das lohnt sich immer dann, wenn die Leitung durch ein Netz läuft, das Sie nicht kontrollieren – das Gäste-WLAN eines Veranstaltungsorts, ein Hotel, ein geteilter Uplink auf einer Konferenz –, denn in solchen Netzen ist das Zuspielsignal das Einzige, was Sie wirklich nicht wiederholen können, wenn sich jemand daran zu schaffen macht.

Die Passphrase muss mindestens zehn Zeichen lang sein. Setzen Sie auf beiden Seiten denselben Wert; bei einer Abweichung scheitert der Handshake, statt sich zu verschlechtern – und genau das wollen Sie, denn ein stiller Rückfall auf eine unverschlüsselte Verbindung wäre schlimmer als eine Ablehnung.

Verschlüsselung kostet an jedem Ende ein wenig Rechenleistung und nichts an Bildqualität. Wenn Sie SRT ohnehin nutzen, weil das Netz nicht vertrauenswürdig ist, gilt dieselbe Überlegung meist auch für die Frage, ob es mitlesbar sein sollte.

Die Wahl in einem Absatz

Ist Ihr Netz eine kabelgebundene Verbindung in einem Gebäude, das Sie kontrollieren, nehmen Sie RTMP. Sind Sie im Mobilfunknetz, im WLAN eines Veranstaltungsorts oder senden Sie über einen Kontinent hinweg, nehmen Sie SRT und erhöhen die Latenz, bis der Stream sauber ist. Ist Ihre Quelle ein Webbrowser, nehmen Sie WHIP. Existiert der Inhalt bereits als Stream anderswo, nehmen Sie HTTP-Pull und lassen ihn von uns abholen, statt ihn von Hand weiterzustreamen. Diese vier Sätze decken fast jeden realen Fall ab.

Den Ingest vor dem Event testen

Testen Sie mit der echten URL von der echten Stream-Karte, nicht mit einer selbst zusammengesetzten. Die meisten Fehler beim ersten Mal sind eine handgebaute Adresse.

Testen Sie vom echten Veranstaltungsort aus, über die echte Verbindung und – wenn dort viel los ist – zur echten Tageszeit. Ein Netz, das um neun Uhr morgens sauber läuft und um sieben Uhr abends überlastet ist, ist der Normalfall, nicht die Ausnahme.

Speziell bei SRT beobachten Sie während des Tests die Verlust- und Retransmission-Zähler Ihres Encoders statt des Bildes. Das Bild sieht gut aus, bis das Latenzbudget aufgebraucht ist – die Zähler warnen Sie also, das Bild nicht.

Und prüfen Sie, dass die Stream-Karte ein Signal zeigt, nicht nur, dass Ihr Encoder verbunden ist. Das sind zwei verschiedene Aussagen, und der streamid-Fehler bei SRT vom Anfang dieses Artikels ist genau der Fall, in dem die erste wahr und die zweite falsch ist.