Ich habe heute noch mal geschaut, warum die Streams im LAN gar nicht laufen.
Das lag daran, dass ich das WebFront per SSL eingebunden habe. Ohne SSL funktioniert es. Zur Nichtunterstützung von Streams über SSL gab es ja glaube ich schon einen separaten Thread.
Die Streams laufen im LAN auch soweit flüssig, wobei einer des Öfteren Artefakte hat. Keine Ahnung warum.
Also ist bei mir das Hauptproblem die Reduzierung der Bildqualität über Connect. Da war ich unter 5.4 mit Einbindung der Streams via VPN (bedarfsweise) in Summe besser dran.
Also ich plädiere immer noch für eine Option, die Transkodierung über IPS und Connect einstellen zu können und auch die Streams weiterhin direkt aufrufen zu können.
Magst du den Spezialschalter einmal aktivieren, dann den Stream anlegen und im WebFront einmal öffnen? Es sollte dann entsprechend „lila“ Meldungen im Meldungsfenster auftauchen. Magst du diese einmal hier rein kopieren?
Gibt es schon Anhaltspunkte an was es hier scheitert?
Betrifft es nur Pi´s?
Zuwenig Rechenleistung?
Ich werde in einigen Wochen auf einen Pi4 mit SSD updaten.
Gestern in der Dunkelheit ist mir durch Zufall aufgefallen, dass es beim „Nachtsichtmodus“ - also IR-LEDs an und Graustufenbild, bei der selben Kamera zu keinen Problemen führt. Der Stream lief ca. 15 Minuten (danach habe ich abgeschaltet) ohne Probleme, tagsüber im Farbbild schafft er keine 30 Sekunden.
Danke für den Hinweis. Ich vermute auch, dass es mit der Bitrate zusammenhängt und bei dunklen Passagen ändert sich nicht so viel, wodurch die Bitrate sinkt.
Gibt es eigentlich zwischenzeitlich Neuigkeiten? Ich würde auch gerne auf die 5.5 updaten, aber benutze einige 1080p Streams, die u. U. von mehreren Benutzern gleichzeitig angeschaut werden könnten.
Erfolgt die Transkodierung eigentlich 2 mal gleichzeitig (und damit die doppelte Belastung des Systems - bei mir via Docker auf einer Synology) , wenn sich zwei User den gleichen Stream auf unterschiedlichen Endgeräten anschauen?
Erfolgt die Transkodierung generell nur, wenn sich mindestens 1 User den jeweiligen Stream anschaut, oder erfolgt die Transkodierung (und damit die Systembelastung) unabhängig davon 24/7?
Wie hoch ist die reduzierte Framerate via Connect?
Der Stream wird immer nur einmal, und nur bei Bedarf transkodiert.
Allerdings wird der Output vervielfältigt, wenn mehrere Clients ihn anfordern.
Michael
Der Thread ist zwar älter aber ich bin jetzt auch auf das RSTP hohe CPU Last issue gestoßen. Bei mir wird ein i7 (OK Gen6) zu 10-30% ausgelastet. Ist aber eine virtuelle Maschine also keine Gfx grafikkarte vorhanden die irgendwie eine transcodierung beschleunigen könnte.
Gibt es außer bitrate reduzieren weitere optimierungsmöglichkeiten? Laufen bei mir je als halber ipad screen da das Türkameras sind - von daher kann ich die Bitrate nur bedingt runterdrehen.
Hi. Ich muss auch noch mal kurz reingrätschen. Ich habe derzeit Instar-Kameras genutzt, welche ich über MJPEG direkt in einen http-Aufruf in der MobileApp als Frame eingebunden habe. Funktionierte wunderbar. Jetzt hat Instar die Preise für die FullHD-Modelle aber dermaßen angezogen, dass ich mir testweise eine Reolink RLC-410W bestellt habe. Diese kann - wie viele neueren Kameras - leider kein MJPEG mehr, sondern nur noch RTSP (und FLV, was aber beim besten Willen keiner mehr braucht ) …
Ich habe daraufhin die Reolink über den Symcon-Stream mittels RTSP eingebunden (Symcon in Version 6.1, neueste Testversion vom 31.01.22). Auch wenn ich den Stream in Auflösung auf 1080P und nur 10 Bilder pro Sekunde begrenze, ist der Stream extrem verzögert (zieht sich sozusagen in Zeitlupe nach).
Daraufhin habe ich mal die Instar-Kameras (wie gesagt, ober MJPEG einwandfrei) mittels RTSP als Stream hinzugefügt. Hier ganz genau so das gleiche Verhalten.
Könnt ihr das so bestätigen oder gibt’s einen Trick, vom dem ich nix weiß? …
Ich hatte genau wie Du diesen Weg ausprobiert, nur mit einer Hikvision. Da hatte ich zu spät bemerkt das sie nur eine Mjpeg-Auflösung von 640x480 oder so bietet. Und per Rtsp ist es dort, wie auch bei meinen Instar-Kameras, zwar möglich gewesen einen relativ flüssigen Stream hin zu bekommen, aber leider brauchte dieser 3,4 Sekunden bis zum Start.
Da das für mich ein NoGo ist, hab ich mir die nächste Instar gekauft, da diese nach meinen Recherchen die einzigen sind, die in der Preisklasse einen recht guten Mjpeg-Stream abliefern.
Mit der Verzögerung bis zum Start des Streams könnte ich sogar noch leben, aber dann muss er flüssig laufen, was er leider nicht tut, weder bei Instar noch bei Reolink. Da die Instar einwandfrei einen MJPEG Stream über die Symcon MobileApp anzeigen, ist das Problem scheinbar doch bei den Stream-Instanzen von Symcon zu suchen. Ich habe testweise die Reolink über VLC und RTSP gestreamt, hier gibt es Verzögerungen von etwa einer Sekunde bei absolut flüssigem Stream. Ich greife nicht über den Connect-Dienst zu sondern direkt per Portweiterleitung mit öffentlichem Zertifikat und TLS. Und spätestens die Vorschau des Streams über die Symcon Konsole (lokal auf 3777) sollte einen verzögerungsfreien Stream liefern. Aber auch hier leider die Zeitlupe.
Kannst du mal schauen wie die CPU Auslastung auf deinem System ist? Ist ein Kern vollkommen ausgelastet? Eigentlich sollten 10 FPS bei 1080p gut gehen. Kannst du Test-Weise eine 720p Auflösung mal testen?
So, ich hab mal geschaut. Symcon läuft auf einem Lenovo Q180 mit 4 Kernen und 4 GB Ram unter Windows Server 2016. Wenn ich den RTSP-Stream bei 1080P und 10 Frames starte, geht zwar die Last etwas hoch, aber nicht so, dass ein Kern am Anschlag läuft. Die Last aller Kerne liegt zwischen 20 und 80 % in der Spitze. Der IPS-Prozess dümpelt ohne Stream zwischen 10 und 30 % und bei gestarteten Stream zwischen 20 und 40 %.
Bei 1080P und 10 Frames verhält es sich so: Ich starte den Stream, warte 3 Sekunden und mache dann eine Bewegung. Diese wird im Stream etwa 30 Sekunden später in Zeitlupe angezeigt. Das Ganz schaukelt sich hoch. Je länger man wartet, desto später wird die Bewegung sichtbar.
Wenn ich auf 720P bei 10 Frames gehe, wird es etwas besser. Hier wird die Bewegung nach 10 Sekunden sichtbar mit etwas höherer Geschwindigkeit.
Bei den niedrigsten Settings (640 x 380, 7 Frames, 160 KBit) läuft es einigermaßen, aber dafür kannste auf dem Bild nix mehr erkennen …
Im Browser und als RTSP Stream über den VLC ist alles super flüssig, selbst in den höchsten Auflösungen und bei 30 Frames … sehr seltsam das Ganze …
) …
…