Computer Vision · AI · Security
CCTV Anomaly AI
Real-Time Surveillance Intelligence
My roleI built the system through four phases, from a single-camera prototype to the multi-camera production MVP.
The situation
A security team watches 8+ camera feeds. They need to know about restricted-zone entry, loitering, crowd surges and unattended objects the moment they happen, without someone staring at every screen.
The hardest part was not detection. A system that pages security 20 times a shift with false alarms trains people to ignore the real one.
- Eight simultaneous feeds on a single NVIDIA T4.
- Alerts with evidence, fast enough to act on.
- Operators must be able to change zones and rules without a deploy.
System architecture
- IP cameras8+ live feeds
- Frame decodeFFmpeg · OpenCV
- DetectionAIYOLOv891% accuracy
- Multi-object trackingAIper-object IDs
- Anomaly enginezones · dwell · density35% fewer false alerts
- Evidence storesnapshots · PostgreSQL
- Operator dashboardWebSocket alerts
Architecture decisions I made
- D1INT8-quantised YOLOv8s, batched across camerasOne frame from each camera is batched into a single inference call. Quantised, YOLOv8s reached 8.4 FPS per camera on one T4, enough for behavioural rules.
- D2Rules in YAML, zones in the databaseEach rule names a camera, zone, object class, condition, threshold and severity. Changing what counts as an anomaly needs no code change or redeploy.
- D3Kill false positives before shipping anything elseTemporal debouncing (a rule must hold for N frames) plus a 0.6 confidence floor took the false-positive rate from 23% to 4% between phases 2 and 3. Staff went from ignoring the system to relying on it.
- D4Pub-sub alert deliveryThe rules engine publishes to Redis; a delivery service pushes to dashboards over WebSockets with a pre-cropped snapshot, decoupling detection from delivery.
In practice
One rule, one alertillustrative example, real schema
- RuleOperators define behaviour as data, not code.
camera: lobby-cam-2 zone: restricted-door class: person condition: dwell threshold_seconds: 30 severity: high - DetectBatched YOLOv8 inference finds a person; ByteTrack keeps the same ID across frames.
- EvaluateThe dwell timer passes 30 s for N consecutive frames above 0.6 confidence.
- AlertPublished to Redis, pushed to the security dashboard with a highlighted snapshot.
Measured in production
What I took away
- Detection is the starting point. Tracking, rules and false-positive control are the product.
- Solve false positives first; everything else is infrastructure.
Questions about this project
What problem did CCTV Anomaly AI solve?
A security operation needed automatic detection of crowd surges, loitering, intrusion and fights across many cameras, without an operator glued to every screen and without alert fatigue.
Who built CCTV Anomaly AI, and how does it work?
I did (Qalab Hassnain Agha). I built the system through four phases, from a single-camera prototype to the multi-camera production MVP. How it works: YOLOv8 detection and multi-object tracking with a custom anomaly engine (per-zone dwell, red-zone entry, crowd density), snapshot evidence per alert and WebSocket push to an operator dashboard. Evolved over four phases from prototype to production MVP. Stack: YOLOv8, OpenCV, FastAPI, Python, PostgreSQL, WebSockets, Docker, FFmpeg.
What results did CCTV Anomaly AI achieve?
91% detection accuracy in production conditions. 8+ simultaneous camera feeds in real time. 35% fewer false positives.
Can I hire Qalab to build something similar to CCTV Anomaly AI?
Yes. Contracts from $25 an hour, full-time remote from $3,000 a month, fixed-price prototypes from $600 and builds from $2,000, and fractional CTO retainers from $800 a month. Book a free 30-minute call and I will tell you honestly whether and how I would build it.