Wenn bei der Intercom jemand klingelt, dann wird der Trigger zu FaceStreamAI gesendet welche den LiveStream "ODER" das LastPicture auswerten könnte - danach per UDP oder MQTT das Result zum Miniserver
Gesichterkennung im Video-Stream
Einklappen
X
-
Wäre es denn möglich, einen Trigger zu integrieren welcher die Gesichtserkennung anstößt damit diese nicht dauerhaft im Livestream arbeiten muss?
Wenn bei der Intercom jemand klingelt, dann wird der Trigger zu FaceStreamAI gesendet welche den LiveStream "ODER" das LastPicture auswerten könnte - danach per UDP oder MQTT das Result zum Miniserver-
LastPicture wäre von Loxone? Wenn das eine Url hat, geht das. Wie würde denn das Event von der Intercom aussehen? Kann man es irgendwo abgreifen? Offenbar hast du Erfahrung mit der Intercom gesammelt. Welche verwendest du denn? Die Intercom2? -
Intercom-2 hab ich!
Das Event von ver Intercom bezieht sich auf ein PlugIn von Loxberry (Intercom22Lox) > https://wiki.loxberry.de/plugins/intercom22lox/start
Somit hätte man das "LastPicture" und könnte es mit der URL vom Loxberry in die FaceStreamAI übergeben zur Auswertung, worauf per UDP/MQTT die Auswertung an Loxone übergeben wird!
Sie die mal den Link zum PlugIn an: https://wiki.loxberry.de/plugins/intercom22lox/start
Bzw. den SupportLink hier im Forum zum PlugIn, da stehen viele Infos drin über die Abwicklung: https://www.loxforum.com/forum/hardw...rauszubekommen
-
-
Kommentar
-
Der Videostream kann man direct abgreifen über folgende URL: http://USER:PASSWORD@IP.IP.IP.IP/mjpg/video.mjpg
Das mach ich auch bereits ... doch mein Verständniss ist hierzu, das "FaceStreamAI" kontinuirlich den Stream nach Gesichtern durchsucht - wobei mein Gedanke wäre, das mittels trigger das letzte Bild (oder ein Snapshot vom Videostream?) abgeholt & analysiert wird - danach Rückmeldung zu Loxone ...
Das letzte Bild nach dem Klingeln, kann man mit folgendem Script holen: https://github.com/markuslaube/loxon...ast-picture.sh
Wäre vielleicht eine Implementierung in den "FaceStreamAI" Tool möglich? Mit trigger und Rückmeldung?Zuletzt geändert von Syrus; 05.07.2024, 06:51.
-
-
Generell ist alles möglich. Ich werde mal überlegen, wie man das integrieren kann. Ich arbeite ohnehin gerade an einer Pro-Version, die MQTT unterstützt, mit Alter -und Geschlechtserkennung sowie mit einer Methode, die prüft, ob es sich um eine echte Person handelt oder um ein Foto, damit man die Software auch für sicherheitskritsche Anwendungsfälle nutzen kann, wie beispielsweise Tür öffnen.
Zum Verständnis: Der Slider Face Recognition Interval gibt an, in welchem Zyklus der Frames die Gesichterkennung durchgeführt wird. D.h. wenn dort eine 60 steht, wird jeder sechzigste Frame genommen und darauf die Gesichterkennung angewendet. Wenn die Gesichterkennung abgelaufen ist, wird wieder 60 Frames gewartet. Also nicht kontinuierlich bzw. du hast die Kontrolle darüber, wie oft die Gesichtserkennung läuft. Im Übrigen ist diese auch unabhängig vom Stream. Die funktioniert also auch ohne, dass du den Stream irgendwo ausgibst. Das ist schon recht effizient gebaut.Kommentar
-
Schön zu hören, dass das Porjekt lebt - danke dafür!
Bezüglich Slider FaceRecognition: Auch wenn der User die Kontrolle über die Anzahl der Prüfungen behält: Dann sollte es lt. meiner Auffassung doch eine Verzögerung geben (wenn auch maginal!) sofern der Slider hochgesetzt wird, da ja die Anzahl der Frames abgewartet wird? Ich finde leider keine Daten zu den Anzahl der Frames der Kamera oder den Stream - aber ausgehen der Frames von 25/s und FaceRecognition = 60, würde ein maximale Verzögerung von 2,4 sec. auftreten bis zu einer Rückmeldung ...
Weiters: Der Stream wird 24/7 gestreamt und im Zyklus (Frames) "FaceRecognition" geprüft was eine höhere Leistung abfordert ... soviel zur Theorie. Sofern es eine Triggerfunktion gäbe auf den Stream oder auf ein Snapshot vom Stream, könnte direkt danach die Erkennung folgen, was auch eine Reduzierung der Rechenleistung zu Gute kommen würde!
Das alles recht effizient gebaut ist, bezweifle ich nicht - im Gegenteil, alles gut - tolle Arbeit! Doch meine Auffassung dazu ist das immer ein Stream läuft welcher vielleicht nicht dauerhaft notwendig wäre, wenn zum Beispiel in der Nacht keiner an der Intercom läutet (in diesme Beispiel!)
Oder verstehe ich generell das System falsch bezüglich Stream <> Auswertung <> Rückmeldung? (Dann Entschuldige ich mich hierfür)
Meine Theorie würde vorsehen:
Möglichkeit in FaceStreamAI zum switchen zwischen Stream/Auswertung oder SnapShot/Auswertung:
Beispiel: Klingeln an der Intercom > Trigger an FaceStreamAI > FaceStreamAI macht ein Snapshot oder ein Bild wird übergeben > FaceStreamAI wertet Gesichtserkennung aus > FaceStreamAI gibt Rückmeldung ob "erkannt" oder "nicht" per UDP/MQTT
-
-
Das mit der Verzögerung hast du richtig erkannt. Das ist naturgemäß so. Der Ansatz mit einem Trigger wäre daher schon resourcenschonender. So wie du sagst: Auswahl zwischen Interval-Recognition und Trigger-Recognition. Der Ansatz war tatsächlich schon geplant. Da genügt es aber die bereitgestellte Stream-URL eben dann nicht permanent abzugreifen und interval-mäßig auszuwerten sondern erst wenn der Trigger kommt. Und dann wieder stoppen wenn x-Sekunden lang kein Gesicht erkannt wurde. Das ist dann natürlich hochgradig effizient. Du verstehst das generell richtig.Kommentar
-
Könnte man den Erkennungsprozess leistungsoptimiert auf z.B. eine Edge TPU auslagern, so wie man es z.B. mit Frigate machen kann ?
👍 1Kommentar
Kommentar