ONVIF Video Surveillance Tutorial

By IPVM Team, Published on Jan 29, 2019

ONVIF is well known within the surveillance industry as an interface to connect IP cameras and VMS systems.

However, new users may find it confusing, with questions such as:

  • Is ONVIF a standard?
  • Why ONVIF?
  • What does ONVIF do? What does it consist of?
  • Who supports ONVIF? What does that mean?
  • What are ONVIF Profiles? S vs G vs Q vs T
  • How well does ONVIF work?
  • Does ONVIF work with H.265?
  • What about advanced features?

Inside this tutorial, we answer all of these questions. Note: If you are not familiar with APIs, you must read our API tutorial first as understanding ONVIF's capabilities depends on knowing how APIs work.

What ** *****?

***** ** ****** ******************* ** ****, *****, and **** ** **** with****** *** *********** **** ************ ***************** *********** ******** ********, and ********* **** * number ** "********" ***** contain ******** **** ** functionality, ***** ** ***** in **** ****** *****. As ** ***** ****, specifications *** ***** ******* used ** ******** ** manufacturers *** **** ******,*************** ********.

Why *****?

***** ****** ************ ******* IP ******* *** *** systems ** ****-********* *** expensive. *****, ** * fragmented ****** **** ***** surveillance, **** ******** ** manufacturer ********* ***** ****, this ****** ******* ** integrations. ** ** **** hard **** *** ***** VMS ********** ** **** up. ******* ***********, *** camera ************* **** ******* by **** ** ************ with ****** **** *****. With *****,*** ****** **** **** **** integrates **** ** ***** and *** **** ********* with ***** ***** ******* on *** ***** ****.

What **** ***** **?

***** ********* ** ****** how ******* ***** ************, also ****** ******* (**** as ** ******* *** encoders) *** ********* **** network ***** ******* (**** as *** ******** *** NVRs). ** ** ** API **** ******* ****** of ******* ****** ***** *** ******** ******* specifications. *****'* *************** *** like ***** ** *********** APIs **** ****** *************, defining *** ******* *** authenticate, ****** ** *********, request ***** *****, ***, tilt, ****, **** ******, etc. *** ***** ********** is **** **** ************* can *** ** **** by **** *************.

ONVIF ** *********** ****

** ******* *** *** systems *** *** ********** use **** ***** *** their *** *********** ****. Since ***** ** ********** new, **** ************* *** already ********* ***** *** APIs. ************, ************* *** offer ********* ** ******* functionality ** ***** ***** own. *** ******* ** this ** ***** *********, which *** ******* ******** calibration *** ************* *********, not ******* **** ** the **** ****** ***** profiles ***** *********** ******** events. ******* ** ********* video*********, ********* *** **** fisheye / *** *******.

**** *****, ***** *** supports * **** ***** range ** ***************. ****************** *********** ******* ******** ***** supports, **** ** ****** IO, *** *******, *********, video *********, ***. *** of *** **** *********** are******************** ***** *********** / setting ****** ** ***** / ****** **********.

ONVIF **. **** / ***

******* ********, ***** ** the ** ***** ********** of****/***, ****** ***** ****** far **** ******** ************* with **** ****** **********. NTSC / *** *** unidirectional, ******** * ******* video ******. ****, ******** with **** ***** **+ years ***, **** ***** standards **** ******** *** easy ** ***. *******, resolution *** ***** **** are ******, *** ** configuration ******** **** *********. If *** ****** ** control ** *** */*, PTZs, *********, ****** ****** settings, ***., **** *** to ** **** ********** as ** *** ******** from *** *************.

****** **.*******

******** ********** ***** *** divided **** *** *********** types / *****:

  • * "******", **** ********* an ** ******, ** a ******* **** ******** to ***** ********. ******* are **** ********* ********, recorders ** ****** ******* panels.
  • * "******", **** ********* a ******** / ***, is * ******* **** makes ***** ********.

*** **** ****** ******** would ** * ******, like *********, *******, *****, etc. ****** ** ***** request ** ** ** camera, **** ****, ******, Hikvision, ****, ***.

*********, * *** / recorder *** *** ** a "******", ********* *** video / ********** ** requests **** ***** *******, but **** ** ****** rare *** ***** *** fully **********.

Profiles *** *****

***** **** * ****** of ******** ***** ****** a ******** *** ** functionalities, ** ***** *** quickly *** ******* * given ******/******** *********** **** integrate. ***** *** ******** four ***** ********:

  • *** *** ****** *** most ******* ********* *******, covering **************, *** ****** ** sending ***** **** * camera ** * *** / ********. * ** what **** ************* *******.
  • *** * ******* ***** to ******* ****** ***** stora**. *** *******, **** could ******* ********** *** sending **** ** ** camera **** **-***** ******* to * *** / recorder.
  • *** ****** ******* **** **** to ******************* ******* *** ******* security, ** *********** ******* passwords. ** ** *** end ** ****, ** is ********** *******, *** has ****** ************ *******.
  • T is the latest ONVIF profile, which improves integration of H.265, motion, analytics, and other events, as well as advanced settings such as exposure, focus, contrast, etc. See ***** ******* * *********** **** *******.

Archived *******

***** ** *** ******* of *** ******* ******, ONVIF ****** **** ******* numbers, **** *** ***** revisions (******* *.* *** 2.x). **** ******* *********** was **********, ******** ***** the ***** *.* ************* were "********" (******** ******** *,***+ ********). *******, ***** ** longer ********* *** **** of ******** ******** *** does ***** ** ************* guarantee. ** *** *****, 1.x ******** **** *** more ****** ** **** integration ******.

Codec *******

******** ******** ** *****'* specs **** ******* ** H.264, *****, *** ****-* streaming ****, *** **** now ******* *.*** *** potentially ***** ****** ****** using**** ***** ************** ***** *****'* ***** Media2 ******* (****** *** **** ***** Will ******* *.****** **** *******).

************, **** *** ******* of ******* *, *.*** is *** *** ** the ******* ********* ******. While **** ***** **** supported *.*** ** ***** cameras, **** *** ********* required ********** *********** ** properly ****** ****** *********. However, ***** ******* *, cameras **** ***** ** H.264 ** *.*** ****** out ** *** ***, and ***** **** ********* this ****** ********, ******* simplifying ***** *.*** ***********.

********/ ***************

***** **** ******** ******* services, **** ** ***** are ******** ** **** broadly *********. **** ** the **** ******* ********:

** ** ********* ** keep ** **** **** direct *********** ************ ***** cover ***** **** ****** / ******** ************. ** contrast, **** ***** *************** do *** *** **** can ** * ****** of ***********.

False ****** ** ***** ***********

*** ******* *** ********** method *** ******* ***** conformance ** *** * manufacturer ** *** *** current ******* ** *** ONVIF **** **** *** to ****** ******* ******* to *****.

**** ************* ****** **** process, *** ***** *** been************ *** ** ********* conformance, ********* ************* ******* ** ************ fake ******. ** ********** ******* of ***** ***********, **-**** products **** ***** ***** "compatibility." *** *** ******* check ** ******* ** up ** ******** ******** *********** *********.

**** ******* ********

***** *********** ******* ** performed ** **** ************ and ** *** ******** by ***** ** *** third *****. **** ************ uses *** ***** **** tool ** ******* ** their ****** ** ********. This ***** ********* **:

** *** **** ******, the ************ ********* * passing ****** *** ******* it ** *****, ***** then ******* *** ********* it ** ***** *********** directory.

*** ******* ******* ** that ***** ******* *** be ***** *** ** have ***** ******* ** manufacturers ***** **.

ONVIF ****** ******* ** **********

***** ** ******* ********* in ********** *** ******/*** integration ********* *****, ** least *** ****** **** as ********* *** ***** configuration. ****** *** ***** manufacturers ******* **, **** over **,*** ******* * devices ***, ** **** 6,000 ** ****, *,*** in ****, *,*** ** 2013, *,*** ** **** and ******* ** *** *** of ****. ****** *** **** strong.

*** ********** *** ********* video **** ******* ** VMSes,***** ****** **% ** the **** ** ****'* test** ** ****** ************* and * *********. *** biggest ****** **** **** archived, ***-******* ********, ************ for ****** *********, ***** no ************ ****, ******** to ******* ****, ***** 50%+ ***.

*** ****, *******'* ***** **** ****.

Advanced ******** ********

***** ***** *** ****** strong ** *** ****** of ********** *** ********* video **** ******* ** recorders, ******** ********, **** motion *********, **** * significant **** ** *******. Moreover, *** ************* ********* have ** *** ****** integration ** ******* ****** detection *** ***** ** each ********** ************. *** control, */* *** ***** analytics *** ****** **** equal ** ******* *********** problems, **** **** *** newer ******* *.

******* * **** ** improve **** ** ***** integration ******, **** ****** detection, ******* ******, *********, and ******* ************* ******** now *********, **** * new ************ ********* *** video ******** ****** ** well ** *************. *******, this ******* ** **** new (******** ** ****) and ******* ** ** far *******. ** **** to **** ******* * integrations ** **** ** support ******* **** **********.

Recommendations ** ***

**** ****** ***** *********** has ******** *************, ** recommend ********** ** *** proprietary '******' ********** ** a *********** ******** **** ONVIF *** *** *********** one ** ** ******* risk *** ***** ******** extra ***************. *******, **** looking ** *** ******* or *****, ***** ******* is ** ********* ****** in ********* **** *** uses. *********, *** ****** test *** ****** ***** preferred *********** *** ** is ****** **** ***** will **** **** *********** previously ************ *******.

Profile * **** ********

*** ******* ** *****'* advanced ********* *******, ******* T, *** ******** *.*** and ********* *** ******* for *** *******, ** well ********** ***** *** focus *******. ************, ** standardized ********* *******, ********* rule *** ****** *************, but **** ** *** a ********* *******.

*******, ***** ******* * conformant ******* **** ****** common, **** **** *,*** models ****** ** ********** from ****** ** *************, VMS ******* ******* **** limited, **** **** **** recorder ************* ****** ** conformant ** ******* ****.

************, ***** ******* * improves *.*** *******, ** does *** **** ** mandatory *** *****. ****** manufacturers *** ****** ** support *.*** **** ** ONVIF *******. *******, ***** VMD **** ****** ** be ********* ******* ********** cameras *** ***** ** have ******, ** **** not **** *** *********** of ******** **** ** region ************* ** *** testing.

********* ****** *** ****** to ******* **** ****, but ** ****** ********* integrations *** ******* * to ****** * ***** feature ** ***** ** little ********* *** ************* to **** ** ***** features ** ***** *******.

[****: **** ******** *** originally ******* ** **** but *** ************* ******* throughout **** - **** to ******* ******** ** ONVIF ** **** ** to *** ******* *******.]

Comments (67)

A few points and comments as we are actively developing Profile S right now:

1.) Profile S defines a minimum of features found in the Original 1.02 Onvif. So this means from a developer’s perspective it's not a major overhaul which is positive for companies who have already developed previous releases.

2.) Profile S mandates specific features of Video Motion Detection which previously lacked and is obviously the #1 thing wrong with Onvif-IMO.

3.) Profile S mandates 3 codec’s to be over RTSP (MJPEG, MPEG4 or H.264) but only mandates the transmission of 1 (Obviously our preferred method is H.264).

There are many other points but our underlining consistent concerns are that Onvif is a moving target to constantly develop with which continues the problems VMS's have in supporting camera manufacturers API changes to begin with. From what we've been told Profile S is "the standard within the standard". Our other main issue is not knowing which VMS manufacturers are moving to Profile S as it stands right now it's a very underwhelming list. Have you considered doing a poll of VMS/Camera Manufacturers who have put Profile S on the development board?

Tom, great feedback. Thanks. I had not looked at the breakdown of camera vs VMS support for ONVIF Profile S.

Interestingly, it looks like a lot of the major VMSes are ONVIF conformant but not Profiles S conformant.

From scanning through the list, the following VMSes are Profile S conformant: Milestone, DVTel, NUUO, NetworkOptix

However, these VMSes support ONVIF but not Profile S: Genetec, OnSSI, Exacq, Avigilon, Aimetis, Axxon, IndigoVision, Koukam, March Networks, Mirasys, NextLevel, QNAP, Pelco DS,

While I didn't call out every VMS, it is quite clear that most VMSes are not Profile S, despite having more than 700 camera models supporting it. I'll send some emails to see if I can get any color on this. Thanks for raising this!

Interestingly older versions of Genetec Security Centre had the Profile S option when enrolling a camera. However in 5.7 the options have changed to Basic or All.



Good feedback on the naming change. If you look at the "Security Center Video Unit Configuration Guide 5.7 GA" (available on Genetec GTAP), it breaks down the differences between Basic and All in the "Supported Features for ONVIF compliant video units" section.

It appears to be just be a naming change (I emailed Genetec for clarification), as the All configuration supports features like Camera Settings, Firmware Upgrade, Audio Output Streaming, Metadata support, relative/absolute PTZ controls, I/Os, Edge Storage and Video Analytics events support (face detection, object left behind, tampering, etc). 

Additionally, Genetec Security Center is listed as G and S Conformant

So security center is listed as an ONVIF client only? If a 3rd party ONVIF client wants to playback recorded footage from a Genetec Archiver (NVR) via ONVIF profile G, will that work? If so then shouldn't it be listed as both s client and server?

Genetec is G/S client only, not device. So you cannot play back video from a Genetec Archiver via Profile G.

Thanks Ethan. Is Axxon Next both an ONVIF Profile S & G client & server? Or just a client? Is the Milestone ONVIF Bridge considered to be an ONVIF Profile S & G compliant server only? Or both client and server?

Rashid, I recommend checking ONVIF's conformance products list, since they are the official source.

For example, on your Milestone question, Milestone only has ONVIF conformant G 'clients', no 'devices' listed currently:

Moreover, when I searched the ONVIF directory, I found no listings for the Milestone ONVIF bridge.

Hi John, Milestone are selling their "ONVIF bridge" product which is not compliant?

I believe so given it not being shown on the official directory, also when we tested it a few years ago, that was the case, as we said then:

the 'ONVIF' Bridge, despite its name, is not officially ONVIF conformant, as it only uses a subsection of ONVIF capabilities, which eliminates the benefit / potential of validating both sides to the official ONVIF standard.

I think you know ONVIF so that's ONVIF being ONVIF. I agree though, generally, products that use the term 'ONVIF' should actually be 'ONVIF' conformant.

I've reached out to Milestone to ask them for any updates or corrections on this.

One thing we learned when trying to access ONVIF streams from Axis cameras is that the VMS must have some form of ONVIF configuration tool. That is directly from Axis - when I questioned their rep, he confirmed that they provide no method to configure the ONVIF stream themselves (specifically resolution, bitrate, compression levels, etc.).

The user can set general features like brightness, contrast, zoom, focus, IP addresses and passwords via Axis' web configuration but not codec-specific functions.

Carl, I am not sure what you mean by a 'configuration tool'? The VMS can simply integrate/embed those controls for changing settings via ONVIF within its standard administrative pane/camera configuration section just like it does for Axis cameras via VAPIX, Sony cameras, Vivotek, Arecont, etc., etc.

Even if Axis allowed you to configure the ONVIF stream settings in the web interface (like resolution, frame rate, quality, etc.) you'd still almost always want to do it via the VMS application anyway as it is easier and can benefit from batch configuration capabilities, etc.

OK. Let's take, for instance, Dallmeier. They claim to be able to read ONVIF streams, however they have no tool to configure the stream. Hence, if the camera defaults its ONVIF stream to MJPEG at 25Mbps, that is all the Dallmeier system will receive. Changes made in the Axis camera's web page have no effect on that.

Another example: we also tested a Ganz PixelPro camera. Although we were able to get "live" 30fps streaming video from its ONVIF stream through IndigoVision's ONVIF Configuration Tool, recording the stream was another matter - the video dropped a large number of frames.

That's neither an ONVIF nor Axis issue. We've used many VMSes with many ONVIF cameras and pretty much all of them allow you to configure an ONVIF stream inside the VMS admin interface, just like any other camera with a proprietary / direct integration.

By the way, look at Dallmeier's ONVIF conformance page, I do not see their recorder/VMS, only cameras and encoders. I'd check if it's actually officially ONVIF compliant.

Another point: apparently ONVIF is not as generic as say, NTSC. We found in the IndigoVision system that even though we were configuring an ONVIF stream, the camera, or at least the camera manufacturer must be present in the ONVIF Configuration Tool utility.

This also is confirmed by our attempts to access ONVIF cameras with the razberi IT-5000. Although it was able to access the stream from our Axis cameras, it failed to access IndigoVision, Dallmeier and even the Ganz cameras' ONVIF stream.

Re: 'the camera manufacturer must be present', that's an IndigoVision implementation approach, neither required nor common in other systems. What other ONVIF conformant VMSes have you used?

That some 'ONVIF' cameras can be accessed and others cannot shows that difference in implementations can cause problems, but that does not mean you must enter in the camera manufacturer / model in some bizarre stand alone configuration tool utility. Btw, did you speak with Razberi and did they have any advice?

Yes and no. They just offered to issue an RMA. We returned it yesterday.

Frankly, all this has led to a vast amount of frustration on our part. ONVIF this, ONVIF that. It's definitely not any real "standard", like NTSC. I can take any analog camera and view its video. I have not seen the same capability with IP cameras, even from so-called "open architecture" VMS' and "ONVIF-compliant" devices. I distinctly recall conversations with Genetec in this regard. We had someone trying to sell us inexpensive IP cameras but the Genetec rep said that they won't go through the steps necessary to add the camera to their list of supported devices unless the camera manufacturer (importer) paid them. The importer has the option to self-certify their cameras with a tool Genetec provides (unclear on price) or possibly via full ONVIF compliance.

I can't claim to be an IP expert but it seems to me that a standard should be a standard, not a bunch of "maybes".

A 4 year old 'standard' that attempts to ~100 different functionalities is not going to be as mature as 50 year old one that standardizes one functionality (video stream only). Expecting as much is not realistic.

That said, you are using one VMS that claims to be ONVIF conformant but is not (i.e., Dallmeier). You can't blame ONVIF for that. You should check for conformance and push back on the vendor here.

Another VMS (IndigoVision) has a long history of only selling its own IP cameras and likely has internal resistance about supporting 3rd party cameras.

I certainly believe the story about Genetec but Genetec does support ONVIF and that's what ONVIF is for. No VMS, even Milestone and Genetec, can directly support every camera manufacturer in the world.

I will say this - ONVIF sucks at marketing - and here I mean the basics, setting expectations, communicating progress, issues, helping 'customers'. They had the one guy who knew nothing and then bizarrely went to Samsung. Now, even we have no idea how to get in touch with anyone at ONVIF. We're hoping Axis can help facilitate this but no luck yet.

We've seen far more than enough success using ONVIF to connect IP cameras and VMSes to know it is viable and useful. I certainly agree that are still many integration issues, made far worse because ONVIF as an organization is MIA in helping to communicate and resolve these issues.

As for you, Carl, try another VMS, one that doesn't sell their own cameras and is officially ONVIF conformant, I think you'll have a better experience.

No sweat. Dallmeier is dead for us and Geutebruck comes in on Monday.

John, we have two specifically different issues here - VMS functionality and usability versus IP camera capability. We're not going to pick a system based solely on its ability to use any IP camera, there are far more factors to consider. Genetec failed our Phase 1 evaluations due to functionality issues - we didn't even test IP cameras during that phase, since even after our system replacement over 90% of our cameras will remain analog.

Dallmeier failed our Phase 2 testing because of other issues too, not because of their lack of ONVIF conformance. IndigoVision passed Phase 2 because it met many of our goals and we were at least able to access Axis cameras via their ONVIF stream. A key point in all of this is that we resist manufacturers like Dallmeier whose unstated (but readily apparent) goal is to force their customers to purchase only their own devices. We at least want the ability to test many brands and models of IP cameras in the future to see if they offer any specific form factor, capabilities or features that others do not.

"~100 different functionalities" seems like a recipe for disaster (if you are chalking up a "standard")

Morten, what's the alternative then, no standard? A simpler one that only focuses on a handful of core functions?

I wonder if they would have started with Profile S, how much crazy issues would they have avoided?

The other think seems to be the rapid uptake / deployment of ONVIF, seems to have made things worse. I wonder if a controlled beta release with only a limited number of parties would have reduced issues.

Morten, what do you think should be done to improve ONVIF? Seriously, I think you're opinion would carry a lot of weight, a least with me :)

Right now, ONVIF is just another protocol to support. Actually, it is multiple protocols, because different camera manufacturers have different interpretations of the ONVIF spec (no wonder). It's a protocol that camera manufacturers can follow if they so please. In time it might become a de-facto standard, but I am not waiting with bated breath.

ONVIF should forget about device discovery, authentication, gateways and whatever else they are trying to solve. Just focus on 3 simple things. 1) Getting video, 2) Getting events and 3) Optical control.

To figure out what video formats the camera supports, we could agree on a URI, e.g. a client can open the URI http://ip/ONVIF/videoformats and get a list of supported formats in JSON format for example. For each format, we could define a URI that gives you the supported parameters. This could be http://ip/ONVIF/formatcaps?formatid=[id]. It might tell you what resolutions the camera supports in the specified format.

I believe that it would be reasonable to define a set of options that must be supported (for H.264 VBR and CBR), and thus we wouldn't need to query those caps. But resolutions do differ on different cameras, and we need a way to query this.

Once we have determined the cameras capabilities, the RTSP URI that you open should ALWAYS be the same - e.g. rtsp://ip/stream/[and then the capabilities that we have negotiated]. Like so


Instead every single manufacturer wants to invent a different URI for their particular camera. That alone means that either the user/integrator has to dig out this info from the manual (who reads them), and enter it for every single camera, and update the URIs if they change the camera, or update the firmware. It. makes. no. sense.

If camera manufacturers could agree on, at the very least, a standard RTSP URI we'd have come a long way - even we omitted the capability discovery mechanism it would make things much simpler.

PTZ controls and changes to apperture, gain and so on could follow the same principle. How many ways do you need to express the desire to move the camera to the left, or to change the f-stop?

Events are slightly different. The simplest support should just be to get the camera to send a TCP packet with a certain syntax when "something happens" to an IP address. Alternatively, the server can connect and the camera can send info downstream. More advanced events that carry event meta-data would require a little more work. I expect a simple key-value array could be sent from the camera to the server.

When I started in this business around 2000, I drafted a (naive) universal spec. I spoke to Axis about it. At the time they said "everyone else can just use VAPIX" which was a great idea, because VAPIX is simple and very easy to use. Then they started suing people who did. Axis should scrap ONVIF and make VAPIX a standard.

But I guess being an armchair coach is always easy :)

Morten, thanks for the detailed analysis! A number of those simplifications could help greatly in making ONVIF easier to implement and less riskier for integrations.

The big challenge is hundreds of companies have already developed ONVIF implementations. It's not so much as being 'an armchair coach' as much as 'the horse has already left the stable'. Given that, the question becomes what can be done, with minimal effort, to take what people have already done and best increase the probability that ONVIF implementations integrate? Scraping and restarting things is likely not politically feasible :)

John, your first statement is not really correct:
1) A de facto standard - such as those promoted by industry consortia and trade associations (e.g. USB, Bluetooth) - are just as semantically valid as a "standard" as any standard recognized by international standards bodies.

2) Both PSIA and ONVIF are actually included in the recently ratified European CENELEC standard EN 50132-5-2:2011 on IP network surveillance.

This standards document defines "protocol requirements to be fulfilled by any high-level IP video device interface", and adds "two alternative protocols, one based on HTTP and REST services (PSIA) and a second based on Web Services (ONVIF)".

Both groups are also in liaison with IEC TC79, which means that IEC will probably end up "adopting" both standards in a similar fashion as CENELEC.

Benjamin, thanks for the feedback. I asked Axis/ONVIF about European CENELEC 6 weeks ago but still no confirmation! I updated the note with a reference to this.

It's pretty funny that PSIA has become a 'standard' considering its poor support. The other big question is what does it mean for it to be a CENELEC standard? i.e., does it matter / count in the US or the rest of the world?

As for whether a trade association promoted 'standard' is just as semantically valid as an International standard, there seems to be disagreement about that. Ultimately, I think the two most important things are (1) how broadly is it supported? as any standard without support is worthless and (2) how well/reliably does it work?

Fortunately it was the wrong horse that left the barn. Let that horse run, never to be seen again. The hundreds of implementations are still at their infancy and they should cut their losses now. I have never heard of anyone requesting ONVIF support when a proprietary driver was available, and I have never heard anyone recommend buying cameras that were not directly supported by the NVR.

I'd love to know if any end users are directly requesting ONVIF, and if they deliberately chose a camera that is only supported via ONVIF in the NVR. Does anyone feel that it is "safe" to recommend arbitrary ONVIF certified cameras and NVRs?

Don't get me wrong. I am not against a standard. I would LOVE a standard to emerge. And when I get the sense that I can go online and buy a dirt-cheap IP camera and just plug it in, just as I can a USB memory stick, then I will celebrate and admit that I was wrong.

Yes, no one requests ONVIF if a proprietary driver is available but that's not the point. ONVIF isn't supposed nor does it need to be 'better' than a proprietry driver. As long as it enables the connectivty that the user needs, that's good enough.

I doubt end users directly ask for ONVIF but they certainly frequently desire cameras that do not have direct integrations. To that end, ONVIF serves a customer need - enabling combinations that otherwise would be impossible.

I think it's safe to recommend ONVIF cameras with a basic integration test that any integrator or user can do. Even in our tests/usage, we have had good success with a number of IP cameras connected to Exacq, Avigilon and Milestone (those are the ones we've tried with).

I'm not sure you could call either of them a standard yet, as they are only included in appendices as alternative protocols. But they are nonetheless included as the relevant alternatives. CENELEC is important for EU-wide adoption, and ONVIF/PSIA complicane could be required in official tenders, pushed by national industry associations etc. IEC is as official and international as it gets, but as far as impact I don't know. The relevant US bodies are SIA/ANSI and I'm not up to date as to what their current stance is towards PSIA/ONVIF.

I agree with your last sentence, and this applies equally to both industry-driven and official standards.

This is exactly my point. If people just want basic interop, why is the ONVIF core spec 145 pages long? All they want is a simple, but robust way to get video into their system via a cheap no-name camera. This, I believe would be enough for 99% of all installations. But ONVIF is trying to make a system that will handle the 1%'ers out there, and thus the spec makes it real hard to get good 99'er.

Well it's not just the core spec. Then you have the dozen service specs to boot!

We clearly agree that they need to make it easier to get the basics done. In particular, not getting streaming video every single time certainly causes so much frustration and ill will towards ONVIF.

"I have never heard of anyone requesting ONVIF support when a proprietary driver was available, and I have never heard anyone recommend buying cameras that were not directly supported by the NVR."

I would. Or to be more accurate, I would prefer that the industry adopt a standard that is a true standard. I don't care if it's ONVIF, PSIA, VAPIX or whatever. I want to see full device compatibility, like USB or SATA or IEEE 1394 or any of a number of uPnP devices.

That is what I feel is the most serious problem in our industry. It is so fractious that the major players (followed by the minor ones) can't agree on a standard and fully compatible interface. Sometimes, I think at least the HDcctv Alliance is pointed in the right direction, despite the grating personality of its most vocal protaganists.

Thanks for tackling this subject, John and team.

It is not technically valid to say that ONVIF is the IP video equivalent of NTSC. USB, NTSC, and HDcctv are comprehensive electrical/mechanical interface standards. Ethernet is the IP video equivalent of NTSC. ONVIF relies on Ethernet and other IP networking electrical interface standards, while ONVIF itself is a set of recommended protocols that leaves many aspects of the transmitted signal unconstrained. That is the source of the interoperability issues that plague systems incorporating ONVIF-conformant products.

Todd, as I said, "Loosely speaking, ONVIF is the IP video equivalent." I don't think it is technically the same but at a high level ONVIF is trying to do for IP cameras what NTSC/PAL did for analog cameras.

Carl's comments point out something that I wish more people were aware of... "ONVIF", or any standard, is only one of several key things that need to be taken into consideration in order for a system to work "as expected".

Before ONVIF it could be a game of "find the magic string" in order to receive a video stream from a camera, much less access more nuanced feature. Or, it was a game of "wait 6 months for my VMS vendor to basically update a text config file" (yes, I'm dramatizing a bit).

If we have 100 steps to go from "Wild West" to "Fluid Interoperability", ONVIF/PSIA probably took us from being 3 steps along that path to about 8 steps. However, just because your camera and recorder both have the "ONVIF" logo, that doesn't mean your job is going to be all plug and play.

This is of course the other side of the coin to having highly complex camera systems with a multitude of features, options, etc. In the end I don't think that anything less than this (eg: "hi res analog", HD-SDI et al) is really a solution that is going to be accepted by modern customers, but we are certainly in that phase just like early PCs and early networking before eevryone in IT got a good grasp of the similar concepts.

Btw, I heard from ONVIF today. They noted that there are a number of new committee members plus a new chair and that they are willing to help provide feedback. I asked for a meeting with a technical ONVIF rep to discuss details and get feedback on particular low level issues / problems. I'll update as this progresses.

This article and conversation are really refreshing. How many times have we read manufacturers' claims of plug-and-play due to ONVIF conformance? As you point out above, those claims lack technical merit.

Also, it's valuable that you point the subtle costs of integrating non-readily-interoperable equipment. So many proponents of IP cameras tend to minimize those costs, and I salute your honesty.

Brian, I disagree with your implication that ultimately every camera should be an IP camera, even in highly complex surveillance systems. Your reference to PCs and I.T. networking is really instructive. Modern PCs sport several interfaces in addition to Ethernet/Wi-Fi: USB, HDMI, SATA, 2-wire audio, and others. The I.T. world does not force-fit everything to Ethernet, nor should the surveillance world. A modern surveillance system includes HDcctv and NTSC/PAL and Ethernet interfaces within local sites, while simultaneously taking advantage of IP networking for inter-site and remote communications.

I agree with you, Brian, that HD-SDI lacks many of the capabilities enabled by Ethernet interfaces. HDcctv1.0 was based on HD-SDI, simplified and adapted for surveillance. HDcctv 2.0 introduces many of those advanced capabilities, with more to come in later versions.

The various implementations of HD-SDI do present interoperability challenges, although not as severe as the interoperability issues confronting IP cameras. But, as you point out, HD-SDI interfaces offer only very basic video delivery capability. Nobody is working on compliance certification for HD-SDI, or integrating the disparate specifications, or extending the capability set of HD-SDI.

[NOTE: Todd Rockoff is the head of the HDcctv Alliance.]

As a comprehensive, compliance-tested electrical interface, HDcctv compliance assures out-of-the-box plug-and-play. Given your acknowledgement of the importance of advanced capabilities and of interoperability, there would appear to be scope for members of this forum to support those 70+ companies who are developing the HDcctv standard.

Todd, there are lots of combinations that are plug n play using ONVIF. We use them all the time. We are not saying that ALL combinations are plug n play but many are.

You've made your point about your offering, HDcctv. I'll let is stand as is (with my edit to note that you are the head of it). No more discussion on this post about HDcctv. Keep it to ONVIF, whether its questions, praise or criticism.

I am not a software developer but just IP camera user rather.

I am just wondering whether I may expect certain functionality of ONVIF-conpilant camera with ONVIF-compilant VMS when ONVIF supported versions of camera and VMS are know (1.0, 1.01, 2.0, Profile S)???

Dawid, there's definitely some risk there. Also, it is not always easy to verify what version each device is currently on. This is, unfortunately, why testing oneself is critical before committing/expectations of an ONVIF integration.

wonder why BOSCH was involved in ONVIF?

IPVM Response: I don't know what the original motivation was in 2008 but now they are releasing lots of IP cameras so it benefits them to maximize the amount of VMSes that those cameras can run on.

We've spoken with ONVIF and are setting up a call to discuss technical issues. Let us know what you would like us to ask ONVIF.

1. How was WebService / SOAP / XML chosen over other alternatives JSON /JSONB / REST and the like ? Seems the latter would find more rapid adoption and simplify integration efforts.

2. How much contemplation and focus was given to PTZ move operations?

3. What alternative authentication methods / technologies were considered ?

This was decided 12 years ago. Even then, the SOAP vs REST decision was debated, but that was locked in long ago.

I don’t know how much consideration was given for PTZ movement optimization but it certainly has been a source of practical problems

It appears to those of us who showed up recently (a decade ago counts as "recently" in physical security time) that the instigators of this protocol all came out of large dev environments where (what appear to others to be) heavyweight mechanisms like SOAP were considered acceptable. I'm assuming at least half of the 1000+ engineers at Bosch thought SOAP was perfectly reasonable ;-)

ONVIF is now old school and maintains a significant amount of “bloatware”.

To understand ONVIF, I suggest you study AXIS VAPIX. It wasn’t BOSCH that drive this ship IMHO.

See our new post covering Detailed Technical Answers from ONVIF.

Dawid, in this post, we discuss the differences between versions and issues therein.

I wonder can onvif be used to call cgi style commands to cameras? So if I wrote a script to use onvif to ptz a Sony dome would it also work for a hik dome? Or have I got it wrong for url commands?

Yes and no.

Yes, the instructions theoretically should be portable.

No, not just a URL.

Although it's http, it's your NOT going to be able just to send some url like http://<IP>?action=movePTZ&x=10&y=50&z=100.

Its a lot of stateful and SOAPy stuff before you get even close to that. Probably a couple thousand characters of XML back and forth before you even dare try to command a PTZ.

See the penultimate paragraph of Rodney's rant below for confirmation and consolation.

Its a lot of stateful and SOAPy stuff before you get even close to that. Probably a couple thousand characters of XML back and forth before you even dare try to command a PTZ.


but... it still doesn't work; it still doesn't induce interoperability; it still is a mechanism to suppress features. It is a great tool to show $35 devices from China can follow a spec better than the established players. Tell me again why we should use OnVIF? Certainly not to get multiple vendors to work together.

It still fails some basic interop metrics:

-- there's no open source camera

-- there's no open source client/victim/vms/whatever-you-call it

-- there's no open source test tools (the free Russian thing is quite useful but it's closed source)

-- you can't trivially find 3 genetically separate implementations

-- it doesn't eliminate the skanky vendor-specific API's

-- VMS vendors who support OnVIF still don't understand they look like fools when they shout about how many billion camera SDK's they support. It's the 21st century, people, get with the (interoperabilty) program... customers are noticing...

Also the repreresentatives from Planet OnVIF still walk around obliviously asking device vendors to load a bloated mechanism on top of a fat web server and so of course they're getting ignored.

By the way it's not secured. I haven't proven people sneak back-door accounts into cameras to support onvif but I'm seeing extra users in the onvif test results and that's scary. BTW they're TLS-illiterate (yeah John I'm sure you've got some other thread about that, not meaning to drag that conversation here.)

Also the repreresentatives from Planet OnVIF still walk around obliviously asking device vendors to load a bloated mechanism on top of a fat web server and so of course they're getting ignored.

ONVIF has support from nearly 6,000 devices and these are only counting the people who went through the trouble of submitting conformance reports. You may think ONVIF is done poorly, but it's certainly not getting ignored.

Tell me again why we should use OnVIF? Certainly not to get multiple vendors to work together.

Rodney, lots of people in the real world use ONVIF to get multiple vendors to work together. Maybe they 'should' not, but they do - regularly.

Is ONVIF better than what we had before? Yes, very much so.

Is ONVIF perfect? Far from it.

Btw, in terms of open source, see the open sourced ONVIF Device Manager and ONVIF Camera Code Open Source'd (Vicon).

Hi John, can you suggest an ONVIF Profile G client software that I can use to test Milestone ONVIF Bridge Profile G conformance and performance please? It obviously has to be other than from Milestone/Axis/Canon. Thanks

You can download a fully functional version of Axxon Next which is Profile G conformant. We tested it in our ONVIF Profile G Video Storage Test.

Thank you Ethan.

Hi Ethan, on Axxon Next website, the Axxon Next Demo (evaluation version) would it include the ONVIF Profile S & G compliant client?

Also, for some unknown reason, i do not get email notifications from IPVM anymore? I have *.ipvm.com in my safe senders list and the notifications are not turning up in junk either. How do i change that?

Hello Rashid,

Your address was on our suppression list because we received a spam complaint for a previous email we had sent. It was probably accidental. We have removed the suppression, so you will begin receiving our email notifications again. If you have any questions, please feel free to contact me directly at ryan@ipvm.com.

Hi Ethan, on Axxon Next website, the Axxon Next Demo (evaluation version) would it include the ONVIF Profile S & G compliant client?

It should, yes. You'll need to install the server and client, then add the Milestone ONVIF Bridge to it with the storage location as the edge storage. I haven't done it in awhile, but don't recall it being too complex.

This video from our Profile G test shows the basic setup and use of Profile G in Axxon. Configuration is essentially limited to enabling embedded storage and switching playback location from local archive to embedded on each camera.

Hi, I have installed the ONVIF Bridge but am unable to find the ONVIF role in the security settings when defining the role. I have followed the YouTube tutorial as well and do not think that i have missed any steps. Can anyone help please? This is the 2020R1 release.

Hi UI6,

Do you have the ONVIF Bridge plugin installed for the Management Client? If you don't then the ONVIF Bridge won't show up in security settings and it won't show up as a side bar plugin in the Management Client.

The plugin is part of the ONVIF Bridge server installer package. Just choose Custom when doing the installation on the machine running Management Client and choose to install just the 64-bit plugin (the last one in the list).

If the Management Client is open when you do this, you will need to close it and open it again to see the plugin.

Hi Jared, thanks for coming back. I have installed the plugin and can see the bridge as per your first picture but it does not appear in Security settings when defining the role.

Hi UI6,

I would suggest opening a case with our tech support. I can't see a reason why it would show up in one location in the Management Client but not the other location.

Hi Jared, I will really appreciate your help on this matter please.

Good article on ONVIF.

Great!!  Good to know what ONVIF do and good video clip for Basic ONVIF Test Tools.

I highly enjoyed reading this article regarding ONVIF. Helps me understand possible root cause why although a camera model claimed conformance, the results were not reflecting it. Talks with both the camera and vms manufacturers pointed at each other. A different VMS worked well with the camera when added using ONVIF.

Thank you much for sharing this.

Read this IPVM report for free.

This article is part of IPVM's 6,584 reports, 886 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now

Related Reports

Remote Network Access for Video Surveillance Guide on Jul 27, 2020
Remotely accessing surveillance systems is key in 2020, with more and more...
Uniview Deep Learning Camera Tested on Jul 14, 2020
Uniview's intrusion analytics have performed poorly in our shootouts. Now,...
Augmented Reality (AR) Cameras From Hikvision and Dahua Examined on Oct 19, 2020
Hikvision, Dahua, and other China companies are marketing augmented reality...
The Future of H.266 For Video Surveillance Examined on Aug 17, 2020
First H.264, now H.265, is H.266 next? H.266 was recently announced amid...
Hanwha AI Object Detection Tested on Sep 28, 2020
Hanwha has added detection and classification of people, cars, clothing...
Video Surveillance 101 Book Released on Jul 07, 2020
IPVM's unique introduction to video surveillance series is now available as a...
Hanwha AI Analytics Camera Tested on Aug 11, 2020
Hanwha has released their Wisenet P AI camera, adding person and vehicle...
Intel Presents Edge-to-Cloud Ecosystem for Video Analytics on Oct 16, 2020
Intel presented its processors and software toolkit for computer vision at...
"Fever Camera" Online Show June 2020 - On-Demand Recordings on Jun 03, 2020
IPVM has successfully completed the world's first "Fever Camera" show....
Face Detection Shootout - Dahua, Hanwha, Hikvision, Uniview, Vivotek on Jul 30, 2020
Face detection analytics are available from a number of manufactures...
Camera Course Summer 2020 - Last Chance on Jul 18, 2020
This is your last chance to register for the Summer 2020 Camera Course. This...
Verkada Access Control Tested on Sep 09, 2020
Verkada raised $80 million earlier in 2020, expanding from video into access...
Verkada Disruptive Embedded Live Help on Sep 24, 2020
Call up your integrator? Have someone come by the next day? Verkada is...
TVT Temperature Measurement Terminal Tested on Jul 23, 2020
While Dahua and Hikvision get the most attention for China temp products,...
Verkada 2020 Cameras Image Quality Test on Oct 06, 2020
Verkada's first-generation cameras suffered from numerous video quality...

Recent Reports

Panasonic Presents i-PRO Cameras and Video Analytics on Oct 19, 2020
Panasonic presented its i-PRO X-Series cameras and AI video analytics at the...
Augmented Reality (AR) Cameras From Hikvision and Dahua Examined on Oct 19, 2020
Hikvision, Dahua, and other China companies are marketing augmented reality...
18 TB Video Surveillance Drives (WD and Seagate) on Oct 19, 2020
Both Seagate and Western Digital recently announced 18TB hard drives...
Watrix Gait Recognition Profile on Oct 16, 2020
Watrix is the world's only gait recognition surveillance provider IPVM has...
Intel Presents Edge-to-Cloud Ecosystem for Video Analytics on Oct 16, 2020
Intel presented its processors and software toolkit for computer vision at...
Best Manufacturer Technical Support 2020 on Oct 16, 2020
5 manufacturers stood out as providing the best technical support to ~200...
Microsoft Azure Presents Live Video Analytics on Oct 15, 2020
Microsoft Azure presented its Live Video Analytics offering at the September...
Worst Manufacturer Technical Support 2020 on Oct 15, 2020
4 manufacturers stood out as providing the worst technical support to ~200...
Clorox Announces, Then Pulls, Fever Camera on Oct 15, 2020
For almost one week, Clorox was marketing fever cameras. The booming...
Faulty Hikvision Fever Cam Setup at Mexico City Basilica and Cathedral on Oct 14, 2020
Donated Hikvision fever cameras (claiming screening of 1,800 people/min. with...
Directory of 209 "Fever" Camera Suppliers on Oct 14, 2020
This directory provides a list of "Fever" scanning thermal camera providers...
Avigilon UMD / UAD Tested on Oct 14, 2020
Avigilon's Unusual Activity Detection and Unusual Motion Detection claim to...
Longse Promoting Hikvision Partner Fullhan Chip Based Cameras on Oct 14, 2020
With Huawei HiSilicon production being shut down at TSMC, camera...
Meridian & Goodview (BEMS Relabeller) Temperature Screening Tested on Oct 13, 2020
A lot of temperature tablets look exactly alike and that is because they use...
Monitoring Alarm Systems From Home - Innovation or Danger? on Oct 13, 2020
Remote monitoring by alarm companies since COVID-19 is bringing cost savings...