Bewegungserkennnung: gespeichertes Video teils unbrauchbar

HD Kameras IN-6012 HD
1

Ich habe die Bewegungserkennung bei der 6012 getestet:

  • einen Bereich definiert
  • diesen aktiv geschaltet
  • eingestellt, daß Video-Sequenzen bei Bewegungserkennung auf die SD-Karte gespeichert werden sollen

Zunächst funktioniert das: Bewegung wird erkannt, Video wird gespeichert. Insgesamt werden manchmal 4 Sekunden Video gespeichert; manchmal sind es auch über 10 Sekunden.

Spiele ich nun eines der aufgezeichneten AVIs mit VLC ab, sehe ich zunächst ca. 2 Sekunden „Dunkel“ - dann setzt auf einmal das Bild ein. Gerade bei schnellen Objekten im Sichtfeld ist das deutlich zu spät - oft sehe ich das Objekt dann gar nicht mehr, welches den Alarm ausgelöst hat…

Ich vermute, daß die Kamera bei einem Alarm einfach den aktuellen Videodatenstrom abgreift und speichert. Zufälligerweise kann die Alarmaufzeichnung zu einem Moment beginnen, an dem gerade ein Keyframe erzeugt wurde - es aber schon „vorbei“ ist (also nicht mehr zum Speichern zur Verfügung steht). Hat man die „Keyframe all XX Frames“ Einstellung dann z.B. auf den Werks-seitigen „50“, dauert es bei 25 fps bis zu 2 Sekunden, bis die Aufnahme brauchbar wird. Bei geringeren fps-Raten noch länger.

Der Prozess, welcher das H.264 Encoding macht - ich vermute, die Hardware (Hi 3510?) - weiß scheinbar nichts von einem Alarm - und macht deshalb auch kein zusätzliches Key Frame an den Anfang der Alarmaufzeichnung…

Sollte die Bewegungserkennung (zusätzlich zum H.264 Encoding) auch von der Hardware gemacht werden, halte ich dies für einen „Designfehler“ des SoC… Der „weiß“ intern ja vom Alarm … und müsste ein außerplanmäßiges Key Frame generieren.

Ich habe dann die Einstellung testweise auf „alle 5 Frames ein Key Frame“ gestellt … und… voilà: die Aufzeichnungen sind durchweg von Anfang an brauchbar.

Im Werks-Lieferzustand stehen übrigens alle 3 Video-Streams auf „Key frame alle 50 frames“. Sicherlich eine sinnvolle Einstellung - soll ja Bandbreite reduzieren. Insbesondere wenn man Areale überwacht, in denen Minuten/Stunden-lang keinerlei oder nur geringe Veränderungen im Bild sind, macht es keinen Sinn, alle 5 Frames ein Key-Frame zu generieren. Gerade hier soll ja H.264 seine Vorteile (nur Codierung der Differenz zwischen 2 Frames) im Vergleich zu MJPEG ausspielen.

Ein dauerndes Herabsetzen auf 5 oder noch weniger Frames pro Key Frame ist also keine Lösung.

Eine mögliche Lösung wäre: Eine Design-Änderung des SoC (sofern dieser die Bewegungserkennnung macht) oder der Kamera-Software (sofern dies die Bewegungen erkennt). Allerdings ist das eher ein Zukunftsthema (es sei denn, der SoC verfügt über eine Art ladbaren (Mikro-)Code und diese Designänderung wäre damit nachträglich möglich).

Eine schnellere Lösung könnte evtl. durch die Kamera-Software erfolgen:

Die puffert scheinbar den Video-Datenstrom … oder müsste ihn puffern … und wenn der SoC einen Alarm meldet (oder die Kamera-Software ihn selbst durch Bildanalyse feststellt), müsste einfach ein längerer Vorlauf aufgezeichnet werden.

Die Kamera-Software kennt ja die aktuellen Einstellungen bzgl. Key-Frames und Frame-Rate … Der Vorlauf muss dann einfach nach folgender Formel berechnet werden:

fps-Einstellung (Frames/Sekunde) / Key-frame-Einstellung = Sekunden Vorlauf (Minimum).

Dazu noch einen Sicherheitszuschlag von 10 Frames oder besser gleich 1-2 Sekunden …

—> Liege ich mit meiner Theorie zum Problem richtig?

Neo

2

Vielen Dank für das Feedback.

Wir freuen uns stehts wenn wir Infos und Rückmeldungen erhalten um die Kameras entsprechend zu verbessern.

In der Tat sollte sich die Bewegungserkennung dementsprechend verbessern lassen. Ich werde es den Kollegen der Software einmal zukommen lassen um prüfen zu lassen was im überschaubaren Zeitrahmen zu realisieren geht. Gerne posten wir die Infos hier sobald es Änderungen in der Firmware gibt.

3

Danke.

Am besten gleich noch mitprüfen lassen, inwieweit die Aktivierung / Deaktivierung des IR Cut Filters bei der Bewegungserkennung berücksichtigt wird:

Normalerweise wird es ja abends/morgens langsam dunkler/heller… je nach eingestellter Sensivität sollte die Bewegungserkennung da keine Änderung melden, wenn die Sonne auf/untergeht.

Wird aber der IR Cut Filter (samt IR-Nachtmodus) zu/abgeschaltet, ändert sich schlagartig das ganze Bild…

Ich habe diesbezüglich noch keinen Test durchgeführt - könnte aber sein, daß das zu regelmäigen Falschmeldungen führen wird, wenn die Bewegungserkennung nicht beim Wechsel IR Cut an/aus „pausiert“ …

Übrigens: bei meiner Synology Surveillance Station kann ich neben einer Sensivität noch einen „Threshold“ wählen (und ausgegraut gibt es noch „Object Size“ und „Trigger percentage“.

Hier die Erklärungen dazu:

Detection sensitivity: The sensitivity of motion detection. If you set a smaller value, motion detection will be less sensitive and will only be triggered when the calculated difference between a series of frames is larger than the specified value.

Threshold: The threshold of motion detection. If you set a larger threshold, motion detection will be triggered when there is larger motion, or when the calculated difference between a series of frames exceeds the specified threshold.

Object size: The size of the object. If you set a larger value, motion detection will be triggered when there are larger moving objects. If you set a smaller value, smaller moving objects could trigger motion detection.

Trigger percentage: The percentage of the object in the view. If you set a larger value, motion detection will be triggered when there are larger moving objects. If you set a smaller value, smaller moving objects could trigger motion detection.

—> ich kann mir vorstellen, daß man mit nur einer Einstellmöglichkeit nicht alle Anforderungen abdecken kann.

Wenn die Einstellung einer „Sensivität“ nur auf den Anteil Bildpunkte abstellt, die sich von einem Bild zum anderen verändern, dann würde ein „Rauschen“ im Bild (z.B: beim Durchzug von Wolken) genauso zum Auslösen führen wie ein einzelnes größeres Objekt, welches das ansonsten (auch in Bezug auf Rauschen/Helligkeit) unveränderte Bild durchwandert. Letzteres will man gemeldet haben, ersteres meist nicht.

Vermutlich ist die Bewegungserkennung bei der 6012 aber dahingehend nicht änderbar, da durch die Hardware (SoC) gemacht. Vielleicht berücksichtigt dieser Prozessor aber auch mehrere Einflussfaktoren/Parameter (Umfang der Änderungen, Zeitraum der Änderungen, Objektgröße der Änderungen), die er auf einen einzelnen Parameter (den im WebUI) nicht-linear abbildet…

4

Zu diesem Thema „Keyframe am Beginn der Alarmaufnahme“ würde mich der aktuelle Status interessieren, wobei ich eine 5907 habe - aber ich vermute mal, Problem und Lösung ist bei beiden Kameras gleich.

Ein zusätzliches Keyframe abzuspeichern wäre natürlich ideal, ich schätze aber mal, aufgrund des Vorlaufs nicht einfach machbar. Alternativ sollte man im WebUI beim KeyFrame-Setting auf die Bedeutung und Auswirkung hinweisen. Keyframes größer 2 x FPS machen bei Verwendung der Alarmfunktion keinen Sinn, die Werteauswahlliste geht aber viel höher rauf. Beim Herumexperimentieren hatte ich schon komplett unbrauchbare Alarmvideos (wollte die Größe minimieren und hab FPS 4 und Keyframe 100 verwendet).

Was meines Erachtens einfach machbar wäre, wenn die Alarmfunktion aktiviert wird, dann Keyframe-Intervall automatisch auf den FPS-Wert setzen. Damit geht max. 1 Sekunde flöten und die deckt der Vorlauf ab.
Günstig wäre auch, bei der Auswahl des Vorlaufs für die Alarmaufzeichnung mit dem nächsten Keyframe zu beginnen - alles davor ist ohnehin nicht brauchbar.

Insgesamt finde ich die WebUI in diesen Belangen relativ unverständlich, weil die Settings aus meiner Sicht nicht ausreichend erklärt werden. Bei meinem Router (TP-Link MR3420) ist in der Konfig-GUI rechts immer eine gute Erklärung für jedes Setting angezeigt, so fände ich es hierfür auch ideal.

Schöne Grüße

5

gibt es hierzu vlt. noch eine Antwort?