Is There An Official ONVIF SDK / Reference Implementation?

Many APIs have official SDKs or reference implementations which makes it easier / quicker for third parties to implement support.

For example, here is Facebook's SDK listing including a wide array of languages / platforms.

Github shows a handful of projects/repositories implementing ONVIF though it's not clear how up to date or how well they work.

Anyone have any ideas, knowledge, feedback on open source or official ONVIF implementations?


Open source ONVIF reference from idevicedesign. But you know about them already...

Yes, but they are worth mentioning, thanks - Ready to Go ONVIF 'Kit'

Note: it is .NET based and requires a payment.

ONVIF response:

ONVIF does not provide an SDK at this time. Neither does it endorse any of the open source and commercial solutions that are available on the market. However, are aware that our members have leveraged these toolkits in their own ONVIF implementations.

What ONVIF does provide is an application programmers guide which is available here.

We are interested in hearing feedback from the market regarding this topic. Please comment below with any thoughts and views on the matter.

The benefit to ONVIF would be that it would cut down mistakes / 'interpretation issues' / variances in implementation.

Which option do you think is more feasible for ONVIF, writing their own reference code, or endorsing someone else's?

The first is quite expensive to do and maintain, the second could appear biased.

I don't accept that it's 'quite expensive'.

First of all, the main expense is developing the huge specifications, which is already done and given away for free.

Secondly, how many of these manufacturer members already have implementations? None of them will contribute theirs? Wouldn't it be less expensive overall for multiple manufacturers to pool their ONVIF contributions to a single project?

I said quite expensive mainly because it's a moving target. I'm assuming this would become de rigueur for all specifications and versions. Just in c? Java? under Linux? Documentation? Sample hello_onvif application? What's an acceptable lag time from spec completion to code?

But maybe you mean just a basic core implementation in one language, but not necessarily every profile written or to be written.

Then I agree someone could donate it, and ONVIF could endorse it.

In this context I think of an ONVIF SDK and a 'reference implementation' as two slightly different things.

I'd propose that a reference implementation would be the camera-side software that implements that aspect of the API. It would be for those who make cameras to base their camera software on. A challenge would be the variety of underlying OS/hardware platforms it would need to target. What would be in it for ONVIF is faster/easier/more consistent proliferation of the standard. What would be in it for camera makers is faster time-to-market. Note that there would still be some divergence from the original (just as there would be today if you took some existing, 'unofficial' design and incorporated it in your camera). It would only be more uniform to some degree among those camera makers who chose to use it.

When you say "SDK" I think more of the the VMS/client side implementation. In this case it's not really a reference design but a suite of software tools and libraries one can use when targeting ONVIF devices. It could include example programs as well that could be used as a basis for further development--which might be what you're thinking of as a 'reference design' from the VMS side. But I suspect fewer VMS/NVR makers would base their implementations fully off this design. What's in it for ONVIF is potentially more consistent client/server side implementations. What's in it for (VMS) manufacturers is slightly faster time to market as well, but the vast majority of their software work is beyond this layer so it probably doesn't factor as much of an advantage as does a reference implementation for camera makers since it's not a full "implementation."

It all comes down to buy vs build decisions. We'll often 'build' even if there's a reference design available for free ('buy'). This because it might not be implemented in the technology stack we'd like to work in, or it might require more work to target our particular platform. It's not a given that just because ONVIF has a reference design everybody (or anybody) will use it. So I imagine the consortium needs to weigh the cost vs the benefit from their POV as well.

ONVIF Response:

Steve makes a good point. The correct terminology could be DDK (Device Development Kit).

"We'll often 'build' even if there's a reference design available for free ('buy'). This because it might not be implemented in the technology stack we'd like to work in, or it might require more work to target our particular platform. It's not a given that just because ONVIF has a reference design everybody (or anybody) will use it."

So you think because your massive organization won't use it, that perhaps no one would use it?

Obviously, not 'everyone' will use it but there are thousands of different organizations out there. It's hard to imagine why many (hundreds) of them would not benefit either directly from using it or from reviewing the code first to better understand the specification / implementation.

I agree completely that it could be useful to a lot of people. I should not have implied that nobody could make use of it. I meant to imply that there are various reasons manufacturers do not choose to use reference implementations directly in their products. I'm sure it could be useful (in some capacity) to many.

I also meant to point out the difference between the code on the camera vs that used to interface to it from the VMS. As they have different dynamics regarding demand and uptake from their respective potential audience.

Well this recently released Client test tool must implement the C,G,S Profiles in order to test them. Maybe they can release the source code as well, if it's not already available...

As an ONVIF member, I believe IPVM is allowed access to the client test tool, located in the developer forum, which is closed to the general public.

It sounds like you could run two instances against each other: one instance testing for S connecting to one testing for G. If so, and the source is available, (would ONVIF not be open source?), then wouldn't this meet your requirement?

@Undisclosed B, any comment?

"would ONVIF not be open source?"

ONVIF is not open source. ONVIF provides specifications only, not code. Each member is responsible for developing / acquiring code themselves.

ONVIF is not open source. ONVIF provides specifications only, not code. Each member is responsible for developing / acquiring code themselves.

Are you saying that the just released Client Test Tool is just a specification? It's a specification to create a Tool? I am not a member so I can't see, but it sounds like a program to me.

April 7, 2015. ONVIF, the leading global standardization initiative for IP-based physical security products, announced today the release of its first Client Test Tool, which tests clients for conformance to ONVIF’s Profile S, G, and C specifications.

Or are you saying it's only provided in executable form?

The official ONVIF test tools are not open source. They're available in executable form to members.

"Or are you saying it's only provided in executable form?"

What industry do you think you are in? ;)

What industry do you think you are in?

The wrong one, apparently. ;)

ONVIF is a member consortium, they have apparently written source code implementing at some level, the Profile specifications. How useful is it, I don't know. I asked for comment from B.

Why do you act as though I am being ridiculous in thinking the source code might be available from an Open standards organization?

"Why do you act as though I am being ridiculous in thinking the source code might be available from an Open standards organization?"

Ridiculous is not really the world I would use.

Listen, this is an industry, where the open platform VMS champion sold to a Japanese conglomerate and less than a year later the open camera champion sold to the same Japanese conglomerate.

With that context, none of this should be a surprise.

Ok. I'm over my surprise. You said

The benefit to ONVIF would be that it would cut down mistakes / 'interpretation issues' / variances in implementation.

If it's a benefit to ONVIF and its members, why wouldn't they consider releasing it?

As opposed to for-profit technology companies, what would be to gain by not releasing source code to a tool? Competition from other standards bodies?

Someone needs to step up and give it away for free.

Stay tuned, one manufacturer is planning to do so shortly.

That one manufacturer wouldn't be Vicon by any chance?

“We are taking the ONVIF drivers for our cameras and putting it in to open source so it is freely available to anybody,” says Fullerton. The goal is to give developers access to the ONVIF application. “This will allow others to implement solutions without restriction. We will not be holding on to it like it is the crown jewels. We hope to spark a new wave of innovation for people building new applications on ONVIF. You can even go so far as to take this driver and place it on third-party hardware that we have not even developed.”

Yes, but they haven't actually put together the specifics of how they are doing it.

ISpyConnect is open source and has ONVIF support from the VMS side.

Is ISpy real ONVIF? They are not listed on the Conformance, neither on their product or business name (DeveloperInABox).

Btw, we tested iSpyConnect a while back.

Maybe they're not, I actually didn't check the ONVIF site. Good point.

Open software for closed cameras?

I had come across some of their code and these ONVIF tagged precompiled .dlls.

Amusingly, they boast that their software "works with more cameras than any other software on the market."

As an ONVIF member, IPVM can try Client Test Tool and (surprise!) see that it is in no way ONVIF client :)

What is it like?

How can you tell if it is using the API or not?

Presumably, it's much like the camera test tool.

Ok. Let's consider that tool for a moment since you have used it.

Theoretically one could write a tool to interact with an ONVIF camera using only the specification data, and ignoring the API. But, IMHO, unless the tool was trivially simple, you would code to the API.

If the camera tool looks like a client to the camera, then it must be coded, to some degree as a client. It would be parsing responses and maintaining state information, even if never displaying or storing a frame. So it would be an 'implementation', whether it's worthy of being a reference implementation, I have no idea.

I was just throwing the idea out there in response to the OP, after reading about another possible 'implementation', the client test tool

please keep in mind that normal client is focusing on general straight-forward cases, something that it need for regular operations. Test tool is focusing on corner-cases, on how devices operating on the edge between one and another parts of specification. So they are just playing different games, and should not share top-level api. As for low-level api - most development environments are generating is from specs automatically.

moreover, different vendors need different api to tightly bind their internal device model with onvif device model.

As for low-level api - most development environments are generating is from specs automatically. moreover, different vendors need different api to tightly bind their internal device model with onvif device model.

Good points.

please try it!

and while it is not possible, please consider that onvif device test tool play as a client, and tested device as a server. Client is able to master the situation.

what about client test tool? It can't be a client (obviously). And it can't be a server either, as server can't drive its client.

so please try it and let us know the answer for this puzzle.

The ONVIF Client Test Tool in it's first version is a network trace parser. When running the tool the operator is required to provide network traces of all exchanges between his client and a minimum of 3 different devices.

The operator must also provide the device Feature List XML file (as found on the ONVIF webpage) so the tool can know if the client tested all supported features or not.

The tool will then parse the network traces and analyze the different "conversations" according to the Client Test Specification (http://www.onvif.org/Documents/Specifications.aspx)

Based on the results, the operator will then be able to generate a DoC with corresponding Feature List XML file for his client.

Updated: not official but here's an open source'd implementation - ONVIF Camera Code Open Source'd (Vicon)