ONVIF, RTSP and Proprietary

One of my most read blog posts is the one where I pose the question Is ONVIF a complete failure? The protocol itself is – in principle – fine (if everyone implemented it to perfection). Back when ONVIF started, SOAP was da shiznit, so obviously ONVIF is based on SOAP. Today SOAP is considered pretty n00b, and AJAX/JSON is considered the way to go. I wish ONFIV had started out simple – a few, well defined HTTP URIs with a clearly defined response format would have been great. But it didn’t pan out like that.

I suppose that most professional integrators already know that picking random cameras and hoping that their NVR will support them (well) via ONFIV is a little haphazard. Granted, it shouldn’t be that way. If I get a device that says it has HDMI support, then my expectation is that it will work with my television that also has an HDMI connector. And I wish the same applied to IP cameras.

So I hope that integrators pick cameras that they know work (well) with the NVR/VMS software that they pick. I think a lot of integrators go for a combination of cameras and VMS’s where the VMS natively support the cameras proprietary protocol (like VAPIX for Axis or SUNAPI for Samsung-Techwin). Under the bonnet, the VMS may use parts of ONVIF to work the camera, but the specific camera type usually shows up in some dropdown in the VMS administration module.

So who uses ONVIF?

I must admit I don’t know. I know that occasionally someone inquires about it, but I never really dug down into the details. Don’t get me wrong – the idea that you could buy an ONVIF camera from anyone, and not have to rely on the VMS manufacturer to provide support for the camera is what we strive for – and some glorious day, we’ll look back at the bad old days when it was plug and pray.


But there’s another option that most people seem to be using : generic RTSP support.

A lot of installations have no need for PTZ at all. They have a bunch of fixed cameras, and if those cameras stream via RTSP, most VMS’s will support them. Granted, obtaining the RTSP URI for your camera is not really user-friendly, for the seasoned/motivated amateur, RTSP is actually a pretty decent way of getting your feed recorded in your favorite VMS.

It does cut out a lot of the simplicity of using a VMS’ proprietary support – setting the resolution, the compression etc. will have to be done via the cameras web interface, which differs wildly across different manufacturers but it might be a price one was willing to pay. Especially in the low end segment where a lot of DIY types are messing around with cameras that are cheap, and offer surprisingly good image quality – pairing them with their favorite VMS.

For the foreseeable future, I think most/all high-end installs will rely on the proprietary protocols, but I hope and pray that within a few years we’ll be able to pick pretty much any camera, and have it work, out of the box, with almost any popular VMS.

Author: prescienta

Prescientas ruler

2 thoughts on “ONVIF, RTSP and Proprietary”

  1. Unfortunately, there are a lot of factors which push back against a common open protocol.

    You have companies like Genetec, who make a lot of money because they’ve done a lot of work writing a lot of drivers to work with a lot of cameras. Should everyone just use ONVIF, then suddenly only a single ONVIF driver is needed in Genetec, and there is a lot less that differentiates Genetec from smaller compeditors. So Genetec pressures camera manufacturers to continue their proprietary protocols.

    You have a similar situation with the camera manufacturers (or rather their marketing department) which feel like a proprietary protocol is how they differentiate themselves from their competition. After all, how do you innovate within an ONVIF-only box? Where is the ONVIF API for deploying Ninjas on motion detection?

    Both problems fade with ONVIF extensions. Cameras can differentiate by adding extra features controlable through ONVIF extensions, and VMS companies can add value to their offerings by supporting those extensions.

    In order to make ONVIF work, they need full adoption in cameras. Today ONVIF support looks like a box-spec feature–something that needs to be supported in order to meet the buyers requirements. ONVIF won’t really take off until camera developers view ONVIF as a solution instead of a requirement.

    But ONVIF itself isn’t helping camera adoption. ONVIF looks like it was designed by a bunch of guys who only know “enterprise” solutions like Java and XML and Microsoft. Unfortunately, a lot of those “enterprise” solutions are big and bloated and are really hard to work with when you are developing a low cost embedded system like a camera. ONVIF and all of its soapiness are really hard to work with for programmers trying to write camera firmware.

    1. Writing camera drivers is sometimes very easy, sometimes very difficult. When Milestone was just starting out, we had no leverage and had to write the drivers to make our offering more attractive. When we became bigger we’d be approached by camera-manufacturers that promised to sell thousands of licenses, if we only supported their camera. We’d put in the hours, only to realize that the sale did not go through. We had just wasted a lot of man-hours for naught (well, a few more cameras on the supported list, but not much in terms of cash in hand). Charging for writing camera drivers put some (all) of the risk on the camera manufacturers, while the VMS vendor gets a few more notches in their belt. At some point I believe that writing drivers was actually a substantial revenue driver, but the industry as a whole would (probably) have been better off with some well established, approachable protocols sooner.

      I believe that the massive volume in the mid-low end segment will benefit the most from ONVIF, and they will simply pick the cheapest Camera/VMS/Integrator combination. The licensing cost of an NVR will probably be baked into the cost of the camera, and it will be only a few dollars per channel. I am on the fence on ONVIF. I so want them to succeed, and if they don’t I expect that a sort of ONVIF Lite might evolve on its own. I am actually a little depressed that this hasn’t happened yet.

      This might leave the incumbents fighting for the complicated installations, spanning multiple sites, integrating with all sorts of 3rd party apps. The question is then – can the old guard change gears, and provide the kind of service needed, or will the transition from “moving boxes” to providing full service and custom development be too much for them to handle?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: