Web applications offer a huge advantage over rich client applications in that they are much more simple in deployment. There are no strict requirements for client workstations, like a specific version of Windows or .NET, OpenGL extensions, and so on, to run a web client. The same is true for upgrades: when the server is upgraded, the clients will receive the new frontend automatically. Additionally, with web application you automatically get an ability to use the application over the Internet, in most cases not bothering about routing, port forwarding and other fragile environment-dependent things which should be explicitly watched for in case of rich client.
There are also “semi-web” approaches involving RTMP, RTSP, or other protocols for media interchange, - and rely on Flash/ActiveX plugins in the browser. These approaches are – to be honest - problematic for use at certain set of corner cases (restrictive firewalls, browser compatibility, reliability on poor network), require additional management when a server is deployed (port forwarding, URL translation), and, if a rich client application requires a video data, - the protocols involved have to be implemented also by that application, in addition to HTTP.
Viinex 2.0 was developed with the following criterion in mind: all the features implemented by Viinex should be reachable by a web client application written in JS for a modern browser, without additional software. We premise that if a web client can use the feature, then a rich client can use it, too. This criterion is met: data acquisition, statistics, commands, events, as well as video streams are available from Viinex 2.0 via HTTP API based on JSON interchange between client and server and stateless REST-like semantics of remote calls. A web client as well as mobile application for Viinex 2.0 can be developed in a “native” way, without involving any tricks and workarounds like third-party plugins, Flash, ActiveX, etc. Viinex 2.0 does not require its clients to use any other transport protocol except HTTP.
Diverse equipment for IP video surveillance
Viinex 2.0 allows the use of virtually any IP video cameras or encoders with your software. This is provided by implementation of ONVIF and RTSP standards in Viinex, and by the fact that it is currently almost impossible to find an IP video camera which ignores that standards. Moreover, Viinex company cares about its product’s interoperability with diverse equipment, and provides support for new or previously untested camera models if this is required in your project.
Multiple video archives
Video recording is stored by Viinex 2.0 in containers of standardized by ISO 14469-12, also known as MP4 format, which can be viewed by means of traditional widely available tools like Windows Media Player, QuickTime, etc. Directory structure where video data is written is transparent (bound to timestamp when video was acquired), so it is possible for a user to inspect stored video data and even manipulate it (make excerpts from, or merge fragments) if required - by simply copying files and folders.
Like most video management systems, Viinex 2.0 automatically maintains the restrictions set for video storage, which can determine maximum video archive size in terms of disk space or maximum video archive depth in terms of time. Given the restrictions set, older video records are overwritten by newer ones. For flexibility, there can be multiple video archives hosted by a single Viinex instance. Each video archive can store recordings from its own set of video sources, and has its own settings and respectively its own depth.
On-board camera detectors support
ONVIF specification unifies the way in which user applications acquire events from IP video surveillance equipment, in particular events from on-board detectors like motion detector. There is a several reasons for using such events instead of implementing detectors in the software running on the PC, of which the most important is performance. Motion detector does not require much resources on its own, however when it comes to processing the video acquired from IP video camera, one have to decode H.264 video stream, - but this cannot be done partially (unless it’s SVC profile), so it the stream is 4MPixels 25 FPS, the entire uncompressed stream should be reproduced on the CPU – just to perform motion detection. Such approach would significantly reduce the number of video channels which can be managed by a single computer.
Viinex 2.0 is capable of getting the events from on-board camera detectors. It implements the rules for processing such events to manage the recording control (turn the video recording on and off). The rules implemented in Viinex 2.0 are flexible enough to combine the events from several detectors, to manage the video recording on a group of cameras.
Viinex 2.0 pays attention to security. It has a well-documented “perimeter” – a single open HTTP port per each instance. There are no additional open ports or binary protocols. All API calls to Viinex are subject to authentication. Viinex 2.0 does not itself implement TLS, but can be wrapped by a reverse proxy implementing TLS on the frontend of a whole application.