Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[PeZi]

@samson71
Stimmt, das Kamerabild soll nicht in VIS dargestellt werden, da dies, zumindest nach meinem derzeitigen Kenntnisstand, für einen RTSP-Stream nicht möglich ist und eine vorherige Transcodierung z.B. mittels go2rtc zu großen Latenzen führt.
Unabhängig davon steuert VIS aber die Darstellung über ein Javascript und soll soll im nächsten Schritt auch die Steuerung einer PTZ-Kamera übernehmen (in meinem Fall eine Reolink 4K 8MP PTZ PoE).
Für die Darstellung der Visualisierung muss Chromium für meinen Anwendungsfall nicht zwingend im Kiosk-Modus laufen, falls dieser mein Vorhaben beeinträchtigt. Die Aktivierung des Vollbildmodus und die Unterdrückung der Cursoranzeige sind ja auch anders möglich.

Ich gehe mal davon aus, dass noch mehr Nutzer von ioBroker bzw. VIS vor dem Problem stehen RTSP-Streams einfach "vis-gesteuert" darzustellen. Daher war mein Ansatz, das Thema hier mal zur Diskussion zu stellen.

Ggf. gibt es ja dazu auch alternative Lösungsvorschläge...

Peter

[Samson71]

@pezi sagte in RTSP-Kamera in VIS darstellen:

eine vorherige Transcodierung z.B. mittels go2rtc zu großen Latenzen führt.

Die Software kenne ich nicht, aber die Aussage kann ich grundsätzlich so nicht bestätigen und damit so stehen lassen. Einbindung in VIS z.B. über Surveillance Station einer Synology läuft problemlos. Viele nutzen auch MotionEye sehr erfolgreich. Kann natürlich auch an der mangelnden Leistung des Endgerätes für die Darstellung liegen oder an der eingesetzten Hardware zur Transkodierung des Streams. Ohne diesen Kontext ist die Aussage jedenfalls zu pauschal und schlichtweg falsch.

@pezi sagte in RTSP-Kamera in VIS darstellen:

Unabhängig davon steuert VIS aber die Darstellung über ein Javascript und soll soll im nächsten Schritt auch die Steuerung einer PTZ-Kamera übernehmen (in meinem Fall eine Reolink 4K 8MP PTZ PoE).

Ob das Skript nun aus VIS heraus getriggert wird ist eine Sache, aber der Beschreibung nach "steuert" VIS hier gar nichts, sondern soll sich bei Auslösen des Triggers irgendwie per Skript verkleinern, damit die andere App mit dem Kamerastream auch Platz findet. Das war meine Feststellung als Abweichung zur gewählten Überschrift. Daher auch mein Hinweis auf den Kiosk-Modus und ggf. dort erstmal ansetzen. Sei es mit einem alternativen Browser (z.B. Kioskbrowser) oder aber auch erstmal ohne den Kiosk-Modus probieren.

@pezi sagte in RTSP-Kamera in VIS darstellen:

Für die Darstellung der Visualisierung muss Chromium für meinen Anwendungsfall nicht zwingend im Kiosk-Modus laufen, falls dieser mein Vorhaben beeinträchtigt. Die Aktivierung des Vollbildmodus und die Unterdrückung der Cursoranzeige sind ja auch anders möglich.

Dann probiere doch genau das mal aus. So war zumindest mein Hinweis auf den Kiosk-Modus zu verstehen.

@pezi sagte in RTSP-Kamera in VIS darstellen:

Ich gehe mal davon aus, dass noch mehr Nutzer von ioBroker bzw. VIS vor dem Problem stehen RTSP-Streams einfach "vis-gesteuert" darzustellen. Daher war mein Ansatz, das Thema hier mal zur Diskussion zu stellen.

Die Frage einen RTSP-Stream in VIS einzubinden ist tatsächlich schon mehr als einmal hier aufgetaucht und auch jeweils breit mit Möglichkeiten und Hinweisen einer Umsetzung diskutiert und beschrieben worden. Siehe dazu auch meine konkreten Hinweise auf 2 mögliche Anwendungen im ersten Absatz. Was Du in dem Kontext unter "vis-gesteuert" verstehst oder damit meinst bleibt (für mich) aber immer noch ein Geheimnis, denn ich vermag keine Steuerung aus oder mit VIS aus Deinen bisherigen Ausführungen zu erkennen.

[bahnuhr]

@pezi

Bei mir läuft go2rtc in proxmox.
Davor hatte ich motioneye in proxmox.
Und dann nach VIS.

!! Bei beiden gibt es keine Zeitunterschiede !!

Links die cam direkt. Rechts in vis über go2rtc.
Die Sekunden sind gleich.

[wendy2702]

Ich habe weder mit go2rtc, Frigate oder AgentDVR Latenzen auf meinen Anzeigen die jeweils aus PI5 und Touch Monitor bestehen sowie ein IPAD.

[PeZi]

@bahnuhr
@wendy2702
Bei mir laufen ioBroker und Chromium jeweils auf einem Raspberry 4 mit 8GB. Weitere Software ist auf keinem der beiden Raspis installiert. go2rtx läuft auf einem dritten Raspi 4 mit ebenfalls 8GB.

Zu Beginn, wenn eine der Kameras "Neu" aufgerufen wird, ist keine Latenz vorhanden. Im Gegenteil, über go2rtc und VIS kommen die Bilder sogar etwas schneller als direkt vom Web-Interface der Kamera:

Wenn der Stream allerdings dauerhaft angezeigt wird, steigt die Latenz innerhalb einer halben Stunde deutlich an.

Hier meine Konfigurations-Dateien von go2rtc:

[Unit]
Description=starting go2rtc server

[Service]
User=admin
WorkingDirectory=/usr/local/bin/go2rtc/
ExecStart=/usr/local/bin/go2rtc/go2rtc_linux_arm64
Restart=always

[Install]
WantedBy=multi-user.target

streams:
 kamera1:
 - rtsp://user:password@192.168.22.40:554/Preview_01_main#udp#media=video
 kamera2:
 - rtsp://user:password@192.168.22.41:554/Preview_01_main#udp#media=video
 kamera3:
 - rtsp://user:password@192.168.22.18:554/mpeg/media.amp
# kamera4:
# - "ffmpeg:rtsp://user:password@192.168.22.42:554/Preview_01_main#video=h264#ultrafast#width=1280"

Kamera 1 und 2: Reolink RLC 520A
Kamera 3: Doorbird
Kamera 4: Reolink 4K 8MP PTZ PoE (derzeit noch nicht produktiv)

Als weitere Software hatte ih mit gleichem Ergebnis mediamtx im EInsatz.
Motioneye habe ich aufgrund vieler negativer Berichte hinsichtlich Entwicklungsstand und auch Latenz, auch hier im Forum, nicht getestet.

Peter

[MartinP]

@pezi interessant wäre, WO hier gepuffert wird.
An irgendeiner Stelle müssen die Frames ja zwischengespeichert werden, wenn sie nicht direkt ausgespielt werden.
Da müsste man schauen, ob auf dem Player- Rechner, oder auf dem go2rtc Rechner der Speicher ansteigt.

Falls es wirklich bei go2rtc ist, kann man ggfs mit Parameter Voodoo bei den Kamera Streams etwas erreichen...

In gewissen Grenzen wird man eh keine Unterschiede erreichen können, da unter der Motorhaube der meisten linux Video Tools ffmpeg arbeitet.

[wendy2702]

Sehe ich das richtig das du den Main Stream mit voller Auflösung nimmst?

[bahnuhr]

@pezi
Peter, bei mir sieht der Link so aus:

Terrasse_2: rtsp://user:pass@192.168.243.158:88/videoMain

alles foscam Kameras.
Und kein Versatz.

[PeZi]

@martinp
gepuffert wird bei go2rtc, da der Zeitversatz bei allen Anzeigegeräten gleich ist. Verursacht wird er aber scheinbar durch den Raspi der Anzeige, da dort das Bild der Kamera 1 ständig im Home-Bildschirm angezeigt wird.
Ich gehe daher davon aus, das die Pufferung "vor" go2rtc stattfindet. Wenn man diesen Puffer ausschalten könnte, würde im Ausgabestream alle paar Sekunden mal ein Bild fehlen, was aber kein Problem darstellt.

Der Parameter Voodoo sagt mir nichts. Was bewirkt er, wo gehört er hin und gibt es dazu weitere Parameter?

@wendy2702
Ja, für den Main Stream verwende ich die volle Auflösung (2560x1920)
Bei den Reolink Kameras wird bei Reduzierung der Auflösung des Main Streams das Bild rundum auf die gewählte Auflösung geschnitten. Der zweite angebotene Stream (im Reolink Wording "Fluent") hat eine feste Auflösung von 640x480.
Bei einem Ereignis an einer der Kameras wird deren Bild im Vollbildmodus angezeigt, sodass nur der Main Stream entsprechende Qualität liefert.
Eine Reduzierung der Auflösung auf die idealerweise benötigten 1920x1080 mittels go2rtc erhöht die Latenz schneller aufgrund der hierfür erforderlichen zusätzlichen Rechenzeit.
Statt dessen habe ich mit der Frame Rate und der maximalen Bitrate experimentiert, allerdings ohne nennenswerten Erfolg

Laut htop liegen aber alle relevanten Parameter des Raspis, auf dem go2rtc läuft, im grünen Bereich.

@bahnuhr
Den Parameter #media=video nutze ich, da ich kein Audio benötige (soll Rechenzeit sparen)
Von #udp erhoffe ich mir wegen des verbindungslosen Protokolls eine schnellere Abarbeitung, da verlorene Pakete einfach wegfallen. Die dann ggf. auftretenden Bildstörungen nehme ich in Kauf.

Danke für Eure Unterstützung

Peter

[wendy2702]

@pezi Ich verarbeite von meinen 4x Reolink nur den Sub Stream den Onvif ausgibt. Mir reicht das zur Anzeige auf der VIS von der Qualität.