Kurz wach, lange schlafen, abends dann etwas Arbeit. Static IP für den HP und bei der Gelegenheit DNS over HTTPS, weil ich lokal das Restreaming testen wollte.
Auf Snipz sah ich den TP-Link M7350 im notebooksbilliger im Angebot – nur €49,90 + Versand. War dort aber schon ausverkauft. Das Teil schafft nur bis 10 Nutzer, hat ein Display, sogar einen 32GB SD-Kartenslot zum sharen und auch ein paar Github Projekte zum Abfassen der Verbindungsdaten. Es wird sicher das MiFi-Gerät der Wahl, nur eben derzeit eher €70 statt vorgestern €50. Da muss ich warten.
Für lokale RTMP tests, startete ich mit dem rtsp-simple-server unter Windows, dein ich erst gestern fand. Der kann auch direkt ffmpeg ansprechen. Per tee muxer gänge (hoffentlich) die Weiterleitung an diverse Dienste. Ich will ja nur YouTube und Twitch. Ein Windows Binary gab’s auch, damit spare ich mir Docker in WSL2 mit den ganzen Standardlösungen (nginx) zum Test.
Es gab zunächst Fehler closed (DTS is greater than PTS), wenn man per OBS QSV mehr als 0 B-frames hatte. Ansonsten ging das Teil doch, wenn auch mit einigen Drops. Obwohl einige Bug als gefixt angezeigt wurde, sah ich diese bei mir. Ich probierte die redirection, was inzwischen anders funktioniert. Am Ende ging’s mit:
restream:
runOnReady: ffmpeg -re -i rtmp://localhost/restream -c copy -f flv rtmp://ber.contribute.live-video.net/app/live_...
runOnReadyRestart: yes
Das Problem war die CPU-Auslastung. Mein i5-1135G7 lief mit dem Server auf 30-50% Auslastung, was einfach zu viel ist und niemals auf der VM gänge. Eine Menge dropped frames und fehlende Keyframes im lokalen Netz?! Mit B-Frames ging gleich gar nichts. Das Teil funktionierte zwar besser mit der Osmo Action aber brauchte noch immer um die 30% CPU bei 0% ffmpeg wegen pass-through. Hier hakt irgendwas, wobei ich schon alle anderen Protokolle (WebRTC, RTSP, …) ausgeschaltet habe. Wenn’s um Performance geht, müsste ich doch das nginx flv oder rtmp Modul nehmen.
Somit also zum online Test auf einer netcup VM.
Dafür installierte ich das SSH Plugin in TotalCommander, dann fix meine Config rüberkopiert, ffmpeg auf der VM installiert und alles gestartet. Und siehe da: auf der VM lief das alles mit 2-5% CPU Auslastung, wie erwartet. Es wird ja nichts am Stream verändert. Echt cool – ich kann also von der Osmo Action auf meinen Server und von da auf Twitch. Jetzt noch der zweite Output auf YouTube und gut ist. Warum Windows so viel Performance verballert, ist am Ende auch egal, weil ich ja über einen Server restreame. Nicht schlecht, Herr Specht.
Da könnte ich auch noch einen ffmpeg loop stream für fallbacks laufen lassen. Die config-Datei vom rtsp-simple-server hat hot reload für configs, womit man alternative Streams je nach Lage versetzen könnte. super wäre noch ein Serverseitiges GPS overlay. Die Möglichkeiten sind ganz gut aber erst mal Twitch/YouTube Dual hinbekommen. Etwas Sicherheit brauche ich auch – wohl eine lange Path-URL erst mal. Tee muxer scheint instabil mit mehreren RTMP streams. Mit dem tee muxer bekam ich es auf Anhieb nicht hin, also nahm ich einfach zwei -f flv outputs mit den entsprechenden Addressen / Keys und siehe da: es klappte. Twitch und YouTube zugleich mit ca. 15-20% CPU Auslastung. Das Problem war, dass YouTube zu wenig Bitrate bekam. Noch einmal tee muxer und dann ging’s.
runOnReady: ffmpeg -hide_banner -loglevel error -re -i rtmp://localhost/restream -strict experimental -c copy -f tee -map 0:v -map 0:a "[f=flv:onfail=ignore]rtmp://ber.contribute.live-video.net/app/live_...|[f=flv:onfail=ignore]rtmp://a.rtmp.youtube.com/live2/..."
Wenn ich in YouTube den Stream beende, läuft ffmpeg weiter
Nachts dann wieder sortierte ich Papier und Spittel. Es hat sich viel angesammelt.
0 Responses to “Nun doch Restreaming”