AI Video Analytics on Existing Cameras: What Actually Has to Be True
On March 31, 2027, ONVIF stops accepting product conformance submissions for Profile S, the profile that has defined basic video streaming across most of the installed base for a decade. If you are weighing AI video analytics on existing cameras, that date is worth understanding and then largely setting aside. Your cameras do not stop working. Nothing about a standards deprecation reaches into a running system and switches it off.
What the date is useful for is exposing the thing most vendors skate past. "Works with your existing cameras" is not one claim. It is four separate claims about four different things, and only the first of them is about the camera.
Featured image: a synthetic illustration created to depict the scenario described here. It is not a real detection capture.
What AI video analytics on existing cameras actually needs
Analytics need a usable image, a stream they are allowed to read, somewhere to run the model, and a person who receives the result. Miss any one of those and the other three are irrelevant. The camera is the gate buyers worry about and it is rarely the one that fails.
Gate 1: the camera, and why it usually passes
Most IP cameras installed in the last decade already clear the bar for person and vehicle detection. The practical floor is a 1080p sensor running at roughly 10 to 15 frames per second, which is comfortably below what a typical modern camera produces. Frame rate matters less than people expect: 30 fps looks smoother to a human reviewer, but tracking an object between frames does not need it.
What matters far more than the sensor is how many pixels land on the thing you care about, which is a function of lens, distance and mounting rather than megapixels. A 4K camera aimed at a car park two hundred feet away can easily put fewer pixels on a person than a 1080p camera covering a doorway. That distinction is the whole subject of pixel density and camera placement under IEC 62676-4, and it is the single most common reason a technically capable camera produces disappointing detection.
| Gate | Practical floor | Where it usually fails |
|---|---|---|
| The camera | 1080p at 10 to 15 fps, with enough pixels on the target area | Field of view too wide for the distance, not sensor resolution |
| The stream | A second stream over ONVIF or RTSP, with working credentials | Recorder or VMS will not hand over a stream, or nobody has the password |
| The inference | Compute somewhere: edge appliance, on-premise server or cloud | Network path that cannot carry what the chosen architecture needs |
| The alert | A named recipient and a route that reaches them | Alerts land in a mailbox nobody watches after hours |
Gate 2: the stream, and why it is the one that stops projects
The most common blocker in a retrofit is not the camera but access to its video. Analytics need their own stream, and on an existing system that stream has to come from somewhere: directly from the camera, or from the recorder or video management system that already owns it. Three things go wrong at this gate more often than anything at gate one. The camera supports a second stream but it was never enabled. The credentials were set by an integrator who is no longer under contract. Or the VMS is a closed platform that will not share video with anything it did not sell you.
This is where the standards actually matter. ONVIF Profile S is, in ONVIF's own words, "designed for IP-based video systems," where a Profile S device such as an IP network camera or video encoder "can send video data over an IP network to a Profile S client." That is the interoperability floor most of the installed base was built on. Profile T is its successor and supports "video streaming features such as the use of H.264 and H.265 encoding formats, imaging settings, and alarm events such as motion and tampering detection," with metadata streaming mandatory for devices. Underneath either sits RTSP, the IETF real-time streaming protocol that most cameras use to actually deliver the video.
Status check: ONVIF Profile S, as of August 2026
- What is happening
- Profile S deprecation is in process. ONVIF lists the last date for product conformance submissions as March 31, 2027.
- What it does not mean
- It is not a shutdown. Cameras already deployed keep streaming, and existing conformant products remain conformant. The deadline governs new product conformance submissions, not devices in the field.
- What it means in practice
- New equipment will increasingly be certified against Profile T instead, which adds H.265 and metadata streaming. When you next specify cameras, ask which profile they conform to rather than assuming ONVIF is a single thing.
Gate 3: where the model actually runs
Analytics have to execute on hardware somewhere, and that choice drives your network requirements more than your camera choice does. Running inference at the edge, on an appliance close to the cameras, keeps full-resolution video local and sends only results upstream. Running it in the cloud means continuously moving video off site, which is a materially different bandwidth question and the reason a plan that works for ten cameras can fail at fifty. We covered that arithmetic in detail in the cloud video surveillance buyer's guide, and it is worth reading before anyone commits to an architecture.
The relevant point for a retrofit is that this gate is independent of your cameras. You are not limited by what the cameras can compute, because they are not computing anything. They stream, and something else thinks. That is precisely why layering analytics onto existing camera infrastructure is possible at all, and why it does not require replacing hardware that is otherwise working.
What low light actually does to detection
Low light degrades detection long before it makes an image look unusable to a person, and this is the gate most likely to be discovered after deployment. A scene that a human reviewer can squint at and interpret may carry very little of the contrast and edge detail a model relies on. Heavy sensor noise, crushed shadows and aggressive compression in dark areas all remove exactly the information detection depends on.
This is not an argument against retrofitting. It is an argument for checking the cameras you intend to rely on at the hour you intend to rely on them, rather than at midday when everything looks fine. Where the lighting genuinely cannot support it, the fix is usually a lamp rather than a new camera. Our breakdown of how AI detection behaves in low light, fog and rain covers where the real limits sit.
Gate 4: the alert nobody receives
A detection that reaches no one is indistinguishable from no detection at all. This gate has nothing to do with technology and it is the one that quietly wastes the most money. An alert needs a named recipient, a route that reaches them on the device they actually carry, and a person who is both able and expected to act. Systems that route everything to a shared mailbox, or to a monitor in a room that is empty after six, produce alerts within seconds that get read the following morning.
It is also worth confirming the cameras you are relying on are actually online, which is a surprisingly common failure and the reason camera health monitoring belongs in the same conversation. A camera that dropped off the network three weeks ago clears none of these gates.
What this does not promise. Nothing here guarantees that a specific camera on a specific site will support a specific detection class. Compatibility depends on the individual device, its firmware, the recorder or VMS in front of it, the network between them and the view that camera actually has. The only reliable answer comes from testing the real streams on the real site.
Detection also depends on a camera having a usable view of the area in question. Ground with no camera on it has no detection on it, and no analytics layer changes that.
Taken together, the four gates explain why the honest version of "works with your existing cameras" is neither a marketing flourish nor a catch. Most cameras pass. Most streams can be reached with some administrative effort. The failures cluster in the unglamorous middle, in credentials, closed recorders and alert routing, which is why an assessment that starts by pulling a live stream tells you more in an afternoon than a specification sheet does in a week. That is the difference between cameras that record and cameras that detect: not the glass, but everything downstream of it.
Frequently asked questions
Do I need to replace my cameras to use AI video analytics?
Usually no. Most IP cameras installed in the last decade meet the practical floor for person and vehicle detection, which is roughly 1080p at 10 to 15 frames per second. Analytics run on separate compute rather than on the camera, so the camera only needs to deliver a usable stream. The more common blocker is access to that stream, not the camera itself.
What is ONVIF Profile S and is it being discontinued?
ONVIF Profile S is the profile designed for IP-based video systems, covering video streaming and configuration, PTZ control, audio input and multicasting. ONVIF lists Profile S deprecation as in process, with the last date for product conformance submissions set for March 31, 2027. This is not a shutdown: cameras already deployed keep working, and the deadline applies to new product conformance submissions. New conformance moves to Profile T, which adds H.264 and H.265 encoding and metadata streaming.
What resolution and frame rate do AI security cameras need?
A practical floor is 1080p at 10 to 15 frames per second. Higher frame rates look smoother to a human but add little for detection. Pixels on the target matter far more than sensor megapixels: a high resolution camera covering a very wide area at distance can put fewer pixels on a person than a lower resolution camera covering a doorway, which is why placement and lens choice dominate the outcome.
Why do AI retrofit projects stall?
Most stall at stream access rather than camera capability. Common causes are a second stream that was never enabled, credentials held by an integrator who is no longer engaged, or a closed video management system that will not share video with third party software. These are administrative and contractual problems more often than technical ones.
Does low light stop AI video analytics from working?
Low light degrades detection before an image looks unusable to a person, because sensor noise, crushed shadows and compression in dark areas remove the contrast and edge detail a model relies on. The practical step is to evaluate cameras at the hours you intend to rely on them rather than in daylight. Where lighting is the limiting factor, adding light is usually more effective than replacing the camera.
Turning cameras a building already owns into proactive protectors is the whole point, and it starts with finding out what those cameras can already do. Talk with our team about assessing your existing system and we will work through the gates with you.