DeepCamera: eine Skill-Plattform für lokale Videoanalyse an Überwachungskameras

Welche Lücke DeepCamera schließt

Klassische NVR-Software zeichnet auf und zeigt ein Raster aus Videostreams. Sie beantwortet aber keine Fragen wie: Was ist in der Einfahrt passiert, während niemand zu Hause war? Wer eine solche Auswertung will, landet üblicherweise bei Cloud-Diensten, die Videomaterial auf fremde Server schicken. Genau dort setzt DeepCamera an. Das Projekt beschreibt sich selbst als Open-Source-Skill-Plattform für Kameras und verspricht, dass die gesamte Inferenz lokal läuft. Die Zielgruppe sind technisch versierte Anwender: Betreiber eines Mac Mini oder AI PC, die bereits Kameras und ein Netzwerk haben und nun Auswertung ergänzen wollen. Wer lediglich Bewegung erkennen und eine Aufnahme starten möchte, braucht diese Plattform nicht. Auch für den reinen Betrieb mehrerer Kameras ohne Analyse ist sie die falsche Wahl, weil der Analyse-Layer den Kern des Projekts bildet.

Frames, JSONL und der Frame Governor

Der Mechanismus ist im README als Diagramm dokumentiert und lässt sich klar nachvollziehen. Ein Kamera-Feed läuft in einen Baustein namens Frame Governor, der auf 5 FPS begrenzt. Der Governor schreibt das Bild als frame.jpg in ein gemeinsames Volume und schickt ein frame-Ereignis über stdin an den jeweiligen Skill. Der Skill liest das Bild, führt seine Inferenz aus und schreibt detections nach stdout. Dieses JSONL-stdin/stdout-Protokoll ist der eigentliche Trick: Aus Sicht der Plattform sind alle Detektions-Skills austauschbar, weil sie dieselbe Schnittstelle bedienen. Ein Wechsel von yolo-detection-2026 auf die Coral-TPU-Variante ändert nicht die Anbindung, nur den Backend-Pfad. Unterhalb dieser Schnittstelle liegt env_config.py, das Hardware erkennt und das passende Framework wählt: TensorRT für NVIDIA, CoreML für Apple Silicon, OpenVINO IR für Intel, ONNX für AMD und CPU. Der Coral-Pfad nutzt ai-edge-litert mit libedgetpu und fällt ohne angeschlossenen TPU auf die CPU zurück. Diese Trennung von Protokoll und Backend ist die tragfähigste Design-Entscheidung des Projekts.

Installation: zwischen CLI und Desktop-App

Das Repository beschreibt zwei Wege. Der eine ist der klassische: Docker und CLI, wobei das README diese Variante ausdrücklich als manuell bezeichnet. Der andere ist SharpAI Aegis, eine Desktop-Anwendung, die laut Projektbeschreibung die Umgebung per LLM einrichtet, Kamera-Skills konfiguriert und die Pipeline verwaltet. Aegis ist nicht Teil dieses Repositories, sondern ein separates Produkt, das auf der Projektseite zum Download angeboten wird. Wer den Quellcode kontrollieren will, muss also den CLI-Weg gehen. Konkrete Befehle nennt das vorliegende Material nicht, und ich habe sie auch nicht ausgeführt. Für die Skill-Ebene sind dagegen Dateien und Schlüssel benannt: Der Einstiegspunkt ist SKILL.md, die Parameter sind in docs/skill-params.md dokumentiert, das Entwicklungsprotokoll in docs/skill-development.md. Alle Skills sind in skills.json registriert, was eine programmatische Auflistung erlaubt. Wer einen eigenen Skill baut, muss sich an das frame- und detections-Schema halten, sonst greift die Austauschbarkeit nicht.

Der Skill-Katalog ist teilweise Zukunftsmusik

Die Statusspalte im Katalog ist die wichtigste Information des README und wird leicht überlesen. Fertig markiert sind yolo-detection-2026, die Coral-TPU-Variante, das home-security-benchmark mit 143 Tests, depth-estimation und sam2-segmentation. In Testing befindet sich yolo-detection-2026-openvino. Als geplant geführt werden unter anderem face-detection-recognition, license-plate-recognition, die Automatisierungs-Skills mqtt, webhook und ha-trigger sowie homeassistant-bridge. Das ist eine erhebliche Einschränkung. Wer eine Gesichtserkennung oder eine Home-Assistant-Anbindung als Kaufargument einplant, plant gegen eine Roadmap, nicht gegen vorhandenen Code. Die Roadmap-Zeile zu Skill Development ist zudem nicht abgehakt und nennt 19 Skills in 10 Kategorien als laufende Arbeit. Der Katalog ist damit eine Absichtserklärung mit einigen fertigen Teilen, nicht ein bestücktes Regal.

Wo die Plattform an ihre Grenzen stößt

Die 5-FPS-Begrenzung des Frame Governor ist eine bewusste Drosselung, aber sie hat Folgen. Ein VLM, das eine Szene beschreiben soll, arbeitet auf einzelnen Bildern. Eine schnelle Bewegung zwischen zwei Frames sieht es nicht, und für Szenen, in denen Sekundenbruchteile zählen, ist der Ansatz ungeeignet. Dazu kommt der Modellwechsel: Wer Qwen, DeepSeek, SmolVLM oder LLaVA lokal betreiben will, braucht Speicher und Rechenzeit, und die Qualität der Antwort hängt direkt von der Modellgröße ab. Das README nennt keine Speicheranforderungen und keine Latenzwerte, und ich habe keine gemessen. Ein weiterer Punkt ist die Abhängigkeit von Aegis für den komfortablen Betrieb. Wer den Desktop-Weg nicht will, trägt die Einrichtung selbst. Und schließlich: Die Lizenz des Repositories ist MIT, aber Aegis ist ein separates Produkt mit eigener Vertriebsform. Wer plant, die Desktop-App produktiv einzusetzen, muss deren Bedingungen getrennt prüfen. Das ist keine Rechtsberatung, nur ein Hinweis auf die Trennung.

Was andere anders machen

Frigate ist der naheliegende Vergleich, weil es ebenfalls lokale Objekterkennung an Kameras betreibt und die Ergebnisse in Home Assistant sichtbar macht. Der Unterschied liegt im Modell der Erweiterbarkeit. Frigate ist eine Anwendung mit einer festen Pipeline und einer überschaubaren Zahl an Konfigurationsoptionen; Detektion ist ein eingebauter Schritt, kein austauschbares Modul. DeepCamera dreht das um: Die Plattform ist im Wesentlichen ein Protokoll und ein Hardware-Abstraktionslayer, und die Fähigkeiten kommen als separate Skills mit eigenen Modellen und Parametern. Das ist flexibler, kostet aber Einarbeitung in das Skill-Format. Wer eine Erkennung mit wenigen Zeilen YAML will, ist bei Frigate besser aufgehoben. Wer verschiedene Detektoren, Segmentierung und ein VLM hinter derselben Schnittstelle betreiben will, findet bei DeepCamera eher das passende Modell. Die Wahl ist also nicht besser gegen schlechter, sondern starr gegen modular.

Wartung, Upgrades und der Blick auf die Versionen

Die Release-Historie zeigt eine Lücke: v3.4.3 stammt aus dem August 2022, danach folgen Aegis im Februar 2026 und v2026.3 im März 2026 mit dem Titel Skill Platform Milestone. Das Projekt wurde also nach längerer Pause wieder aufgenommen, und die aktuelle Struktur mit SKILL.md, skills.json und env_config.py ist jung. Das bedeutet für Betreiber, dass sich das Skill-Format noch bewegen kann und ein selbst geschriebener Skill bei einem Plattform-Upgrade Anpassungen brauchen dürfte. Der letzte Push liegt laut Repository-Metadaten im Juni 2026, das Projekt ist nicht archiviert. Für die Wartungskosten heißt das: Wer eigene Skills beisteuert, sollte sie gegen docs/skill-development.md geschrieben haben, damit ein Formatwechsel nachvollziehbar bleibt. Die MIT-Lizenz erlaubt Weitergabe und Änderung, verlangt aber die Beibehaltung des Lizenzhinweises. Wer DeepCamera in ein Produkt einbettet, muss diesen Hinweis mitführen. Für die mitgelieferten Modelle gilt das nicht automatisch, deren Lizenzen sind separat zu prüfen.

Redaktionelles Fazit

Wer lokale Videoanalyse auf eigener Hardware betreiben und Detektions-Backends austauschen will, findet in DeepCamera eine offen dokumentierte Skill-Struktur mit MIT-Lizenz. Wer eine fertige, stabile NVR-Lösung für den Produktivbetrieb sucht, sollte zuerst den Status der als geplant markierten Skills im Repository prüfen und erst dann über einen Einsatz entscheiden.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. SharpAI/DeepCamera on GitHub