LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Blog-Übersicht /CCTV / Frigate und Coral TPU: Wie viele Kameras...
Diesen Artikel in anderen Sprachen lesen:

Frigate und Coral TPU: Wie viele Kameras ein Beschleuniger schafft

Frigate und Coral TPU: Wie viele Kameras ein Beschleuniger schafft
Inhalt
  1. Bereiche sind nicht einfach bewegte Objekte
  2. Ein Budget mit ausdrücklichen Annahmen
  3. Detektoren messen statt Kamerazahlen zuweisen
  4. Dekodierung, Erkennung und Aufzeichnung trennen
  5. Die richtigen Messwerte lesen
  6. Zwei PCIe-Detektoren als Konfigurationsausschnitt
  7. Fragen und Antworten
  8. Quellen

Eine Coral besitzt keine feste Kamerakapazität. Die Detektorlast hängt von der Zahl der Inferenzanfragen, dem gewählten Modell und der Dauer je Anfrage ab. Zusätzlich muss das System Video empfangen, dekodieren, Objekte verfolgen und Aufzeichnungen speichern. Ein Detektorbudget ist eine nützliche Schätzung, keine Garantie für die Erkennung jedes relevanten Objekts.

Bereiche sind nicht einfach bewegte Objekte

Frigate erkennt Bewegung, fasst benachbarte Bewegungsflächen zu Erkennungsbereichen zusammen und berücksichtigt bestehende Objektspuren. Ein Bereich kann mehrere Objekte enthalten; zwei sichtbare Bewegungsflächen führen nicht zwangsläufig zu zwei getrennten Inferenzen. Auch stehende Objekte werden regelmäßig kontrolliert. Eine ruhige Szene bedeutet deshalb weder null Systemlast noch zwingend null Detektorarbeit.

Maßgeblich ist die beobachtete Zahl tatsächlicher Inferenzaufrufe je verarbeitetem Erkennungsbild, einschließlich Bildern ohne Aufruf und Bildern mit mehreren Aufrufen. Dieser Faktor hängt von Bildausschnitt, Bewegung, Verfolgung, Masken und Konfiguration ab. Der folgende Wert 1,5 ist eine illustrative Annahme, kein gemessener Standardwert für Außenkameras.

Ein Budget mit ausdrücklichen Annahmen

Text
Angefragte Inferenzen/s = Summe(verarbeitete Bilder/s × mittlere Aufrufe/Bild)
Geschätzter serieller Detektorbedarf = Angefragte Inferenzen/s × ms/Inferenz

8 × 5 × 1.5 = 60 Inferenzen/s
60 × 8 ms = 480 ms/s = 48% eines seriellen Detektors

16 × 10 × 1.5 × 8 ms = 1920 ms/s = 192% angefragter Bedarf

Das Beispiel setzt einen seriell arbeitenden Detektor, acht mit 5 B/s verarbeitete Kameras, durchschnittlich 1,5 Inferenzaufrufe je verarbeitetem Bild und 8 ms je Aufruf voraus. Daraus ergeben sich 48 Prozent geschätzter Detektorbedarf. Das ist keine Messung von CPU-Auslastung, Gesamtlatenz oder Aufzeichnungskapazität. Auch die 8 ms sind hypothetisch; maßgeblich ist der Messwert des gewählten Modells auf dem tatsächlichen Host.

Das Beispiel mit 192 Prozent verlangt mehr serielle Arbeit, als in eine Sekunde passt. Daraus folgt nicht, dass genau die Hälfte aller Videobilder verworfen wird. Warteschlangen, Verzögerungen und übersprungene Bilder hängen von Verarbeitungskette und Last ab. Bei Sättigung kann die beobachtete Fertigstellungsrate den angefragten Bedarf außerdem unterschätzen.

Gleichzeitige Aktivität ist aussagekräftiger als ein Tagesmittel. Sinnvolle Versuche umfassen mehrere bewegte Objekte, Wind, wechselndes Licht und Nachtbilder. Selbst unter 100 Prozent bleibt Reserve für Schwankungen und andere Arbeit nötig. Kein allgemeiner Prozentsatz garantiert eine zuverlässige Objektverfolgung.

Beispielbudget: 60 Inferenzaufrufe je Sekunde benötigen bei angenommenen 8 ms insgesamt 480 ms serielle Detektorzeit. Modell, Szene und Verarbeitungskette benötigen reale Messungen.
Beispielbudget: 60 Inferenzaufrufe je Sekunde benötigen bei angenommenen 8 ms insgesamt 480 ms serielle Detektorzeit. Modell, Szene und Verarbeitungskette benötigen reale Messungen.

Detektoren messen statt Kamerazahlen zuweisen

Die Inferenzzeit hängt von Modell, Eingabeabmessungen, Laufzeitumgebung, Host, Verbindung und Betriebsbedingungen ab. Eine allgemeine Tabelle mit 7 ms für PCIe, 8 ms für USB und festen Kamerazahlen würde diese Abhängigkeiten verdecken. Zwei kompatible Coral-Detektoren können über eine gemeinsame Warteschlange Kapazität ergänzen, verdoppeln aber nicht garantiert die Leistung der gesamten Anlage.

Die Schätzung für einen seriellen Detektor ist kein allgemeiner GPU-Benchmark. Manche GPU-Verfahren verarbeiten Aufgaben parallel. Frigates einfacher TensorFlow-Lite-CPU-Detektor wird nicht für den allgemeinen Einsatz empfohlen; OpenVINO im CPU-Modus ist eine andere Möglichkeit. Die Kernzahl allein bestimmt bei keiner Variante die Inferenzzeit.

Dekodierung, Erkennung und Aufzeichnung trennen

Die Coral übernimmt Modellinferenzen, keine Videodekodierung. FFmpeg kann dafür unterstützte GPU- oder Medienhardware mit einem geeigneten Frigate-Preset verwenden. Eine feste Angabe wie ein CPU-Kern je 4K-Kamera lässt sich nicht auf beliebige Codecs, Hardware und Ströme übertragen.

Ein niedriger aufgelöster Strom für Erkennung und der Hauptstrom für Aufzeichnung sind oft sinnvoll. Die Erkennungsauflösung muss trotzdem ausreichend Details für kleine oder entfernte Objekte bewahren. Frigate schneidet Bereiche aus und skaliert auf die Modelleingabe; eine kleine Modelleingabe belegt nicht die Eignung jeder niedrig aufgelösten Quelle.

Bei Aufzeichnung mit Videostream-Kopie braucht der Kopiervorgang selbst keine Dekodierung und Neukodierung des Videos. Zusätzliche Anzeige-, Transkodierungs- oder Analysepfade können Arbeit ergänzen. Schnappschüsse stammen aus dem Erkennungsstrom. Vorzugsweise liefert bereits die Kamera die gewünschte Bildrate dieses Stroms: Eine Reduzierung nur von detect.fps kann den Dekodieraufwand zusätzlicher Eingangsbilder bestehen lassen.

Die richtigen Messwerte lesen

frigate_detection_fps zählt Detektorläufe je Sekunde und entspricht nicht einfach der eingestellten Bildrate. Ein niedriger Wert in ruhiger Szene ist normal und beweist keinen Bildverlust. Kamera-, Verarbeitungs- und Auslassungsrate beschreiben unterschiedliche Stufen. Zunehmend übersprungene Bilder oder sinkende Verarbeitungsraten bei realistischer gleichzeitiger Last erfordern einen Abgleich mit Detektorzeit, CPU/GPU-Last, Speicher, Protokollen und tatsächlicher Objektverfolgung.

Die Prometheus-Metrik frigate_detector_inference_speed_seconds verwendet Sekunden. Der Wert 0,008 entspricht 8 ms. Eine längere Inferenzzeit allein beweist keine thermische Drosselung: Modellwechsel, Konkurrenz auf dem Host sowie Stromversorgungs- oder Verbindungsprobleme sind weitere Ursachen. Auch ein fehlendes Ereignis belegt keine Detektorsättigung; Konfidenz, Masken, Zonen und Aufbewahrungsregeln gehören zur Prüfung.

Zwei PCIe-Detektoren als Konfigurationsausschnitt

YAML
detectors:
  coral1:
    type: edgetpu
    device: pci:0
  coral2:
    type: edgetpu
    device: pci:1

Dieser Ausschnitt setzt zwei verfügbare Geräte voraus und erzeugt keinen zweiten Beschleuniger. Hosttreiber und Containerzugriff müssen beide relevanten Geräteknoten bereitstellen, häufig /dev/apex_0 und /dev/apex_1. Für zwei USB-Corals lauten die Kennungen usb:0 und usb:1. Jeder Detektorprozess bezieht Aufgaben aus der gemeinsamen Kamerawarteschlange. Der Ausschnitt ist keine vollständige Frigate- oder Docker-Konfiguration.

Fragen und Antworten

Senken Masken die Last ohne Erkennungsverluste?

Kleine Bewegungsmasken können irrelevante Bewegung unterdrücken, etwa eine eingeblendete Uhrzeit. Zu große Masken können die Verfolgung erschweren. Ein maskiertes Objekt kann weiterhin erkannt werden, wenn ein anderer Auslöser einen Bereich mit diesem Objekt erzeugt; Bewegung irgendwo anders garantiert keine vollständige Prüfung aller maskierten Flächen. Bewegungsmasken sind keine Datenschutzverpixelung und entfernen Objekte nicht zuverlässig aus Aufzeichnungen.

Was ändern die Einstellungen für stehende Objekte?

Die dokumentierte Standardschwelle beträgt das Zehnfache der Erkennungsbildrate, bei 5 B/s also 50 Bilder. Ein Stillstandsintervall von 50 prüft nach jeweils 50 verarbeiteten Bildern erneut, bei 5 B/s etwa alle zehn Sekunden. Bei 3 B/s entsprechen dieselben 50 Bilder ungefähr 16,7 Sekunden. Tatsächliche Einstellung und erreichte Verarbeitungsrate sind maßgeblich. Die Funktion reduziert wiederholte Inferenzen, beseitigt aber nicht jede Prüfung.

Spart eine Reduzierung von 5 auf 3 B/s 40 Prozent?

Nur im Beispielmodell mit unverändert 1,5 Aufrufen je Bild und 8 ms je Aufruf: Der Bedarf sinkt von 480 auf 288 ms/s und damit um 40 Prozent. Reale Bereichsbildung und Verfolgung können sich ändern. Weniger Bilder bieten zudem weniger Erkennungsgelegenheiten für kurz sichtbare Objekte. Versuche in der Debugansicht zeigen, ob die niedrigere Rate weiterhin geeignet ist.

Wie lässt sich die USB-Verbindung prüfen?

Unter Linux zeigt lsusb -t die ausgehandelte Verbindungsgeschwindigkeit. Beim betreffenden Coral-Zweig bedeutet 5000M eine SuperSpeed-Verbindung mit 5 Gbit/s und 480M eine USB-2.0-High-Speed-Verbindung. Buchsenfarbe und eine Inferenzmessung von 8 oder 22 ms ersetzen diese Prüfung nicht. Kabel, Hub und Stromversorgung spielen ebenfalls eine Rolle. Die Coral wechselt bei der Initialisierung die USB-Kennung; die Durchreichung muss diesen Wechsel unterstützen. Frigates Docker-Beispiel reicht den USB-Bus durch und gewährt damit Zugriff auf mehr als ein einzelnes Gerät.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Eine Frage oder eine Idee für ein Webprojekt? Schreib mir kurz, worum es geht. Das Formular nutzt reCAPTCHA zum Schutz vor Spam.

Kommentar schreiben

Erfahrungen mit anderen Kameras, Objektiven oder Rekordern und Rückfragen zur Einrichtung sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.