Up to four channels, no repeats
Push and email, plus SMS and an on-site siren once they are set up for the site. Each person picks their channels, and an incident alerts once however long it lasts.
Technology
How AnomaEYE turns video into reviewable alerts.
What runs today: the media pipeline, the detection model and the verifier that checks it, how alerts are delivered, how data is protected, and where the limits are.
Architecture
From camera to alert in six stages.
Viewing and detection are separate paths, so nothing heavy sits between a camera and the person watching it.
- RTSP
01Camera
A supported IP camera on your network provides a standard RTSP stream.
- SRT / RTMP
02Site agent
A small agent on site relays the stream out without re-encoding it, so no inbound ports are opened.
- MediaMTX
03Media server
Receives each stream, produces viewing renditions and keeps a five-minute rolling buffer.
- v4 ensemble
04Scene model
On a GPU inference server, scores every second of video and opens a candidate event when the anomaly score reaches 0.50.
- Qwen3-VL
05Verifier
A vision-language model looks at 8 frames from each candidate, confirms or vetoes it, and writes a one-sentence description.
- FastAPI
06Incident and alerts
A published event becomes one incident with an evidence clip, sent to each person's chosen channels and opened on web or Android.
Detection model · v4
A scene model that proposes, and a verifier that checks.
The scene model reads video through two frozen encoders. X3D-M captures how things move; InternVideo2-CLIP captures what is in the frame. A causal temporal transformer combines them using only footage it has already seen, so it works on live video. Eight of these models are averaged into one ensemble.
Every second, the ensemble gives an anomaly probability, a coarse group and one of 13 crime classes. When the probability reaches 0.50, a candidate event opens.
Before any alert goes out, the Qwen3-VL vision-language model looks at 8 frames from the candidate, confirms or vetoes it, and writes the one-sentence description your team reads. The event is published if the verifier agrees, or if the scene model's peak score is 0.86 or higher. If the verifier is unavailable, the scene model publishes on its own at a stricter 0.84.
Groups
- Violence
- Weapon
- Fire
- Vehicle
- Theft
- Other incident
Crime classes
- Abuse
- Arrest
- Arson
- Assault
- Burglary
- Explosion
- Fighting
- Road accidents
- Robbery
- Shooting
- Shoplifting
- Stealing
- Vandalism
The 13 classes come from the UCF-Crime dataset. The group is the dependable signal; the class is right about half the time.
Held-out results
Public test sets never used for training or calibration. An event counts as caught if an alert overlaps it within 5 seconds.
| Test set | Events caught | False alerts / hour |
|---|---|---|
| UCF-Crime290 videos | 59.6% | 0.50 |
| MSAD240 multi-scene CCTV videos | 69.2% | 3.63 |
| CamNuvem49 robbery CCTV videos | 100% | 0.00 |
What the verifier adds
UCF-Crime, both at 0.5 false alerts per hour.
- Scene model alone
- 28.8%
- With the verifier
- 59.6%
The previous model caught 46.8% of UCF-Crime events at 0.17 false alerts per hour, and 25.2% of MSAD events. These public sets are small, so results on your cameras will differ; a pilot measures that.
Alerts and evidence
One incident, one alert, one clip.
Evidence from the buffer
The media server keeps the last five minutes, so the clip saved for an incident includes the moments leading up to it.
Low-latency live view
WebRTC carries live video to the browser and the app, with HLS as the fallback where WebRTC is blocked.
Security and privacy
Built to keep each organization's data its own.
Detection reads movement and behavior. Facial recognition is not part of the workflow.
Verified sign-in
Every request carries a signed identity token that the server checks.
Isolated organizations
Each organization's data lives under its own path; one can never read another's.
Roles checked live
Permissions are looked up on every request, so removing someone takes effect at once.
Re-authentication for risky actions
Destructive changes require a sign-in within the last 15 minutes.
Private evidence
Clips sit in a private bucket and open only through links that expire after 30 minutes.
Audit trail
Administrative actions are recorded per organization.
Deployment
A hosted service with small agents on site.
AnomaEYE runs as a hosted service on Google Cloud. Detection runs on a separate GPU inference server, not on your cameras or site hardware.
Cameras behind a firewall
The site agent connects outward, so cameras never need to be reachable from the internet.
The on-site siren
A second agent on the local network picks up siren commands and triggers the device, because the cloud cannot reach a private address.
Hosting region
The service and its database share one region, which keeps every request fast.
Limitations
What it doesn't do well yet.
Knowing the limits is part of deploying it responsibly.
Naming the crime is the weakest part. The group (violence, weapon, fire, vehicle, theft or other incident) is reliable; the specific crime class is right about half the time.
Short, subtle events involving a single person can be missed.
The public test sets are small, and camera angle, lighting, resolution and crowding all change results, so we recommend a pilot before rollout.
An alert is a prompt for review, not a finding. A trained person should check every alert before anyone acts.
If the verifier is unavailable, the scene model alerts on its own at a stricter threshold, so fewer events are caught until it is back.
The mobile app is Android only for now. It is downloaded directly as AnomaEYE.apk and is not yet on Google Play.
The service runs in one region without automatic failover. That suits pilots, not yet large rollouts.
Research directions
Being explored, not in the product.
These come from the project's original research scope. None of them is part of AnomaEYE today.
Pose-based interaction cues
Hand-to-pocket, item-transfer and escape patterns from body keypoints, to catch subtle theft the current categories miss.
Cross-camera re-identification
Following one person between cameras without storing who they are.
Lighter models for site hardware
Smaller models that could run closer to the cameras and cut bandwidth.
Technical questions
Bring your camera setup. We'll walk through it.
Stream formats, network access, detection scope and what a pilot would measure.