Where road traffic video analytics breaks on real sites
Pilot road traffic video analytics almost always produces a smooth report until the first comparison with manual counting on the same section.
A discrepancy within one-fifth on dense traffic is common, and it means not a "weak model" but specific scenes where the detector loses an object or counts it twice.
The most frequent source is camera view occlusion. A truck in the outer lane, a tree branch, a new billboard or shifted markings after repair cut off part of the detection zone, and everything behind the obstacle does not exist for the system.
A separate case is U-turn loops and junctions: a car leaves the frame and returns to it, and without correct binding to zones it is counted again.
Dark-time and precipitation filming breaks the detector differently. Headlight glare, reflections on wet asphalt, long shadows from fences reduce object contrast, tracking breaks, and the break turns either into missed vehicles or a double count of one car. Rain and snow add noise that the model confidently recognizes as a moving object.
False detector triggers more often come not from transport: reflections in puddles, shadows, pedestrians at the edge of the roadway, structures swaying in the wind.
When such triggers are suppressed by raising the confidence threshold, part of the real traffic goes away with the noise — and the discrepancy with manual counting grows from the other side.
All these failures lie in calibration and local data, not in the choice of model.
We break down how this is closed: setting zones to the real geometry of the site, retraining on the site's own scenes, and regular reconciliation with manual counting as a mandatory check before handover.
What changes after implementation: counting accuracy and reaction time
The effect of video analytics comes down to three numbers: the share of correctly recognized traffic units, the median time from event to notification, and the volume of archive that the operator reviews manually.
We measure them on labeled segments of recordings before the start — otherwise "it became more accurate" is not confirmed by anything.
- Traffic counting accuracy. The algorithm keeps the same object between frames, so in a dense row cars are not doubled and not lost in shadow. The daily report by lane begins to match manual recount without corrections.
- Incident detection time. Stopping in a lane, oncoming movement, fallen cargo reach the operator in seconds — with camera binding and timestamp, not after shift review.
- Transport classification by types. Cars, trucks, buses and special equipment are separated by dimensions and silhouette, traffic composition is calculated automatically, without manual labeling.
- Reduction of manual video review. The operator opens the event list and short fragments around them instead of a day of archive: shift review takes minutes, while each trigger is verifiable.
Detectors of the current YOLO branch are retrained on recordings from your cameras: angle, lighting and traffic density affect accuracy more than the model itself.
Deployment options: on-site, processing center, hybrid
The deployment scheme determines where the compute node is located — at the intersection or in the center — and what load falls on the communication channel. Raw video stream from cameras occupies bandwidth constantly, while events and metadata go only at the moment of a trigger.
Therefore the choice is dictated not by recognition models, but by the number of cameras at the site, channel stability and the requirement for continuous archive.
| Scheme | When suitable | Limitations |
|---|---|---|
| On-site video processing | Channel unstable or limited, many cameras, response needed at the moment of an event | Compute node at the intersection requires power, a protected cabinet and on-site maintenance |
| Centralized video stream processing | Channels reliable, few sites or they are compact, uniform rules needed for the entire network | Load on the communication channel grows with each camera, communication loss zeroes out the site |
| Hybrid scheme | Heterogeneous network: some sites with stable connection, some remote | More expensive to support — two update loops and two points of failure |
At sites with stable connection, the centralized scheme gives an overall picture across the network and uniform processing rules.
Where raw video output is impossible, recognition moves to the intersection, and only events go to the center: during communication loss they accumulate locally and are sent after channel restoration.
A hybrid is assembled from both loops and most often turns out to be a working compromise for a city where sites differ greatly in operating conditions.
Stages of video analytics implementation: from survey to handover
Work proceeds in sequential stages: the result of each becomes input for the next, so skipping survey or calibration almost always returns as false triggers on the live stream. It is cheaper to catch an error where it arises.
-
Site survey. Road geometry, camera angles, occlusions, daytime and nighttime lighting, access to poles and communication channels. Blind zones and unstable points are either covered by additional view or honestly excluded from the system's responsibility zone.
-
Scheme design. We agree on object classes (cars, trucks, buses, pedestrians), counting lines, control zones and trigger rules — what is considered a violation, what is an incident, and what is noise.
-
Detection zone calibration. Binding zones to markings and lanes, sensitivity thresholds, masks for shadows, branches and advertising structures. We separately check night, rain and backlight.
-
Verification on archived recordings. We run the configured scheme on recordings from different days and weather, and compare manual recount with automatic. Discrepancies are analyzed item by item: some are closed by retraining, some by zone correction.
-
Pilot operation on the live stream. The system works in parallel with usual monitoring, operators record misses and false alarms. We make edits in configuration, not in code on the fly.
-
Acceptance and system handover. Handover according to agreed accuracy and completeness metrics, transfer of documentation, configurations and access, operator training. Separately — rollback and recovery procedure after failure.
Delivery package: zone configurations, schemes, operation regulations
The delivery package is what allows the system to be operated after the installation crew leaves: without a description of zones and rules, any edit turns into guessing parameters at random.
We fix not only the current settings, but also the logic by which they were chosen — so that when the traffic scheme changes, changes are made consciously. Below is the list of artifacts that remain with the customer.
- Control zone passport: boundaries of each zone, trigger rules, sensitivity thresholds and false trigger suppression logic — shadow, headlights, brief stop in traffic.
- Camera placement schemes: installation plans, fields of view, overlap zones, connection and power points, binding of each camera to passport zones.
- Video stream access policies: user roles, separation of live viewing and archive, retention periods, logging of every access to video.
- Operation regulations: frequency of checking angles and image quality, zone calibration, procedure for signal loss and a disputed event.
- Event log: composition of record fields, export to reporting, reconciliation of automatic data with manual measurements at control sections.
- Operator instructions and change matrix: what is considered an incident, who approves edits to zones and rules, how configurations are versioned and rollback is performed.
The package is assembled for a specific site, not issued as a template: during expansion, new zones are described according to the same structure.
Compatibility with the already installed camera fleet is checked before installation — by ONVIF profile, so as not to replace working equipment for analytics.
Case: how counting accuracy grew at an urban section
What it was before
The section — dense urban traffic with a pedestrian crossing and a turn onto the highway. The detector configured for "average" traffic erred precisely at peak: the share of correct recognitions stayed around 75%, and in the evening hour fell below 70%.
Tracks merged, some cars were counted twice, some were lost behind a truck. False triggers accumulated several hundred per day — nighttime glare, shadows, reflections from the wet road.
What was changed and what became
We retrained the detector based on YOLO on a local sample of frames from this section and added a tracking module that checks the object by trajectory, not by a single frame.
Counting zones were calibrated according to road markings, and for night we assembled a separate set of thresholds — this removed a whole class of failures with false detections on headlights and shadows.
The share of correct recognitions — 93–96% per day and not below 90% at rush hour. False triggers decreased from several hundred to 20–25 per day, and almost each is confirmed by a second frame, not by a single trigger.
Time from event to operator signal: it used to be 20–40 minutes while the incident was found in the recording, it became 3–5 seconds — a card with a fragment and marks goes to the console.
Metrics were calculated on identical recording intervals before and after, with the same zone marking — therefore the comparison is comparable, not "by eye".
What to do if the site already has cameras from another vendor
Short answer: replacing the entire camera fleet is almost never necessary. We start with inventory — which cameras are already installed at the site, how they output the video stream and who manages them.
Based on its results, most of the fleet connects to analytics as is, some requires modification, and only a small remainder is replaced physically.
Stream suitability is determined not by brand, but by whether the camera outputs video via an open network standard, and not only into a related recorder; whether the stream is accessible with read permissions; whether the angle allows distinguishing transport and plate; whether the image remains workable at night and in bad weather.
Different camera models at one site are normal: analytics accepts a heterogeneous fleet and brings streams to a unified form.
Replacement is needed where the camera records only into a closed manufacturer archive with encryption, where the output is an analog recorder without a network channel, or where the view is occluded and quality does not allow distinguishing classes.
Often it is more profitable not to replace the camera, but to add a node: an additional viewpoint at the problem section or a local processing module.
Integration with installed equipment is built so as not to break the current loop: recording and monitoring continue to work on the previous recorder, while analytics receives the video stream in parallel and does not change its settings.
Channel capacity is calculated in advance — if insufficient, we allocate a separate segment for analytics, rather than taking bandwidth from security.
Bottom line: first check video stream suitability for each camera, then the decision — connect, modify or replace. The customer receives a list of cameras with a verdict for each and sees where replacement is inevitable and where one additional node is enough.
Common technical doubts before project start
Engineering doubts before start concern not demonstration, but system behavior in bad conditions: precipitation, night, headlight glare, backlight.
That is where detector accuracy drops, so we confirm each answer below with control runs and manual labeling — before signing the work plan, not after handover.
How does video analytics behave in rain, snow and fog?
Precipitation reduces contrast, and drops and snowflakes on the lens produce false triggers. We narrow zones of interest to the roadway, raise the detector confidence threshold, make the decision based on accumulation of features over several frames, not one.
Heated housings remove most of the problem, the remainder is measured by reference runs in bad weather at the specific section.
How accurate is nighttime footage?
At night, infrared illumination and high-sensitivity mode work, headlight glare is masked by zones. We retrain the model on nighttime fragments of the same section, and calculate accuracy separately for day and night — the overall average shows nothing here.
How long are recordings stored?
The policy is two-level: we store video for a limited period, metadata — tracks, object classes, timestamps — substantially longer. Reports and traffic recounts are built from metadata, so the video retention period is dictated by requirements, not archive size.
How to make sure counting is correct?
We take control intervals and recount them manually, comparing the result for each class. A discrepancy above the specified threshold is a signal for recalibration. Additionally, automatic checks work: balance of entries and exits per day and filtering out duplicate tracks.
Is a permanent operator needed?
No. The system works autonomously, the operator connects only to resolve disputed situations. Notifications about camera failures, view occlusion or data anomalies arrive automatically.
Let's discuss the task: we will assemble a scheme and come back with an estimate
To discuss the task in one round, not a week of correspondence, minimum input is needed. Below is what we request from the customer at the start and what we return based on the analysis results.
- List of cameras and stream types: models, whether they output video directly or only archive, who owns the infrastructure and whether access to it exists.
- Recognition tasks: transport counting by lanes and directions, object classes, recording of stopping, congestion, driving into a dedicated lane.
- Event requirements: what data is needed at the output — counters, alarms, reports — and to which system to transmit them.
- Infrastructure limitations: where computations may be placed, what communication channel is available and how long to store the archive.
- Difficult filming conditions: night, rain, glare, occlusions — what is already known about problem sections and viewpoints.
- Acceptance criteria: by which metrics we consider the system operational — detection accuracy on the test sample, notification delay, share of missed events.
- Contact on the customer side who approves the solution scheme and accepts the stages.
Based on the analysis results, we return with a solution scheme: camera placement and stream organization, set of models and detection rules, required integrations.
To the scheme we attach an estimate of timelines by stages and an implementation plan: pilot at a limited section, model calibration, acceptance on the test sample, deployment and documentation handover.
Describe the task in free form — we will return with an estimate and plan.
