Overview

Quick Overview of The Ocularis SDK Architecture

This document is intended to provide a quick introduction to how integration with Ocularis can be accomplished.

Overview

A typical Microsoft Windows application will have the following architecture:

sdk_diagram

The host application will instantiate one or more Auga objects and (usually) just one OCAdapter. The host application will have to do a small bit of plumbing to tie the Auga object to the OCAdapter, it’s a trivial task that only requires a few lines of code.

The life-cycle of the application is typically something similar to this:

Caveats

Auga has 2 modes : hardware accelerated and basic GDI.

In hardware accelerated mode, only a small number of Auga instances can be made (depends on the GPU, OS and drivers, typically the limit is 16 instances, but sometimes less). However, a single Auga instance in HW accelerated mode can display many cameras within that instance. The layout can be set up via the LoadLayoutFromString method, which is what the Ocularis Client uses.

In Basic GDI mode, a much larger number of auga instances can be made, each instance consuming less memory and using the window GDI system to draw video.

So depending on your host applications design you can pick one or the other. If you expect the user to launch a large number of independent Auga instances, you should use GDI mode. If you create a relatively small number of Auga instances, you should use HW accelerated mode.

Behind the scenes

A host application should generally not be concerned with the behind-the-scenes plumbing, but a general understanding of how things work may help avoid pitfalls and help improve the system design.

When an application tells the OCAdapter to log in, the OCAdapter will connect to the Ocularis Base and retrieve a system description. From the system description a number of proxy object will be created; recorders, cameras, microphones and so on.

Only when the host application needs to get actual data from a camera for example, will the OCAdapter initiate a connection with the “real” camera. This design is necessary because in a large scale system, a user might log in, only to see video from a few cameras at a specific location. In a system with hundreds of locations, there is no reason to log into the remaining locations if the user never actually wants to look at video from them. All of this happens from within Auga and OCAdapter, and requires no additional coding on the host application side.

When a “real” connection is needed, the OCAdapter will first determine if the proxy object has created a peer object (this corresponds to the real camera), if not it will attempt to create one. To do that, it will determine a connection to the relevant recorder has been made. If the connection is good, the relevant peer camera will be found and stored with the proxy object, and from then on, all commands are sent to the real peer object.

This means that that client application creates a direct connection to each NVR in the system, independent of the Ocularis Base. In fact, if the base machine was to crash, the clients that have already logged in, would continue to function uninterrupted (with some functions being unavailable).

Security

Communication between the OCAdapter and Ocularis Base happens via a secured WCF service. The Ocularis Base stores settings in a SQL server, and provides access to the data via the WCF interface. There is no direct connection from any other Ocularis apps to the DB. The Ocularis Base is the sole connection to the DB.

Since Ocularis supports different recorders with different capabilities, the AV data is transmitted via whatever channel the recorder supports. The latest generation recorders use AES over a multiplexed TCP channel, and thus provide a high level of security even in open networks, but generally, the video surveillance systems should run on a dedicated network, ideally protected by a VPN tunnel.

Advanced options

The Ocularis Base WCF interface can be used either directly, or by crafting ASP.NET pages that are placed on the IIS instance that hosts the WCF service. The WCF interface is not officially documented, but is considered stable and will remain forward and backward compatible for years ahead.