Webcam proxy extrem unperformant
Ich benutzte aktuell zwei Kameras mit einer Auflösung von 1280x720 und
1920x1080. Jedoch kommt es bei der Nutzung zu extremen Performanceproblemen. Repetier server zieht ca 360% cpu leistung (4 Thread cpu). Die beiden Mjpg-streamer Instanzen hingegen ziehen jeweils nur ca 10% Leistung.Das Webinterface reagiert nach einiger Zeit nicht mehr und zeigt beim neuladen eine Ladeanimation an (siehe Screenshot). Nach einiger Zeit ist es dann wieder erreichbar. Der Vorgang wiederholt sich aber, sobald irgendwo der Stream im repetier Webinterface angezeigt wird.
Da es zu keinerlei performante Probleme kommt, wenn ich mir die Streams direkt anschaue, also ohne das Repetier server Webinterface zu nutzen und aufgrund der Tatsache, dass Repetier server nun 360% cpu im Leerlauf zieht so bald ich die Kamera im repetier Webinterface öffne, denke ich, dass es wahrscheinlich am integrierten viedo proxy liegt.
Ich habe die Framerate bereits von 30fps auf 15 reduziert, als auch die Auflösung auf 1280x720 herabgesetzt, ohne ein nennenswerte Verbesserung zu erzielen.
Wäre es ggf möglich den Stream optional einfach nur per iframe einzubinden, so das Repetier server nur für den timelapse selbst auf die Kamera zugreifen muss?
Auffällig ist auch dass wenn das Repetier server Webinterface hängt, firefox noch nicht mal mehr in der Lage ist den dev moduls zu öffnen und mindestens einen ganzen core Leistung frisst.
Auffällig ist auch dass wenn das Repetier server Webinterface hängt, firefox noch nicht mal mehr in der Lage ist den dev moduls zu öffnen und mindestens einen ganzen core Leistung frisst.
Der dunkel graue Teil im Scrennshot ist das Webinterface von Repetier server, der weiße Abschnitt (welcher genau die gleiche Farbe hat, wie der Hintergrund dieses Forums und deswegen kaum sichtbar ist), ist der ebenfalls nicht ladende Firefox dev moudus.
Comments
Der server Proxy ist eigentlich recht performant und nutzt nicht ganz 2 mal die cpu last des mjpg streams. Allerdings kommen bei 1920x1080px 30FPS eine Datenrate von ca 300MBit/s zusammen. Wenn das dann nicht über gigabit ethernet sondern wifi gesendet wird, gibt es einen Flaschenhals. Möglicherweise verursacht das die Probleme und die hohe Last des servers.
Was Firefox angeht ist MJPG recht katastrophal. Langsam beim dekodieren, bei meiner pi cam im Direktstream stopt die Übertragung ständig, allerdings bei unserem Proxy stream nicht. Wenn er einen Punkt überschreitet bekommt er in der tat nichts mehr auf die reihe, stat einfach frames fallen zu lassen. Dev modus geht dann auch nicht mehr.
Vermutlich sollte ich dem Proxy beibringen die Framerate selbständig zu verlangsamen. Das ist wohl noch nicht gut genug gelöst. Mal sehen ob ich da was hinbekomme. Aber grundsätzlich sollte man nie hohe auflösung und FPS kombinieren, da die Komprimierung von MJPG schlecht ist und auch die wiedergabe sehr CPU lastig ist.
Auffällig war wie gesagt, dass es zu keinen Performencproblemen kam, wenn ich den Stream direkt anschaue.
Versuche gerade das mit Websockets zu lösen, aber Firefox stürzt bei den Lösungen aktuell gerne ab, wobei Chrome das ganze ohne murren mitmacht. Hier wäre es sogar offenbar besser wenn das Netzwerk langsamer wäre, dann käme firefox hinterher weil wir dann Frames droppen. So aber buffert er imme rmehr und fügt sogar verzögerungen ein. Mal sehen wie weit ich mit der Alterntivlösung komme. Immerhin hat sie keinen Backbuffer und verzögerung ist daher nur minimal.
Firefox hat ja scheinbar keinerlei Probleme damit, den mjpg-stream direkt zu dekomprimieren.
Sounds like a different issue. Can you check over ssh if
ps aux | grep mjpg
shows no mjpg_streamer instances when that happens. Since a restart of the mjpg_stremer instaces works the problem is more likely that they stopped or crashed. If they stopped you should check /var/log/syslog to see at the timestamp if there is any hint like linux disconnnected usb or a mjpg reason for closing.