Wie viele Kamerastreams kann ein Heim-NVR bei gleicher Erkennungsrate analysieren?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Ein heimischer NVR kann nur so viele Streams analysieren, wie sein Detektor und seine Videopipeline verarbeiten können, ohne die konfigurierte Erkennungsrate jeder Kamera zu verringern.

Wenn acht Kameras jeweils fünf Erkennungsbilder pro Sekunde anfordern, muss der Detektor nach Berücksichtigung des Overheads mindestens 40 Inferenzen pro Sekunde verarbeiten können. Doch auch Dekodierung, Größenanpassung, Tracking, Aufzeichnung und Bewegungserkennung beanspruchen CPU, GPU, Speicherbandbreite und I/O. Das tatsächliche Stream-Limit ist erreicht, sobald die Erkennungshäufigkeit pro Kamera oder die Ereignislatenz bei gleichzeitiger Aktivität im Haushalt nachlässt.

Der Erkennungsbedarf ergibt sich aus Streams multipliziert mit der Erkennungs-FPS

Die einfachste Mindestanforderung ist die Anzahl der Kameras multipliziert mit der konfigurierten Anzahl der Erkennungsbilder pro Sekunde. Zehn Kameras mit fünf FPS fordern 50 analysierte Bilder pro Sekunde an. Bewegungserkennung kann den tatsächlichen Arbeitsaufwand reduzieren, doch bei der Kapazitätsplanung sollten Zeiträume berücksichtigt werden, in denen viele Kameras gleichzeitig aktiv sind.

Das Projekt zur lokalen Objekterkennung trennt lokale Aufzeichnung von der Objekterkennung in Echtzeit und empfiehlt gegenüber einer rein CPU-basierten Erkennung eine dedizierte Beschleunigung. Diese Pfade belasten denselben Server auf unterschiedliche Weise.

Die Quell-FPS der Kamera entspricht nicht unbedingt der Erkennungs-FPS. Ein Aufzeichnungsstream mit 25 FPS kann einen Erkennungsstream mit fünf FPS speisen und so den Inferenzbedarf reduzieren, ohne die flüssige Aufzeichnung von Bewegungen zu beeinträchtigen. Eine Verwechslung der beiden Werte führt zu überhöhten oder unsicheren Kapazitätsschätzungen.

Dekodierung und Vorverarbeitung können zum früheren Engpass werden

Vor der Inferenz muss komprimiertes Video dekodiert, skaliert, in den richtigen Farbraum umgewandelt und an den Detektor übertragen werden. Hardwaredekodierung kann die CPU entlasten, doch Codec, Auflösung, Farbtiefe und die Begrenzung gleichzeitiger Sitzungen sind entscheidend. Aufzeichnungen und Transkodierung für die Live-Ansicht konkurrieren um dieselbe Pipeline.

Eine Übersicht über KI-Beschleuniger erklärt, dass Beschleuniger wiederholte Inferenzen mit geringerem Host-Overhead schneller als allgemeine CPUs ausführen können. Die Dekodierung muss die Bilder dennoch rechtzeitig liefern.

Ein schneller Detektor garantiert daher nicht automatisch mehr Kameras. Wenn die Bildwarteschlange vor der Inferenz wächst, bleibt zusätzliche Detektorkapazität ungenutzt. Wenn der Speicher blockiert, kann die Aufzeichnung beeinträchtigt werden, selbst wenn die Erkennungs-FPS korrekt aussieht.

Wo die Teilungsformel versagt

Die Division von Detektor-FPS durch die FPS pro Kamera setzt gleiche Modellkosten und unabhängige Bilder voraus. Zusätzliche Modelle für Gesichter, Kennzeichen, Posen oder Klassifizierung verursachen nur bei ausgewählten Erkennungen weiteren Aufwand. Kacheln mit variabler Auflösung und Remote-Streams können ungleichmäßige Kosten verursachen.

Eine Produkterklärung zur sekundären Erkennung weist darauf hin, dass sekundäre Erkennung die Pipeline verlangsamen kann, wenn Aufgaben erkannte Objekte nicht effizient gemeinsam nutzen. Die Auswahl der Merkmale verändert die Kapazität selbst bei gleicher Basis-FPS.

Die Schätzung versagt außerdem, wenn nicht der Durchsatz, sondern die Latenz das Limit darstellt. Ein Detektor kann durchschnittlich 60 FPS erreichen und dennoch eine Kamera gelegentlich um mehrere Sekunden verzögern, weil Warteschlangen nicht fair behandelt werden. Gleiche Durchschnittsraten garantieren keine gleichmäßige Reaktionsfähigkeit für jeden Stream.

-15% OFF

Streams hinzufügen, bis die langsamste Kamera nachlässt

Aktiviere die Kameras nacheinander mit ihrem endgültigen Codec, ihrer Auflösung, ihrem Aufzeichnungsmodus und ihrer Erkennungs-FPS. Löse in allen Ansichten gleichzeitig Bewegungen aus und erfasse die erreichte Erkennungs-FPS pro Kamera, das Alter der Bildwarteschlange, die Inferenzzeit, die Dekodierungsauslastung, verworfene Bilder, die Ereignisverzögerung und die Festplattenlatenz.

Führe den Test auf derselben Konfiguration des gemeinsam genutzten Video-Computers durch, auf dem Video- und KI-Dienste gemeinsam ausgeführt werden sollen. Deaktiviere unabhängige Aufgaben nur, wenn sie auch im Produktivbetrieb entsprechend eingeplant werden.

Behalte die höchste Kamerazahl bei, bei der der langsamste Stream mindestens 95 Prozent seiner konfigurierten Erkennungsrate beibehält und die p95-Ereignisverzögerung innerhalb des gewählten Zielwerts bleibt. Halte 20 Prozent Reserve bei der Detektor- und Dekodierungskapazität für gleichzeitige Bewegungen und sekundäre Modelle vor.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.