Umwandlung RTSP zu WebRTC - Ideen / Unterstützung gesucht

[DS_Starter]

Guten Morgen,

ich habe mal eine Frage in die Runde die nicht _direkt_ etwas mit FHEM zu tun hat.

Zur Zeit suche ich nach einer praktikablen Möglichkeit, RTSP-Streams welche die Synology Surveillance Station für die integrierten Cams anbietet (Modul SSCam), in WebRTC umzuwandeln um diese umgewandelten Streams in FHEM einzubinden.
Ich habe schon etliche Möglichkeiten geschaffen und beschrieben, z.B. RTSP zu HLS bzw. RTSP zu MJPEG. Diese Streams werden dann mit den spezifischen SSCamSTRM-Devices angezeigt. Aber jede dieser Möglichkeiten hat Stärken und Schwächen, WebRTC scheint mir da ideal zu sein.

Bezüglich WebRTC-Integration bin ich aber noch nicht wirklich vorangekommen. Etwas gelesen habe ich zu Janus Gateway, Kurento und Ant Media Server. Den letzteren will ich mir noch genauer anschauen.

Bevor ich mich total verrenne und es vllt. bessere Möglichkeiten gibt die ich nur nicht sehe mal die Frage in die Runde ob sich bereits jemand mit diesem Thema beschäftigt hat. Eventuell hat jemand sogar schon eine Lösung für sich aufgebaut die ich adaptieren könnte.

Es ist also quasi eine Ideen- und Anregungssuche für die Umwandlung von RTSP in WebRTC und die Integration in SSCam/FHEM.

Grüße,
Heiko

[AlpenFlizzer]

Hallo!

Ich beschäftige mich zur Zeit selbst sehr viel damit, weil ich nicht akzeptieren kann, warum ich meinen Full-HD Stream von meiner Überwachungskamera nicht ohne Verzögerung und Qualitätsverlust in meine Smart Home Steuerung einbinden und anzeigen lassen kann.

Ich bin bei meinen Versuchen letztendlich beim Janus Gateway geblieben (Kurento habe ich nie wirklich zum Laufen gebracht und einen anderen WebRTC Streamer fand ich mit 30-40% extra CPU Last pro Stream etwas zu Resourcenhungrig - für Interessierte: https://github.com/mpromonet/webrtc-streamer)

Das Janus Gateway streamt bei mir zwei RTSP/H.264 Streams von einer Billig-China-Cam um 15€ und einer Hikvision HWI-B120H-M in original Qualität und in Echtzeit ohne Probleme an zB Chrome oder Firefox für Windows und Chrome, Lynket Browser (alias Chromer), Brave Browser für Android bei etwa 2% extra CPU Last.

Passend zum Rest meines Setups läuft das Janus Gateway bei mir in einem Docker Container, für Interessierte hab ich eine öffentliche Demo auf Github. Sollte Plug-n-Play sein wenn man 'docker-compose up -d' benutzt. https://github.com/AlpenFlizzer/janus-gateway-docker

Der Container beinhaltet einen abgespeckten JavaScript Client, der es ermöglicht, mit nur einem Funktionsaufruf im HTML Code, einen Janus Stream auf ein Video-Tag zu leiten. (Ich sollte wohl eine vernünftige Anleitung schreiben was zu ändern ist...  ) Falls jemand nur Input für die HTML/JavaScript Umsetzung sucht und schon einen laufenden Janus Server hat.

Nun zu meinem derzeitigen Problem, weil das alles ja zu schön ist um wahr zu sein: Fully Kiosk Browser (nutze ich auf einem Tablet zur Darstellung meiner FTUI) verwendet die Chrome WebView als Render-Engine für Webinhalte. Während die Chrome App für Android Codecs für H.264 beinhaltet, tut dies die bloße Chrome WebView nicht. Also fehlen Fully die H.264 Codecs und H.264 Videos (wie es meine IP Cam Streams sind) bleiben schwarz. Derzeit arbeite ich an einer custom Chromium WebView, die von Fully verwendet werden kann und alle Codecs inkludiert.

Meine Erfahrung sagt mir jedenfalls, der Teufel liegt hier zumeist in den Details bezügliche der unterstützten Codecs, so kann es etwa sein, dass ein Browser behauptet er kann H.264 decodieren, kann es aber dann doch nicht, weil er nur das Baseline Profil unterstützt und der ankommende Stream davon abweicht. Das kann man aber dann zB in Janus mit einer Option bei der Stream Konfiguration erzwingen.

Grüße,
Sascha

PS: Zur Nachvollziehbarkeit meiner bisherigen Schritte ein paar Links zu diversen Beiträgen von mir:
https://bugs.chromium.org/p/chromium/issues/detail?id=801501&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=
https://bugs.chromium.org/p/chromium/issues/detail?id=719024
https://bugs.chromium.org/p/chromium/issues/detail?id=719023
https://groups.google.com/forum/?nomobile=true#!topic/meetecho-janus/FwXG36e5uGQ
https://groups.google.com/forum/?nomobile=true#!topic/meetecho-janus/LLgNU60qI_E

[DS_Starter]

Hallo Sascha,

herzlichen Dank für deine wirklich umfangreiche Einführung
Bis jetzt hatte ich mit der Janus Installation von Meetecho (ohne Docker) experimentiert und war nicht wirklich glücklich geworden.
Aber ich werde mir nun deine Dockerlösung mit deinem Ansatz zu Gemüte führen. Das liest sich erstmal recht optimistisch.
Vielleicht finden sich noch ein paar Mitstreiter die bei der WebView/Fully Problemlösung mithelfen können.

Am Ende steht bei mir das Ziel eine integrierte Lösung für SSCam-Nutzer anbieten zu können.
Mal schauen wann es gelingt. 

Danke erstmal und ich hoffe der Thread bekommt Zuwachs.

Grüße
Heiko

[AlpenFlizzer]

Ich freue mich über Gleichgesinnte! :-D

Bzgl. WebView/Fully: Ich habe gestern mal Chrome mit den default Build Flags gebuildet. 60 Gigabyte und 8 Stunden bei 100% CPU Last später konnte ich meinen eigene 100MB große Chrome App auf mein Tablet installieren. 

Die 'angeblich' richtigen Build Flags für alle Codecs habe ich im Internet schon erstöbert, sollte ich diesbezüglich also demnächst erfolgreich sein, lasse ich es euch wissen.

Mein Ziel bei dem Ganzen vorhaben ist die Darstellung meiner IP Cam Stream in Fully. Das SSCam Modul kenne ich garnicht, werde ich mir aber auch mal reinziehen - nutze nämlich auch eine Syno DS für Aufzeichnungen, eventuell gibt es da einen Nutzen für mich den ich nicht kannte.

Grüße,
Sascha

[DS_Starter]

Das SSCam Modul kenne ich garnicht, werde ich mir aber auch mal reinziehen - nutze nämlich auch eine Syno DS für Aufzeichnungen, eventuell gibt es da einen Nutzen für mich den ich nicht kannte.

Gibt es schon seit 2015 

Siehe auch Wiki:
https://wiki.fhem.de/wiki/SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station

Das ergänze ich laufend (wenn ich Zeit habe).

LG

[AlpenFlizzer]

Ich habe schon etliche Möglichkeiten geschaffen und beschrieben, z.B. RTSP zu HLS bzw. RTSP zu MJPEG.

Ich habe auch versuchsweise mittels NGINX und FFMPEG RTSP Streams in HLS umgewandelt und dann mittels plain HTML5 im Video-Tag dargestellt. Wie ist bei dir da die Verzögerung zum Originalstream? Ich bin nicht unter 8 Sekunden Versatz gekommen, egal wie sehr ich die FFMPEG Settings getweakt habe.

Übrigens: Eine weitere Möglichkeit, die fehlenden H.264 Codecs in der Chrome WebView zu umgehen ist, den RTSP Stream mittels Gstreamer in VP8 zu konvertieren (VP8 ist das "kostenlose" Equivalent zu H.264 und im derzeitigen Codec-Krieg der relevanteste Gegner - VP8 wird von allen Mainstream Browsern per default unterstützt) und im Anschluss mittels Janus wie gewohnt per WebRTC zu streamen. Dazu habe ich auch schon Versuche gemacht und den Big Buck Bunny Demo-RTSP Stream konvertiert und gestreamt. (Wenn auch zum Preis von ca. 30% CPU Last per Stream) Leider hat mir das nötige Wissen/Können gefehlt, um das Ganze auf meine IP Cam Streams umzulegen (Wieder mal Codec geschichten...). Also sollte in dem Forum ein Gstreamer Experte herumgeistern, ich wäre da an einem Austausch interessiert.

LG

[DS_Starter]

ch habe auch versuchsweise mittels NGINX und FFMPEG RTSP Streams in HLS umgewandelt und dann mittels plain HTML5 im Video-Tag dargestellt. Wie ist bei dir da die Verzögerung zum Originalstream? Ich bin nicht unter 8 Sekunden Versatz gekommen, egal wie sehr ich die FFMPEG Settings getweakt habe.

Mit der im Wiki beschriebenen Möglichkeit (gihad/streamer) komme ich auf einen Versatz von ca. 4 s. Je nach Einsatzzweck kann auch das genügen wenn man nicht Real Time Wiedergabe benötigt. Aber HLS hat ja technologisch bedingt immer einen Nachlauf.

VP8 wäre auf jeden Fall interessant, aber man muss natürlich schauen, dass das transkodieren nicht zuviel CPU-Power braucht. Die meisten User sind meist mit relativ schwacher Hardware unterwegs. Und wenn man nicht nur eine Kamera hat, wird das schnell zuviel.