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.
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

  • Ich hab das gerade mal versucht nachzustellen.
    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.
  • Benutze eine pi3, dieser ist über gigabit Ethernet angeschlossen, jedoch kann der Anschluss vom pi nur ca  321Mbits/sec. Die sollte von der Datenrate her eigentlich ausreichen.

    Auffällig war wie gesagt, dass es zu keinen Performencproblemen kam, wenn ich den Stream direkt anschaue.
    Sonder lediglich, wenn ich ihn über den cam proxy geschaut habe, welcher dann praktisch die komplett verügbar cpu leistung in Anspruch nahm.

    Falls die Datenrate ein Problem wäre sollte dann nicht ein http reverse proxy der zeitgleich nochmal komprimiert Abhilfe verschaffen können oder das Problem zu mindestens entschärfen können?
  • Problem ist wenn firefox mit dekomprimieren nicht hinterherkommt. Dann blockiert er total, lädt aber weiterhin mit voller Datenrate. Dadurch erhöht sich sogar konstant der Speicherverbrauch.

    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.
  • Was spricht gegen eine Option zur Einbindung als iframe?
    Firefox hat ja scheinbar keinerlei Probleme damit, den mjpg-stream direkt zu dekomprimieren.
  • iframes lösen das Problem nicht sondern verlagern es ins iframe wo ja dann das mjpg ist. Und direkt vom streamer ohne proxy geht nicht weil das nicht weitergeleitet wird, nicht bei allen Webcam klappt, ... Hab den proxy ja nicht so ganz ohne Grund:-) Bin jetzt seit 3 Tagen an der Lösung dran und fast durch. Konnte sogar die abstürze von Firefox beseitigen und performance des proxy erhöhen.
  • I think I am having this same problem.  I am not familiar with the technical details of my device, but I do have Repetier server running with a webcam and I am able to watch the video at 1920x1080 @ 15FPS as long as I like in Chrome.  However, if I stop viewing the video and return to pick up the monitoring later, the Webcam video stream is unavailable to view.  The only way to resume viewing the video is to reset the webcam server.  When I reset the webcam server from the printer settings page neither the static nor video images reload.  I must click on the server home page link at the top of the browser and when I review the dashboard, the camera is back online again.  I can then watch it and open it in webcam view where I am able to watch the webcam for as long as I want until I leave and then at some point the video stream stops and repeat the cycle..... Is there a logging function I can send to identify the root cause of this issue?
  • I should have added to my note above that I am running stock Repetier Server 1.2.0 on a raspberry Pi 3B setup.  The power supply to the Raspberry Pi is a UL certified 2.5A supply.   The server itself never shows issues, but the webcam server continuously fails to display video or static photo images.

  • @KWizzK
    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.
Sign In or Register to comment.