Why video analytics does not find events at a site
Cameras are installed at the site, the archive is being recorded, but the needed clip is not there when an incident is being reviewed.
A typical cause is a motion detector: it triggers on swaying branches, shadows from headlights, snow and insects near the lens, but not on crossing the perimeter or an object left at the gate.
The operator receives dozens of false triggers per shift and stops looking at them — missed events become the norm, not a failure.
The second layer of the problem is coverage geometry. Camera blind spots are almost always at gates, turnaround areas and building end walls, while at the boundaries of coverage zones a person's transition between cameras is not tracked at all.
The night shift adds noise and loss of detail: the trigger threshold is raised, and real events are lost along with false ones.
Industry review on intelligent video surveillance estimates the share of incidents that do not become events as significant — and it hardly decreases no matter how many cameras are added.
Video surveillance at a site provides recordings but not actionable events — that is exactly where the value of the system is lost.
We explain how this is addressed: from defining the detection task to configuring zones, thresholds and rules by which the system gives the operator an event rather than a stream of images.
What video analytics delivers at a site: measurable effects
The detector runs at the site, not in the cloud: the camera stream is filtered on site, and the security post receives not frames but ready events with type, camera and timestamp.
Fewer false triggers and missed events
Previously, the detector triggered on motion in the zone: shadows, rain, headlights and swaying branches accounted for most alarms.
The YOLO detection model, fine-tuned on frames from a specific site, reduces the share of false triggers severalfold — a shift leaves a few confirmed events instead of hundreds.
At the same time, the class of failures "event not recorded" disappears: event recognition follows scenarios — crossing a perimeter line, an abandoned object, a crowd gathering — rather than motion in the frame.
Security response instead of archive review
With ordinary video surveillance, an incident is learned about after the fact: security opens the archive and manually checks the interval.
An alert with camera, timestamp and event type arrives in real time, so security response time drops from dozens of minutes of viewing to seconds — by the time they arrive on site, the picture is already clear.
The operator monitors more cameras
The operator's workload decreases not by abandoning monitoring but through prioritization: they process the event queue by importance and monitor more cameras than with manual tile viewing. Some routine checks are removed entirely — the event is already described and has a clip attached.
Video analytics deployment options: on site, in the cloud, hybrid
The deployment method determines not the accuracy of the model but the communication channel requirements, privacy of frames and system behavior when the network goes down. Below is a comparison of four schemes that are actually chosen between at project start.
| Option | When it fits | Limitations |
|---|---|---|
| On-site computing | Dense stream, sensitive data, unstable network | Compute module at each site and model update procedure |
| Cloud processing | Unified control over the camera fleet, readiness for a permanent channel | Frames go outside, sensitivity to latency, outgoing traffic grows |
| Hybrid scheme | Detection on site, analytics and archive in the center | More complex synchronization of events and model versions |
| Fine-tuning on an existing camera fleet | Cameras are already installed, a new model is needed without replacing equipment | Dependence on camera angles and quality, some scenes will require additional equipment |
On-site processing
What goes outside is not frames but event metadata, so privacy is ensured by design rather than by access settings.
If communication breaks, detection continues to work locally: events are buffered and go to the center after the channel is restored — monitoring is not interrupted.
Hybrid scheme
Detection remains on site; aggregation, archive search and retraining are in the center. The channel must be stable but narrow: an event and a short clip instead of the full stream.
If communication breaks, the site is autonomous, and model version divergence is closed by deferred synchronization.
How implementation proceeds: from survey to handover
The work sequence is structured so that each stage relies on data from the previous one: rework during deployment costs many times more than refinement during the survey, so we do not shorten the first two steps even under tight deadlines.
- Site survey. We walk the territory together with security and facility operations: we record camera angles, blind areas, night lighting and points where flows of people and vehicles intersect.
- Coverage zone and scenario plan. On the plan we mark zones of interest and lines whose crossing is considered an event: perimeter, gates, warehouse, cash area. For each zone we define its own scenario — crossing, staying longer than a specified time, gathering.
- Deployment and stream connection. We calculate how many cameras one compute node supports, what margin remains for peak scenes and how the system behaves if communication with the recorder breaks.
- Model configuration for the site. We select sensitivity thresholds and filters by object class, mask areas with glare, shadows and reflections — otherwise the shift will drown in false triggers.
- Test run. We run the archive for a representative day and the live stream during peak hours, calculate the share of misses and false alarms, and return to settings if needed.
- Handover and security training. We hand over the response procedure for each event type, review typical triggers and stay in contact for the first weeks of operation.
Working with already installed cameras
The camera fleet is more often already installed, and it does not need to be replaced entirely: we check what the existing angles can support and cover what is missing in a targeted way — with two or three cameras at problem points.
Validation on real events
We run incident recordings already held by the security service through the configured system and compare: how many events were detected, what was missed, how many were false. We fix the final thresholds in the configuration so that the result does not depend on who is on shift.
Package of settings, plans and procedures after implementation
After commissioning, the site retains not only working video analytics but also a set of decisions made during the project. Without it, a month later no one will remember why the zone is bounded in that particular way and why the trigger threshold is set to a specific value. Below is the package we hand over together with the system.
Scenario configuration and zone map
- Scenario configuration: a list of rules with trigger thresholds, zones of interest and schedule — which rule is active on which shift and under which lighting conditions.
- Zone and blind area map linked to the site plan: where the view is blocked by racks, where a sector falls out of the field of view and how this is compensated by neighboring cameras.
- Alert procedure: who receives the signal, in which channel, within what time and by what criterion an event is recognized as false.
Access policies for recordings
- Role matrix: who can view the stream, who exports a clip, who approves export and how each export fact is recorded in the log.
- Retention periods and archive depth by camera type, the deletion procedure after expiry and the rules for retrieving a clip on request.
Documentation and shift instructions
- Operator and security instructions: review of typical events, procedure for responding to a trigger, escalation and behavior when a camera fails.
- Retraining procedure: for which changes at the site — new equipment, rearrangement, different workwear — the model is retrained and how the result is checked on a holdout set.
Case study: video analytics in a warehouse, metrics before and after
Initial situation
A warehouse complex with four storage zones, a perimeter and loading gates was covered by cameras, but analytics ran on a motion detector.
During a shift the operator received dozens of false alarms: the shadow of a passing forklift, glare on racks, motion in the frame from a draft.
A real perimeter violation drowned in this stream, and incident review was retrospective — scrolling through the archive by time after the shift had already ended.
A separate problem was the storage zones. The system did not distinguish an employee walking down an aisle from one who entered the order picking zone. Events arrived in a single list, without binding to a specific zone or a clear picture of what happened.
We changed the object detection model to a current branch and applied zone rules configured for the warehouse layout on top.
Object tracking across frames confirms an event by several consecutive hits and filters out single triggers, so a perimeter violation and entry into a storage zone became different event types with their own alert logic.
Result after implementation
Metrics were taken before and after on the same loop, so they are directly comparable — both points are recorded by the Acceptance Measurement Protocol.
- False alarms per shift: dozens → a few; the operator views only confirmed events.
- Incident review time: from half an hour of archive scrolling to two or three minutes using an event card with a ready clip.
- Perimeter violations: the share recorded with video confirmation grew from a third to almost all.
- Storage zones: each event has a specific zone and type; manual archive search is no longer needed.
The alert stream became predictable, and incident review stopped being a separate task for the shift: the shift operator handles it as part of the workflow, without distracting the duty engineer.
How does live stream review differ from archive review?
The modes differ in where the frame comes from and when the decision is made.
In real time the stream comes from the camera, a YOLO-family detector processes not every frame — the analysis step is selected to match the pace so the queue does not grow, and the event goes to the security console within seconds.
Archive review is the inverse task: recordings are already on disk, so every frame can be processed, sensitivity can be raised and tracks can be stitched forward and backward.
The price is alert delay: the result appears hours later, and a response based on it is no longer possible.
| Mode | What it provides | Limitations |
|---|---|---|
| Real time | Alarm within seconds, automatic launch of security procedure | Frame-skipping analysis, coarser threshold — the share of false triggers grows |
| Archive review | Full frame-by-frame processing, fine thresholds, retrospective search | Alert delay — hours; review only after the fact |
| Mixed | Online trigger plus buffer-based refinement and nightly re-analysis | Higher load on the compute unit, more complex configuration of zones and rules |
The mixed mode is assembled when both response and accuracy are needed: the online detector produces a draft event using a coarse threshold, disputed tracks are rechecked against the ring buffer for the last minutes, and at night the same material is re-analyzed with softer thresholds — this is how they find what the online mode missed for the sake of speed.
The choice is dictated by the response class: if a team is dispatched on the signal or a passage is blocked, real-time scale is needed; if the event goes into a report and incident review, the archive is enough. Mixed mode is chosen where a response is needed but the cost of a false alarm is high.
Technical questions asked before the start
Before the start, customers ask approximately the same questions — and these are the right questions. Below are short answers to the point: without promises that "everything will work by itself", with an indication of what needs to be checked specifically at your site.
Some parameters depend on camera angles, lighting and network condition — we capture these inputs during the survey, before design. The answers below describe the logic of the system and how it behaves in non-standard modes.
What happens if communication with the server breaks?
Detection is performed on a local node next to the cameras, not in a remote center. If the channel breaks, recognition and event recording continue, frames and metadata accumulate in a buffer and go to the server after communication is restored.
The order of events and timestamps are preserved, and repeated triggers on the same frame do not appear.
Can the system be fine-tuned for our scenarios?
Yes, this is a standard part of the work, not a separate service. The model is fine-tuned on frames from your cameras: we label classes that are not in the base model — workwear, an abandoned object, movement in a restricted zone.
A class usually requires a few hundred labeled frames; we check quality on a holdout set, not on the same frames used for training.
How is employee privacy addressed?
Processing takes place on site; metadata and events go outside, not the video stream. Faces and work areas are masked at the level of camera and model configuration, access to recordings is role-based, and archive access is recorded in the log.
This makes it possible to comply with internal policies and avoid turning the system into total surveillance.
How does the system behave in winter and in the dark?
At night, infrared illumination and separately configured exposure are used, and the model is trained on night frames — otherwise accuracy is high during the day but drops by half after sunset.
In winter, housing heating, lens cleaning and protection against snow adhesion are added; for outdoor cameras, we separately check image stability under low contrast.
What should be done with an already installed camera fleet?
In most cases it is suitable — we connect existing cameras using standard network protocols, without replacing equipment.
Limitations are usually not in the model but in the angle and resolution: where the image is insufficient for confident detection, we propose a targeted replacement or an additional camera rather than reworking the entire fleet.
Let's discuss the task and come back with an implementation plan
A list of inputs that immediately moves the conversation into project estimation rather than a week of back-and-forth.
The more specific the initial data, the more accurately we state timelines and scope: an implementation plan is not built from a video saying "there are cameras in the shop", but it is built from a scheme with zones and flows.
- Site scheme: floor plans, control zones, camera installation heights, places where coverage without "blind" spots is needed.
- Cameras: how many, which models and current streams, whether recording exists now and at what quality.
- List of events that are important to catch: perimeter crossing, presence in a danger zone, absence of protective equipment, abandoned objects — with priority for each.
- Response procedure: who receives the alert, in which channel, what they do next and whether the operator's action needs to be recorded.
- Site operating mode: shifts, night hours, seasonal load peaks, areas with restricted access.
- Recording storage limits and access requirements: retention period, archive depth, who reviews clips and on what basis.
- What already works nearby: access control system, existing recorder, where events and metrics need to be sent.
Once we receive this, we come back with a project estimate and implementation plan: the composition of cameras and zones, a set of models for the event list, the response procedure, the deployment scheme and launch stages.
Describe the task at this level of detail — and we will come back with a plan showing what is done and in what sequence at your site.
