NEWS
Einbindung (IP) Kamera über "Motion"
-
Hi,
Hab motioneye auf einem rock64 mit 4GB laufen. Die letzten Tage hatte ich das Problem, das die Cpu Last von motion immer bei über 90% ist und der Rock damit heiß wird. Das ganze bei nur einer Kamera.Auflösung war 800×600, Qualität 75%
Hattet ihr das Problem auch schonmal?
Dachte da motioneye auch auf einem Pi läuft würde der Rock nicht mal zucken.@martinschm der Rock macht nichts anderes? Ich habe auch keine beseondere Hardware, aber einige VM laufen, darunter eine für motioneye mit 3 Cameras. Motioneye alleine zieht 15% CPU bei mir. Wieviele frame rates hast du? Ich habe nur 3 frames pro Sekunde.
-
@pix kannst du mal deine bash-datei zeigen für die action buttons? Buttons habe ich, aber funktionieren nicht. Sieht bei mir so aus für "down_1-button":
#!/bin/bash URL="http://user:passwort@192.168.178.31/cgi-bin/hi3510/ptzdown.cgi" METHOD="GET" TIMEOUT="5" curl -X $METHOD --connect-timeout $TIMEOUT "$URL" > /dev/null@lobomau Hallo,
habe mal versehentlich motioneyeOS per Weboberfläche upgedatet und damit zerschossen. Darf man nicht machen, nur über CLI. Deshalb habe ich alles neu aufsetzen müssen und dabei die Action Buttons nicht neu erstellt. Sie sind ja in VIS nicht sichtbar und daher doch eher uninteressant.
https://forum.iobroker.net/post/152954
Gruß
PixioBroker auf Ubuntu in Proxmox (früher Mac mini (bis OS X 10.12.6 Sierra), VIS via iOS; angeschlossen: Homematic CCU2, Homepilot 1, ConBee II, einige Wemos, Sonos, Unifi CK+Protect, Homekit, Homebridge; KEIN blockly! Github-Profil
-
@lobomau Hallo,
habe mal versehentlich motioneyeOS per Weboberfläche upgedatet und damit zerschossen. Darf man nicht machen, nur über CLI. Deshalb habe ich alles neu aufsetzen müssen und dabei die Action Buttons nicht neu erstellt. Sie sind ja in VIS nicht sichtbar und daher doch eher uninteressant.
https://forum.iobroker.net/post/152954
Gruß
Pix -
@martinschm der Rock macht nichts anderes? Ich habe auch keine beseondere Hardware, aber einige VM laufen, darunter eine für motioneye mit 3 Cameras. Motioneye alleine zieht 15% CPU bei mir. Wieviele frame rates hast du? Ich habe nur 3 frames pro Sekunde.
-
@lobomau hab glaub ich 5 oder 7 frames.
Kannst du mal die anderen Werte posten die du so hast. Also wie kommt der Stream von deiner Kamera und was hast du in motioneye bezüglich Auflösung, Frames, Qualität eingestellt ?
CPU Belastung für motioneye < 20%:
-
CPU Belastung für motioneye < 20%:
-
@lobomau Vielen Dank.
Was für ein Format streamen denn deine Kameras?
Ich streame grade via rstp im Videoformat VBR. Bitrate habe ich 2000 Kbits eingestellt und Frames aktuell 10 pro Sekunde. Videogröße ist 1270x720.
@martinschm muss ich mal genau schauen. Ich glaube meistens habe ich 10 frames in den cameras eingestellt. Die wansview ist über rtsp, die anderen beiden über http.
-
@martinschm muss ich mal genau schauen. Ich glaube meistens habe ich 10 frames in den cameras eingestellt. Die wansview ist über rtsp, die anderen beiden über http.
-
@lobomau wäre super, wenn du mal schauen könntest. Hatte irgendwo was gelesen, das motioneye den Stream decodiert und wieder codiert, das erzeugt dann wohl auch Last
@martinschm also bei meinen cameras steht:
FDT 720p: http, 1280 x 720, bitrate: 4096 kbps, 10 frames, bitcontrol: VBR,
wansview w2: rtsp, 1920 x 1080, bitrate: 2048 kbps, 10 frames, bitcontrol: VBR,
Edimax: http, 1280 x 960, 20 frames -
@martinschm also bei meinen cameras steht:
FDT 720p: http, 1280 x 720, bitrate: 4096 kbps, 10 frames, bitcontrol: VBR,
wansview w2: rtsp, 1920 x 1080, bitrate: 2048 kbps, 10 frames, bitcontrol: VBR,
Edimax: http, 1280 x 960, 20 frames -
@lobomau bei mir sieht es in htop so aus mit zwei Kameras und Bewegungsüberwachung
Beide via rstp 7 frames bei 2000 kbps mit VBR und 960x540 Auflösung. Da hat jeder motion process über 25% CPU oder lese ich das falsch?
@martinschm ich kenne mich damit nicht aus. Bei mir zeigt "top" wenn ich im server einlogge 50-70% für motion an. Und manchmal >200% kvm. Für motioneye hab ich aber einen eigenen Container laufen. Eigentlich dachte ich dass ich keinen motion process sehen würde beim Server.
-
Ok. Super. Fangen wir mal an.
Grundvoraussetzung um den iobroker Motion Adapter zu nutzen ist natürlich ein funktionierender motion daemon. Dieser Dienst muss nicht zwangsweise auf dem gleichen System laufen wie iobroker, da der Adapter mit diesem via Netzwerk spricht.
Da Motion rtsp nativ erst in einer neueren Version unterstützt (ich benutze 4.0.1) ergeben sich zwei unterschiedliche Möglichkeiten. Beide haben vor und Nachteile.
1.) Man nutzt eine aktuelle Version von Motion.
2.) Man benutzt eine ältere Version von Motion und macht rtsp und decodierung des h264 streams extern.
Die Vorteile von Variante 1 liegen auf der Hand. Weniger Komplexität und daher vermeintlich höhere Stabilität.
Die Nachteile von Variante 1: H264 decodierung in Software (daher höhere cpu last)
Die Vorteile von Variante 2: Höhere Flexibilität bei Quelle und Decodierung. Alles was gstreamer kann, kann auch mit motion verwendet werden. (inkl. omxdecode auf der rpi gpu)
Die Nachteile von Variante 2: Höhere Komplexität. Vor dem Motion dameon muss noch ein loopback modul geladen werden und eine gstreamer pipeline muss eingerichtet werden. Das sind alles Dinge die abspacken können.
Vorschlag:
Wenn motion auf einer Kiste läuft, die wenig CPU aber die Möglichkeit von GPU Decoding hat (vaapi, omx usw.) wie z.b. der rpi dann empfehle ich Variante 2.
Wenn man keine Möglichkeit des GPU Decodings hat, oder genug cpu power dann empfehle ich Variante 1.
Wenn das alles läuft, können wir uns um den Adapter kümmern.
@ruhigundrelaxed sag mal, ist das Thema mit dem GPU decoden immer nur noch in der "alten" Version von Motioneye und mit Loopback möglich oder hat sich da in den letzten Monaten was getan? Habe eine VM mit GPU erstellt und würde Motioneye hier möglichst CPU-Ressourcensparend laufen lassen => GPU soll die möglichen Aufgaben übernehmen... Wie kann ich das einstellen und vor allem am System sehen / testen?
-
Das Thema ist zwar schon ein paar Tage alt, aber vielleicht hat der eine oder andere MotionEye Nutzer einen Tip für mich.
Bei mir laufen 5 Kameras über einen RPI 3B+. Ich nutze den rtsp Stream Link um die Kamera Bilder in ioB anzuzeigen.
Dabei ist mir schon vor einiger Zeit aufgefallen, das die Bilder die über MotionEyeOS ruaskommen, teilweise mehrere MINUTEN gegenüber dem Livebild der Kamera verzögert sind.
Hat jemand eine Idee woran das liegen kann? An der Menge der Kameras liegt es nicht, denn das Phänomen tritt auch im "Ein Kamera Modus" auf.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Das Thema ist zwar schon ein paar Tage alt, aber vielleicht hat der eine oder andere MotionEye Nutzer einen Tip für mich.
Bei mir laufen 5 Kameras über einen RPI 3B+. Ich nutze den rtsp Stream Link um die Kamera Bilder in ioB anzuzeigen.
Dabei ist mir schon vor einiger Zeit aufgefallen, das die Bilder die über MotionEyeOS ruaskommen, teilweise mehrere MINUTEN gegenüber dem Livebild der Kamera verzögert sind.
Hat jemand eine Idee woran das liegen kann? An der Menge der Kameras liegt es nicht, denn das Phänomen tritt auch im "Ein Kamera Modus" auf.
Internetleitung ausgelastet?
Zuviele Geräte?
Hab ne 50er Leitung und die ist arg strapaziert mit knapp 35 Geräten. -
Internet dürfte damit nichts zu tun haben, weil alle Geräte, einschließlich ioB im selben IP Kreis unterwegs sind.
Internet ist eine 200er Leitung - das nur am Rand und 60 aktive Geräte sollten jetzt auch Netzintern nicht so das Problem sein.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Internet dürfte damit nichts zu tun haben, weil alle Geräte, einschließlich ioB im selben IP Kreis unterwegs sind.
Internet ist eine 200er Leitung - das nur am Rand und 60 aktive Geräte sollten jetzt auch Netzintern nicht so das Problem sein.
Beim Kamera streamen hat die Leitung schon ein besonderes Augenmerk ;)
Aber ich denke die 200er sollte tatsächlich reichen.
Bin über dein Post gestolpert weil ich gerade in MotionEye rumfummel :)
3 Kameras, ruckelfreies streamen sieht anders aus :( -
Ich verwende auch keinen echten Livestream, sondern hole mir alle 1 Sekunde ein neues Standbild ab. Für meine Zwecke reicht das - es nervt nur kolossal, wenn es an der Haustür klingelt und lt. Kamerabild ist niemand da weil die Bilder 2-3 Minuten hinter dem echten Livebild hinterher hinken.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Ich verwende auch keinen echten Livestream, sondern hole mir alle 1 Sekunde ein neues Standbild ab. Für meine Zwecke reicht das - es nervt nur kolossal, wenn es an der Haustür klingelt und lt. Kamerabild ist niemand da weil die Bilder 2-3 Minuten hinter dem echten Livebild hinterher hinken.
Das kenne ich :) :)
Wie hast du das umgesetzt?
Bei mir war es der Versatz von Bild machen und bereitstellen.
Da war die Zeit zu kurz.
Nun geht es so lala. -
was meinst du mit umgesetzt?
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
was meinst du mit umgesetzt?
Ich hab das über MotionEye, Javascript und dann in die VIS
631
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge