Camera-Agnostic AI Video Analytics: Add AI to the Cameras You Already Own

The most consequential decision in a central video analytics system is one that rarely makes it into the requirements document: whether the intelligence is tied to particular hardware. Get it wrong and every future choice about your cameras, your models, and your budget is quietly made for you by a vendor. Get it right and your camera estate becomes something you can grow, mix, and modernize on your own terms for years. This is an argument for getting it right, and a practical guide to the two open standards, RTSP and ONVIF, that make it possible.

The lock-in you do not notice until you try to leave

If you have decided to run analytics centrally, on servers you control rather than on chips inside the cameras, you have already made the harder half of the right decision. The case for server-based over edge inference is its own subject, but the short version is that putting the intelligence in the camera makes the camera the thing you must replace to change the intelligence. The trap this piece is about is subtler, because it can catch a central system too.

A central analytics platform that only works with a particular manufacturer's cameras, or only with one VMS, has simply moved the lock-in up a level. You are no longer replacing cameras to change the AI, but you are still tied to a single vendor's ecosystem for the cameras those analytics will accept, which quietly dictates what you can buy next, forecloses the better or cheaper camera that comes out in two years, and turns the mixed estate you already own, the one assembled over a decade of separate purchasing decisions, into a compatibility problem.

Real camera fleets are never one brand. They are Axis at the entrances, Hanwha in the parking structure, a few Bosch or Avigilon units someone specified for a particular corridor, and a scattering of older cameras nobody wants to touch. A system that cannot read all of them as they are is a system that will eventually make you rebuild the estate to suit it, which is the exact expense this whole category is supposed to spare you.

RTSP and ONVIF: the escape hatch

The way out of that trap is not a clever integration written per manufacturer. It is the fact that the industry standardized how cameras present themselves a long time ago, and almost every IP camera made in the last decade speaks two open standards that, between them, make the brand on the housing irrelevant to the software.

RTSP is the transport, the pipe the video actually travels down. When a camera publishes a stream, RTSP is how a client asks for it and how the frames arrive. It is the same whether the camera cost fifty dollars or five thousand.

ONVIF is the interoperability layer around that pipe, a family of standards that let cameras, recorders, and clients discover and describe one another so software can ask a device what it offers and how to connect without a manufacturer-specific driver. ONVIF is not one thing, though, and this is where most explanations stop too early. It is a set of profiles, each covering a different job, and knowing which profile does what is what lets you reason honestly about whether a given camera and a given analytics system will actually work together.

The ONVIF profiles, and what each one is for

Profile S is the workhorse and the one that matters most, because it is the live streaming profile and it is nearly universal. If a camera speaks Profile S, an analytics layer can pull its feed, and that alone covers the majority of what a camera-agnostic system needs. Profile T is its modern extension, adding proper H.265 support, which halves the bandwidth for the same picture, along with imaging controls and a first layer of on-camera event metadata. Between them, S and T are how the live video gets in from almost anything.

Profile G is about the past rather than the present: recording, retention, and searching footage that a recorder has already stored. It is what lets a system reach the archive on an existing NVR rather than only the live stream, which is the difference between analyzing what is happening now and being able to go back through what happened last week.

Profile M is the one purpose-built for this era, and it is the interesting one for AI. It standardizes analytics metadata and events, the structured output of a detector, so that a device or a system can publish "a person, here, now, at this confidence" as data rather than as a picture. It works in both directions, which is the whole point: an analytics platform can ingest the detections a smart camera already produces at the edge and fold them into its central processing, and it can expose its own detections back out as a standards-based analytics feed that another system can subscribe to. That two-way flow is what turns the edge from a walled garden into just another signal.

Profiles C, A, and D sit outside video entirely, covering physical access control, door and lock control, its configuration, and the peripherals around it. They earn a mention here only because the most valuable analytics scenarios often want to act on the physical world, and these are the standards through which a detection can reach a door.

Where a camera-agnostic system fits

This is exactly the design AI Live Insight is built to, and the standards above are how it stays hardware-independent. It reads live video over the streaming profiles, S and T, via RTSP, from essentially any compliant camera or VMS, which is why it does not much care whether a feed comes from an Axis unit, a Hanwha camera, a Bosch or Avigilon device, or a mixed estate assembled over fifteen years. It treats them all as ordinary sources and does the thinking centrally, on GPUs you control.

It is not blind to the edge, either. Through the analytics profile, Profile M, it can take in the detections a camera already produces on-board and fuse them with its own central analysis, and going the other way, the same standard lets its detections be presented back to a VMS like Milestone or Genetec as an analytics source, so the platform slots into an existing operations picture rather than demanding to replace it.

Those three profiles, S and T for streaming and M for analytics metadata, are the ones this approach is built on. None of this asks you to standardize on a particular camera, and that is the entire idea: the open standards do the work that a per-vendor integration would otherwise have to, which is what keeps the door open to whatever your estate looks like now and whatever it grows into later. The mechanics of doing this cleanly, the read-only tap, credentials, sub-streams, and where to pull from, are their own subject in pulling live streams from your VMS into AI.

What camera-agnostic actually buys you

The payoff is not abstract. It means you can add AI to the cameras you already own without replacing any of them, and roll it out a corridor or a district at a time rather than all at once. It means procurement is free to buy the best or most cost-effective camera next year without checking whether the analytics vendor blesses it, and free, for a public-sector buyer, to standardize on NDAA-compliant hardware, Axis, Hanwha, i-PRO, Bosch, Avigilon, while the system technically reads any RTSP or ONVIF source. And it means the estate is future-proof in the only way that matters, that the intelligence and the hardware can each be upgraded on their own schedule instead of being chained together. The cameras become interchangeable, and interchangeable is another word for leverage.

How to tell if a system is genuinely camera-agnostic

The claim is easy to make and easy to check, so it is worth checking:

• Does the system read standard RTSP and ONVIF streams from cameras you already own, or does it require, prefer, or perform best on the vendor's own hardware?

• Does it work across a mixed estate of different manufacturers, or quietly assume one?

• Can it consume the analytics metadata a smart camera already produces, over Profile M, rather than ignoring it?

• When you ask what happens if you buy a different camera brand next year, is the answer "nothing changes" or a sales conversation?

A system that answers those the right way keeps the leverage on your side of the table. One that does not has simply moved the lock-in somewhere you will not notice until you try to leave.

Where this choice sits alongside GPU sizing, the network, deployment, and everything else that has to hold at scale, is in Real-Time AI Video Analytics at Scale: The Systems Engineering Guide.

Talk to us about your mixed camera estate. See how AI Live Insight keeps the leverage on your side, not the vendor's.