Parking video analytics: where vehicle accounting breaks down
At the entry point, vehicle accounting rests on the chain "plate detection — pass — event record." Semi-manual mode breaks it at two points at once: the operator enters the plate retroactively, and the barrier is opened with a button, without being tied to an event.
The log keeps a line with no time or no license plate — and later there is nothing to reconcile it against.
Discrepancies accumulate unnoticed. The plate is blocked by a trailer, dirt or oncoming light — the operator types in a similar one by hand, and someone else's vehicle appears in the database.
At night the share of reading errors grows, and some passages do not make it into the system at all. By the end of the month the difference between entries and exits is measured in dozens, and finding where an event was lost is already impossible.
The second cost is the queue at the entrance. While the operator clarifies the plate over the radio or searches for the vehicle in a list, the lane stands still; during peak hours the waiting grows, and drivers bypass the checkpoint or abandon their car on the access road.
Disputed passages — "I was only there two minutes," "the barrier wasn't raised" — are reviewed from footage, scrolling through it manually for the required interval.
Parking video analytics flips the order: the event becomes primary, the frame with the plate, the timestamp and the command to the entry point are recorded in a single action, without manual editing.
Entry control is then reconciled against every individual fact rather than against a shift summary — a discrepancy is visible on a specific vehicle immediately, not in a report a month later.
Below we break down what such a system consists of and what it delivers on a mixed flow of passenger cars, trucks and service vehicles.
What parking video analytics delivers in practice
Identification starts ahead of time: the plate and body type are read from the video stream while the vehicle is still approaching the booth.
The admission decision is made before it stops — entry time drops to 3-6 seconds versus 30-40 with manual checks, and no queue builds up at the entrance even during the morning peak.
The share of passages closed without human involvement is the core metric of the system. On a properly tuned setup it stays at 95% and above: the rest are dirty or non-standard plates, trailers, glare from headlights.
Such cases go to the operator as a single card with a frame and a clip of the recording, rather than as a stream of every single vehicle.
Accounting accuracy does not rest on the plate alone: the system reconciles it against the list of authorized vehicles, simultaneously checks make and color, and writes an event log with a frame for every entry and exit.
The discrepancy between the number of entries and exits per day is visible immediately — previously it was only found during an inventory count.
The existing camera fleet is connected via ONVIF — no need to replace equipment at the entrance, it is enough to route the stream to the analytics module.
The load on security staff drops proportionally: intervention is needed only for conflicts, not for every passage, so the duty officer handles patrolling and resolving disputed situations rather than raising the barrier.
The effect holds under clear conditions — camera angle, lighting, plate legibility.
We verify them on archived footage from your site before work begins: if the entry area does not provide the required quality, we propose a targeted camera repositioning rather than a full upgrade.
Entry control methods: recognition, tags, passes
At the entrance you need to reliably tell insiders from outsiders, and each method solves this differently. License plate recognition works without any action by the driver, a tag on the vehicle triggers on approach, and a pass-based regime relies on an issued document or code. Below — by applicability conditions and limitations, so you can choose for a specific site.
| Option | When it fits | Limitations |
|---|---|---|
| License plate recognition | Open entry, mixed flow, guest vehicles with no prior registration | Requires a legible plate and even lighting; a dirty or obscured plate reduces accuracy |
| Tags on vehicles | Own fleet and regular routes where passage speed matters | Requires issuing and tracking tags; a tag can be handed to another car |
| Pass-based regime | Staff, long-term tenants, one-time visitors | Manual issuance and queues; human factor at the checkpoint |
In practice the options are combined: recognition covers guest vehicles and one-time visitors, the tag covers the own fleet, and the pass remains for exceptions and contractors.
Access logic is still described by a single set of rules, so a mixed scheme does not complicate operation but reduces the share of manual checks at the checkpoint.
Verification runs against the plate database and access lists, so a new guest is added with a single entry, with no reissuing of a pass.
Implementation stages: from survey to handover
The engineering work proceeds in sequential stages, and each next one builds on the result of the previous — this way problem areas are identified before installation, not at handover.
A separate acceptance stage records not the fact that "the cameras work" but confirmed quality metrics on real vehicle traffic.
- Site survey — geometry of entries and exits, mounting height, lighting by time of day, blind spots and conflict areas where cars stand in two rows. The result is a site map with constraints that are taken into account in the design.
- Camera placement plan — angles and frame overlap are selected so that each spot is read from at least two directions, and the plate is captured on approach and exit.
- Calibration of viewing zones — we mark parking spaces and traffic directions in the frame, compensating for perspective distortion and headlight glare. A space is considered occupied only after stable confirmation, not from a single frame.
- Scenario configuration — space occupancy, transit, parking duration, marking violations. Trigger thresholds are tested on recordings of real traffic, not on test runs.
- Field trials — day and night, rain and snow, low sun, entry with a trailer. For each scenario we record the share of misses and false triggers.
- System acceptance — a protocol with metrics for each scenario, a list of known limitations and an agreed procedure for failures.
- Handover — documentation, data flow diagram, access credentials, training for the duty shift and a maintenance regulation.
Deliverables: configurations, diagrams, regulations
The deliverable set is not a folder of files "just in case" but a working system that can be handed to another team or brought back up after a storage failure.
We store configurations in a version control system and hand them to the customer together with a description of the logic: what is configured, why such a threshold was chosen, and what will change if it is shifted.
- Video analytics configurations — event rules, control zones, trigger thresholds and exceptions (for example, transit passage and shadows). They can be transferred to a backup node without rebuilding the logic.
- Viewing zone diagram — floor plans with camera placement, viewing direction, overlaps and blind areas. It shows which parking spaces are not covered and where an additional point is needed.
- Access policies — roles for operator, engineer and administrator: who can view the archive, who edits the rules, who exports data. Configured for real job positions, not abstract groups.
- Operating regulation — procedure for responding to triggers, escalation points, frequency of checking lens cleanliness and calibration correctness.
- Operator instructions — short guides on reviewing events and manually correcting false triggers.
- Change log and configuration versions — any edit is reversible, rolling back to the previous working version takes minutes rather than a shift.
- Integration diagram — where and in what form events are sent: security system, dispatch center, archive storage.
- Acceptance methodology — a set of test scenarios with reference recordings, against which recognition quality is verified repeatably rather than "by eye."
Case study: accounting accuracy at the entrance before and after
What the entrance looked like before
Accounting relied on two cameras and an operator: license plate recognition worked in even lighting and dry weather, but fell apart in rain, snow and on dirty plates.
The share of disputed passages reached 6% — each such case was reviewed manually by security from footage, averaging 12 minutes per episode.
Over a shift this consumed several hours of checkpoint work: while the operator was reconciling the log, the live entrance remained uncontrolled.
What was changed
We built a separate video analytics setup: the plate and make are determined from several frames instead of one, and the hypothesis is automatically reconciled against the pass database.
A doubtful trigger is not discarded but flagged with a confidence level and placed in the event queue — the operator sees the frame, the clip and the reason for doubt.
The confidence threshold is configured by time of day and weather, so the night flow is not cut off along with the noise.
Metrics after implementation
Recognition accuracy at the entry point grew from 88% to 99.2%, and the share of disputed passages fell to 0.4%. The average episode review time dropped from 12 minutes to 40 seconds, and the share of passages without security intervention — from 71% to 98%.
Measurements are taken per the Control Measurement Protocol: once a week we run a sample of recordings and reconcile the automatic answer against a manual frame-by-frame check.
How is license plate recognition different from vehicle tracking?
These are not alternatives but two different layers of vehicle identification solving different tasks.
License plate recognition answers the question "who exactly," while vehicle tracking answers "what happens to the object over time." Mixing them into a single requirement is a common reason why a system at acceptance delivers a result other than what was expected.
Tracking works on geometry: the detector finds the car, the algorithm matches it to the object in the next frame by position, size and appearance, assigns a track ID and follows the movement line.
The plate is not needed here: the track survives even if the plate is removed or not visible from this camera. But it provides no identification of the owner, and in dense traffic it breaks on occlusions.
License plate recognition builds identification differently: it finds the plate, normalizes the angle, recognizes the characters and reconciles against the database — the output is a vehicle from the list, not a nameless object.
The price for this is sensitivity to conditions: night, oncoming light, plate tilt and high speed produce reading errors. A lost track simply breaks the history, while a reading error produces a false trigger at the barrier.
The choice of technology is determined by the task. If you need passage by list, access control, or finding a specific vehicle — license plate recognition becomes the baseline.
If you need occupancy, parking duration, marking violations, flow counting — vehicle tracking does the work, and the plate is connected as an attribute.
In practice it is more often a hybrid: the track is the main entity, and the plate is attached on the first confident reading, so short gaps do not break the history.
Technical doubts: camera failure, night, dirty plates
We address reliability objections not with promises but with bench testing: we collect recordings from the specific site — nighttime, with dirty plates, with headlight glare — and run them through the model before launch.
The conditions in which the system errs become known in advance, and there is an answer for each one in the configuration.
What happens at night when there is almost no lighting?
The camera switches to night mode with infrared illumination, the frame becomes black-and-white, and the recognition module switches to a profile with different contrast and confidence threshold.
The plate is read from reflection in the infrared range rather than by color — this is more resistant to low light than processing a color frame.
What if the plate is dirty, overexposed or non-standard?
The recognition module returns not only a string but also a confidence score for each character.
If the score is below threshold, the event is not discarded: the log receives the frame, its clip and a "needs review" flag — the operator sees what was at the entrance and decides manually.
The threshold is tuned for the specific site so that the number of such flags stays within reasonable limits.
What if a camera freezes or the connection drops?
The control node monitors signs of a live stream: frame change, periodic signal from the camera, time synchronization. A frozen frame or a lost stream raises an event in the monitoring system within seconds.
Recordings are buffered on the local node and uploaded after the connection is restored, so a break does not leave holes in the archive.
How is redundancy set up?
The viewing zones at the entrance and exit are overlapped by two cameras from different angles — failure of one does not leave the lane unobserved.
Power and network run over independent lines, and the node configuration is stored separately from the node itself: replacing a camera comes down to substituting the address and verifying zone calibration.
Bottom line: the system does not stay silent about a problem but shows it — camera failure, low recognition confidence and a gap in the archive are visible in monitoring rather than surfacing during the review of a disputed situation.Let's discuss the task and come back with an estimate and a plan
So that the project estimate is substantive rather than "approximately," we start the review with questions about the site.
Implementing parking video analytics comes down to four things: the geometry of the passages, lighting, the quality of the cameras already installed, and how vehicle traffic is managed today.
We clarify at the start:
- How many entries and exits there are, whether there is a reversible lane, dedicated lanes for regular customers, and areas where cars stand outside the markings.
- Operating hours and night load: whether there is enough light to read plates confidently and distinguish vehicle class.
- What cameras and recording equipment are already in place, where power and network can be brought, and where the compute node can be placed.
- What we consider an event: entry, parking duration, rule violation, space occupancy by zone.
- What the result should be linked to: barrier, cashier station, free-space display, operator workstation.
- Accuracy requirements and the procedure for reviewing disputed triggers — who confirms an error and how.
- The archive depth and exports needed for handling inquiries and reporting.
Based on the review, we send a project estimate and scope of work: stages, a camera placement plan with viewing zones, a list of integrations, a work plan with acceptance points and a list of risks — what depends on the site and what depends on the analytics settings.
Describe the task in free form: how many sites, approximate vehicle flow, what equipment is already in place and what you want to see in the reports. We will come back with a project estimate and a work plan.
