Engineering overview

When Video Becomes Data: What Changes for the Security Team

The same vehicle passes two cameras. Two weeks later, when the security team needs to revisit the incident, the first camera gives them hours of video to search through manually. The second gives them something more: structured attributes that make that specific vehicle pass searchable.

The difference is not in image quality. It is in what the system can extract from what it sees.

The second camera stores more than video. It also captures structured attributes describing what happened in the scene — turning what the camera sees into data that can be searched, correlated, and passed into the next process.

The question this raises is not really about technology. It is about how the security team operates: what changes when video stops being just a recording?

Structured data enters Security Center in two ways. The first is through Genetec’s own purpose-built analytics, with AutoVu — its automatic license plate recognition subsystem — providing the clearest example. The second is through analytics performed by the camera itself or by a third-party solution, with Security Center receiving the resulting data. The first is the better place to start, because it shows most clearly what “structured data” actually means in practice.

A License Plate Read Is More Than a String of Characters

License plate recognition is usually judged by a single question: did the camera read the plate correctly or not? But for a system that needs to do something with that plate afterward, the read itself is only the beginning.

The result is a structured record:

  • the plate number itself
  • a close-up of the plate
  • a wider image of the vehicle and its surroundings
  • the time and location
  • vehicle attributes
  • the recognition confidence score

These records are collected in the Reads report, where they can be searched using any of the available attributes.

The practical value is straightforward: to find a vehicle of a particular color and type that passed a specific point at a given time, the operator does not have to search through the traffic footage manually. They run a query instead. The investigation stops being an exercise in reviewing hours of video.

Some of the available attributes are determined by the capabilities of the camera and its analytics. But the attributes the security team will need to search by a year from now are decided much earlier — at the design stage. That decision shapes both the choice of analytics source and the storage architecture required to support it.

For the architect, there is another important consideration: recognition data and the images associated with it are handled by different platform roles — ALPR Manager and Archiver. Their retention periods need to be planned separately. Otherwise, six months from now, the structured reads may still be searchable while the associated images are already gone: the data remains, but the visual context does not.

Diagram: a license plate read becomes a hit and moves into reports, external systems, or a system action
Figure 1. A read becomes a hit — and from there moves into reports, external systems, or a system action.

The Observation Point Determines What Data You Get

The available attributes are not determined by the recognition algorithm alone. They begin with where — and under what conditions — the system observes the vehicle. A fixed observation point at an entrance and a patrol vehicle moving through a site serve different operational purposes — and produce different data.

In AutoVu, these are two distinct types of observation points. SharpV is a fixed ALPR camera designed for a stationary scene, with all recognition processing performed onboard. SharpZ3 is a mobile system designed for patrol vehicles, with a separate processing unit and reads delivered to Security Center through Genetec Patroller.

Diagram: fixed and mobile observation points feed into the same Security Center roles
Figure 2. Fixed and mobile observation points feed into the same Security Center roles.

The difference between the two goes beyond how they are installed. Only a fixed SharpV can determine the vehicle’s direction of travel relative to the camera; a read captured from a patrol vehicle simply does not contain that attribute.

This is why a question that often comes up at the start of a project — why not simply choose a good recognition camera first and decide where to install it later? — has a purely engineering answer. The observation scenario determines what attributes will exist in the system in the first place.

A strong recognition engine cannot compensate for a poorly designed observation point. And the reverse is equally true.

The Cost of Tolerance: A Missed Match vs. a False Positive

The hotlist contains plate ABC123, but the camera reads ABC12 — the final character is obscured. A single misread character should not be enough to miss a vehicle of interest, so the system can work with imperfect reads: accounting for visually similar characters, differences in plate length, and partial matches. Tolerance thresholds can be configured separately for different operational scenarios — hotlists, permits, and parking time enforcement.

Diagram: visually similar plate characters and how the configured tolerance changes which reads count as matches
Figure 3. Visually similar characters — and how the configured tolerance changes which reads are considered matches.

The system does not “correct” the plate number. It determines whether the read qualifies as a potential match under the configured logic. The tolerance is set according to the operational scenario — and it is this setting that shifts the balance between missing a relevant vehicle and creating an unnecessary verification.

One Read, Three Different Paths

The same read can follow three architecturally distinct paths. The choice determines not only what the system does with the data now, but also what that data becomes — and what remains available afterward.

One read

  • 01 · Event

    The vehicle requires attention now.

    The organization defines in advance which license plates should trigger a response. In Security Center, this list is called a Hotlist, and when a recognized plate matches an entry on that list, the result is a Hit. That Hit can then trigger a predefined response — an alarm, a notification, or the start of recording. For the security team, this changes something fundamental: detecting a vehicle of interest no longer depends on someone happening to be watching the screen at the right moment.

  • 02 · Access credential

    The plate becomes part of an access decision.

    There is another architectural approach: instead of list-based logic determining whether the gate opens, the decision is made by the Synergis access control system, where the license plate is registered as an access credential. The distinction is more than architectural. Recognition simply provides the data; the authority to grant access remains where it belongs — within the access decision lifecycle, together with the rest of the access control tools and reporting.

  • 03 · Parking session

    The plate becomes part of a specialized process.

    In Free-Flow, the parking occupancy management subsystem, entry and exit reads are linked to create a parking session — a distinct entity with its own state. From there, the session follows its own logic: tracking site occupancy, identifying vehicles that exceed their paid parking time, and generating a list of violations.

Three different outcomes from the same recognition event.

Structured data becomes truly valuable when it stops being the output of analytics and becomes the input to the next process.

In Security Center, that process does not have to remain within video surveillance: the same read can become an event, serve as an access credential, or become part of a parking session.

Diagram: one license plate read with three paths — an event, an access credential, or a parking session
Figure 4. One read, three different paths: an event, an access credential, or a parking session.

Does the Platform Need to Run Every Algorithm Itself?

So far, we have focused on purpose-built analytics, where the vendor controls the entire processing chain. With general-purpose video analytics, the architecture is different — and so is the question the system designer needs to ask.

Judging a platform by how many analytics algorithms it provides natively is of limited value. A site may already have cameras with onboard analytics, while other use cases may require a specialized third-party solution. The more practical question is what analytics results the platform can consume — and what it can do with them once they arrive.

Security Center can receive analytics events generated either by the camera itself or by a supported external analytics module. Within the platform, the camera’s role as a source of analytics events is separate from its role as a source of video.

Consider camera tampering — an obstructed lens or a sudden change in camera position. Security Center has an event type for this, but the event itself may be generated by the camera or by an external analytics module. So the presence of a particular event type does not necessarily mean that Security Center is running the corresponding algorithm. The platform can receive the result and use it within its own operational logic.

For the security team, this is more than a matter of terminology. Where the analysis actually runs determines what needs to be validated during testing — and who owns the problem when the results need to improve.

Question for the vendor

So the better question for a vendor is not “Does the system support detection of X?” but “Where is that detection performed, and what can the system do with the result afterward?”

There is also a case where an incoming analytics event does not map to a dedicated standard event type in Security Center. That does not make the event unusable: the platform can still capture it and preserve additional information in the associated metadata. This should not be read as universal compatibility with any analytics solution, however — the capabilities available in practice depend on the specific integration.

If the analysis is performed by an external system, that system first needs access to video from the platform. Security Center provides a dedicated Media Gateway role for this purpose, allowing video streams to be delivered to external consumers. But sending video out and bringing the analytics result back into Security Center are two separate integration challenges — and the second depends on the capabilities of the specific solution.

Events and Data Answer Different Questions

One detection

  • 01 · Event

    An event answers one question: has something happened that requires attention now?

  • 02 · Metadata

    Metadata answers another: what did the system identify in the video, and what information can be used later?

This creates two distinct paths. A detection generates an event, and the event drives either an operator response or an automated action. Alternatively, metadata is stored alongside the video, with its value emerging later during search and investigation. In most cases, both outcomes matter — and that is something to decide before selecting the equipment: do we need analytics to trigger an immediate event, provide searchable data for later use, or both?

Diagram: from one detection, an event leads to response and metadata leads to search
Figure 5. Events drive response; metadata enables search. Two different paths from the same detection.

Metadata recording is enabled separately and has its own retention lifecycle. Metadata is available only for archives stored locally and is deleted when the local retention period expires. If investigations are expected to rely on structured data months later, metadata retention needs to be designed just as deliberately as video retention. Otherwise, the video may still be there — but the attributes that would have made it searchable will be gone.

Design the Process, Not the Analytics

Before choosing a camera, an algorithm, or an integration, there are three questions worth answering first.

What does the system need to understand about the scene? What data should the analysis produce? And what needs to happen with that data next?

Without an answer to the third question, the project effectively stops at detection. With one, the entire chain can be designed deliberately:

  1. the operational objective
  2. the object being analyzed
  3. scene conditions
  4. required data
  5. analytics source
  6. integration
  7. downstream process
  8. acceptance criteria

The specific technology should be the last choice in that sequence — not the first.