Is ONVIF a complete failure?

I like to sit on the sideline and critique the work that other people did. I tend not to participate in committees as I find them totally counterproductive.

To make a protocol a success, I think it should be simple. Now, simplicity is in the eye of the beholder, but take the original HTTP proposal. One page.

ONVIF is not just one page. It is a LOT of pages, a few concepts but a LOT of room to interpret things differently and mess things up (don’t forget to add developers tendency to make funny errors to the mix).

I am told that ONVIF is already creating problems in the real world. An NVR vendor recently announced that a new “Samsung ONVIF driver” was available. The idea that you write ONVIF drivers for particular vendors tells me that while ONVIF might not be broken per se, there are certainly problems pretty much across the board (please correct me if I am wrong).

ONVIF is really a great example of two problematic concepts. Design by committee and the second system effect. While the committee part is fairly obvious, the second system effect might need some clarification: Most people that participated in the committee had already had experience with simple HTTP based interfaces. Now, instead of picking the BEST parts, keeping it simple and then incrementally add functionality, they decided to make this the “mother of all rewrites”. No more simplistic HTTP, no, let’s go all out and throw the technology du jour at it. What about SOAP? Hell YEAH!! I guess the ONVIF guys could have chosen CORBA as well, because when CORBA was hot the community wanted to use CORBA for everything too.

Here’s one example of how the ONVIF committee, in my opinion, have compromised the user for the sake of the technology: Events are never pushed from the camera to the NVR, instead the NVR has to POLL for events. This may or may not be a problem, if you want your system to respond fast you need to poll more often. I think it is a poor design. I don’t need my app to act like a kid in the back seat asking me “are we there yet” every 30 seconds (or every second if you want something that seems a little closer to real time).

Now, I don’t pretend to know the motivation for this weird design and I suppose that there is some merit to it (I just don’t know what it would be). An alternative could have been a HTTP POST with some XPath and an expiration, the response would then be a multipart/mixed response, each payload corresponding to an event.

Don’t take this the wrong way, the ONVIF spec is a magnificent specimen of work, but I believe you have over-engineered the solution. All we needed was for you guys to agree on the same freaking URI to get video and we’d be done, instead we got something terribly complex that I believe will be too difficult for a lot of people to implement.

Advertisements

7 thoughts on “Is ONVIF a complete failure?

  1. prescienta says:

    It seems that the simple parts of ONVIF are now working; getting live video, PTZ and that sort of thing.

  2. […] 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 […]

  3. me says:

    lmao! So so true… ONVIF has to be the most bloated standard since CORBA. You’re absolutely right on the video url. The PTZ stuff is almost useless as well if you want to use joystick because a simple pan-tilt command takes an entire freaking page paragraph of ascii text. It should be a simple header indicating the command type and a float for pan and a float for tilt, but nooooo….. let’s make it thousands of characters sent to a server that takes half a second to reply!

  4. Borja says:

    The best part of ONVIF, each company implements it the way they want, you get an axis which needs to have its time sync with yours -+5seconds and their addresses for each spec(Device, Media, PTZ) are all the same, if you go to avigilon they got one for each and time can be set to whatever you wont, it will still work.

    • prescienta says:

      “It will still work”

      I think that’s debatable. Look at any of the top 5 VMS vendors – most of them (all?) rely on the proprietary drivers (VAPIX for Axis, SUNAPI for Samsung and so on), and only offer ONVIF as a last resort. In many cases, generic RTSP is actually preferred. Axis is a founder of ONVIF but still push VAPIX as the primary protocol, and ONVIF isn’t even enabled by default!?

      • Borja says:

        My comment there was kinda ironical, but still it makes no sense to me why create a standar which you need to implement differently for each camera. I have a lot of code lines that say (if camera == brand) do this

  5. prescienta says:

    Ah, OK, then we agree.

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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: