Face recognition and VMS integration
Adding face recognition to a video management system means putting a matching engine beside the VMS and sending its results back in as events the operator already knows how to use. The VMS keeps recording, retention and permissions; recognition only decides what is worth an operator's attention.
What does face recognition inside a VMS actually mean?
Two arrangements are in normal use, and they are not interchangeable. Which one a site can have depends on what its VMS exposes, not on which is better in principle.
| Pattern | How it connects | What it gives up |
|---|---|---|
| Plugin inside the VMS | Runs as an extension the VMS loads, using the vendor's own SDK for video and events | Tied to that VMS and its versions; upgrades have to be planned around it |
| Alongside the VMS | Takes the camera stream in parallel and returns results to the VMS as events, or to a separate console | Overlays inside the VMS interface are limited to what its event model accepts |
The second pattern is more common in retrofits, because it does not require a version of the VMS that supports third-party extensions and it does not couple the analytics upgrade cycle to the VMS upgrade cycle. The first gives a tighter operator experience where the platform supports it.
Where does the engine get its video from?
From the camera directly, or from the VMS. Both work and they fail differently, which is why this is decided early rather than discovered during commissioning.
- Directly from the camera, usually over RTSP: the engine sees the stream the camera produces, before the VMS has re-encoded anything.
- From the VMS, through its SDK or an ONVIF interface: one integration point, but the stream may already be transcoded or reduced.
- From a substream rather than the recording stream: cheap on bandwidth, and frequently too small for a face at the distances the camera is mounted at.
The substream question is the single most common cause of disappointing results. A camera recording at full resolution may publish a substream at a fraction of it, and an engine given the substream is being asked to work from a face a few dozen pixels across. Establish which stream the engine will receive before anybody measures anything.
What goes back into the VMS?
A result is only useful if it lands somewhere an operator already looks. What a VMS can accept varies, and the right integration uses the mechanisms the platform already has rather than adding a second screen nobody watches.
- An event or alarm: the VMS raises it in the same list as its motion and device alarms, with the camera and the time attached.
- A bookmark on the recording: the operator can jump to the moment afterwards without searching by hand.
- Metadata alongside the stream, where the VMS supports it, so a search can be filtered later.
- An overlay in the live view, where the platform allows third-party drawing on the video pane.
Which of these four are available is a per-platform, per-version question. It is also the question worth settling first, because an integration that can only raise a generic alarm gives the operator much less than one that can bookmark the clip.
What does the VMS keep doing?
Nearly everything it did before. This matters commercially, because it means a face recognition project does not put the existing video estate up for replacement.
- Recording, storage and retention policy stay with the VMS.
- User accounts, roles and who may view which camera stay with the VMS.
- Export and chain of custody for evidence stay with the VMS.
- Camera health, bandwidth and failover stay with the VMS.
The recognition layer is deliberately narrow: it decides what is worth attention and hands that judgement back. Anything that duplicates the VMS - a second recording store, a second permission model - is a sign the integration has been designed the wrong way round.
What usually breaks?
Integrations rarely fail at the matching step. They fail at the seams, and the same handful of seams account for most of it.
| Symptom | Usual cause |
|---|---|
| Faces detected far less often than expected | The engine was given a substream, or a stream the VMS re-encoded at lower quality |
| Events arrive but the recorded clip cannot be found | Clock drift between the engine host and the VMS; timestamps no longer line up |
| Results degrade at busy times only | Frame rate is being dropped under load, so the moment a face was presentable was never delivered |
| Works on one camera, not on its neighbour | Mounting height, angle or lighting differs; the geometry decides more than the engine does |
- Camera placement for face recognitionHeight, angle, standoff and pixels across the eyes — the geometry that governs whether a face is usable at all.
Where does the recognition run relative to the VMS?
On the customer's own infrastructure, in every supported arrangement. The engine can sit on a server in the same room as the VMS, on an edge appliance near the cameras, or in a network with no outbound path at all.
What follows from that is the answer to the question a security team asks first: face images and templates do not have to leave the network for the system to work, and no call to an external service is required to perform a match. For a video estate that is already treated as sensitive, adding recognition should not change where the video lives.
- Ayonix video analyticsThe analytics that attach to an existing camera estate, and how they are licensed.
- Face recognition for access controlThe door case, where the same engine is wired to a controller rather than to a VMS.
How is compatibility confirmed for a specific site?
By checking the actual platform, edition and version against the actual cameras, rather than by reading a grid. Ayonix does not publish a VMS compatibility matrix, and the reason is worth stating plainly: a matrix is a per-version integration claim, it goes stale on somebody else's release schedule, and a stale one sells a project that cannot then be delivered.
- Send the VMS product, edition and version, and the camera models and firmware.
- Say which stream the engine can be given, and at what resolution and frame rate.
- Say which of event, bookmark, metadata and overlay the operator actually needs.
- Test on representative video from the site before the design is fixed, not after.
- How to run a face recognition pilotWhat to measure, on whose footage, and how to tell a real result from a demonstration.
Frequently asked questions
- Do we have to replace our VMS?
- No. The normal arrangement adds a recognition layer beside the VMS and returns results to it as events, leaving recording, retention, permissions and export exactly where they are. Replacing the VMS is not a prerequisite and is rarely worth making one.
- Does Ayonix publish a VMS compatibility matrix?
- No, deliberately. A matrix is a per-version integration claim that goes stale on another vendor's release schedule, and a stale one sells a project that cannot be delivered. Compatibility is confirmed for the specific platform, edition, version and cameras on a site before the design is fixed.
- Should the engine take video from the camera or from the VMS?
- Either works. Taking it from the camera gives the stream before the VMS has re-encoded anything; taking it from the VMS gives one integration point instead of many. What matters more than the choice is knowing which stream is being delivered, because a substream is frequently too small for a face at the distance the camera is mounted.
- Can results appear inside the VMS interface, or only in a separate console?
- That depends on what the platform's event model and its extension interface allow. Events and alarms are widely supported; bookmarks on the recording are common; metadata and live overlays vary by platform and version. Which are available is one of the first things worth settling, because it decides what the operator's day actually looks like.
- Does the video leave our network?
- It does not have to. The engine runs on the customer's own infrastructure — beside the VMS, on an edge appliance, or in a network with no outbound path — and no call to an external service is required to perform a match.
- Why did face detection work in the demo and not on our cameras?
- Most often because the engine was given a different stream, or because the camera geometry differs. A substream at reduced resolution, a re-encoded feed, a lower frame rate under load, or a camera mounted higher than the one in the demonstration will each change the result, and none of them is a property of the matching itself.
- Is Ayonix NIST certified for VMS integration?
- No, and no vendor is. NIST runs evaluations and publishes reports on how submitted algorithms performed; it does not certify, approve or endorse vendors, and it runs no evaluation of VMS integrations at all. Ayonix has participated in NIST face recognition evaluations, which means algorithms were measured.