Field of the Invention
The present invention is directed to a fail-safe architecture for recording video in a
multi-camera Video Management system, an advanced technique for estimating
server capability for load balancing, automatic uniform distribution of video recording
load across all the active servers, auto-registration of recording servers when they
are active in the network, use of multiple distributed NAS/SAN storage devices ,
automatic back up of recorded video in the server local storage space in case of
failure of the central storage, automatic upload of the video files to the central
storage once the storage system is recovered from failure, video streaming to the
clients without passing the video through any central hardware and thus avoiding
single point of failure, automatic camera add and release operation on new server
addition in the system and in case of server failure, without any manual intervention.
The recording system according to the invention can thus be constituted involving
multiple servers and is highly scalable with respect to increase or decrease in the
number of cameras, tolerant to intermittent or permanent failure of one or more
servers or one or more storage devices.
Background of the Invention
Video Management Systems are used for video data acquisition and search processes
using single or multiple servers. They are often loosely coupled with one or more
separate systems for performing operations on the acquired video data such as
analyzing the video content, etc. Servers can record different types of data in storage
media, and the storage media can be directly attached to the servers or accessed
over IP network. This demands a significant amount of network bandwidth to receive
data from the sensors (e.g., Cameras) and to concurrently transfer or upload the data
in the storage media. Due to high demand in bandwidth to perform such tasks,
especially for video data, often separate high speed network are dedicated to transfer
data to storage media. Dedicated high speed network is costly and often require
costly storage devices as well. Often this is overkill for low or moderately priced
installations.
It is also known that to back up against server failures, one or more dedicated fail-
over (sometimes called mirror) servers are often deployed in prior art. Dedicated fail-
over servers remain unused during normal operations and hence resulting in wastage
of such costly resources. Also, a central server process either installed in the failover
server or in a central server is required to initiate the back-up service, in case a
server stops operating. This strategy does not avoid a single point of failure.

Moreover, when the servers and clients reside over different ends in an internet and
the connectivity suffers from low or widely varying bandwidth, transmission of multi-
channel data from one point to another becomes a challenge. Data aggregation
techniques are often applied in such cases which are computationally intensive or
suffer from inter-channel interference, particularly for video, audio or other types of
multimedia data.
As regards analytic servers presently in use it is well known that there are many
video analytics system in the prior art. Video content analysis is often done per frame
basis which is mostly pre defined which make such systems lacking in desired
efficiency of analytics but are also unnecessarily cost extensive with unwanted loss of
valuable computing resources.
Added to the above, in case of presently available techniques of video analysis ,cases
of unacceptable number of false alarms are reported when the content analysis
systems are deployed in a noisy environment for generating alerts in real time. This
is because the traditional methods are not automatically adaptive to demography
specific environmental conditions, varying illumination levels, varying behavioural
and movement patterns of the moving objects in a scene, changes of appearance of
colour in varying lighting conditions, changes of appearance of colours in global or
regional illumination intensity and type of illumination, and similar other factors.
It has therefore been a challenge to identify the appearance of a non-moving foreign
object (static object) in a scene in presence of other moving objects, where the
moving objects occasionally occlude the static object. Detection accuracy suffers in
various degrees under different demographic conditions.
Extraction of particular types of objects (e.g. face of a person, but not limited to) in
images based on fiduciary points is a known technique. However, computational
requirement is often too high for traditional classifier used for this purpose in the
prior art, e.g., Haar classifier.
Also, in a distributed system where multiple sites with independent administrative
controls are present, unification of those systems through a central monitoring
station may be required at any later point of time. This necessitates hardware and OS
independence in addition to the backward compatibility of the underlying
computational infrastructure components, and the software architecture should
accommodate such amalgamation as well.

It would be thus clearly apparent from the above state of the art that there is need
for advancement in the art of sensory input/data such as video acquisition cum
recording and /or analytics of such sensory inputs/data such as video feed adapted to
facilitate fail-safe integration and /or optimized utilization of various sensory inputs
for various utility applications including event/alert generation, recording and related
aspects.
Video Management System using IP enabled video capturing devices(Cameras etc)
has become an integral part of Surveillance industry today. A basic requirement of
this type of systems is to input compressed video streams from multiple cameras and
record the video in storage devices. In the earlier days when DVR and then NVR were
predominant components, the complexity and hence the challenges for efficient
deployment of the system were less. This is because each DVR or NVR was a
standalone system taking feed from a handful of cameras (typically 16 or 32), and
used their dedicated local storage devices to record the video. However, when the
number of cameras started to increase beyond 100, and typically to a few hundreds,
and the users demanded a unified system to record, view and search video from
these hundreds of cameras efficiently, Video Management System emerged as a
solution.
In a typical Video Management System there are multiple servers, each catering a set
of Video Capture devices (e.g., Cameras), one or more network accessible RAID
configured storage devices, and multiple workstations. Each server now needs to
handle 64 or more cameras, stream the video from the cameras to the client
machines. Traditionally, the servers are grouped into one or more clusters and one
or more redundant servers are kept as standby per cluster so that they can back up
the functionalities of the failed server(s). This has the disadvantage of non-optimal
use of the server resources, both under normal scenario as well as when one or more
servers fail. To back up against server failures, one or more dedicated fail-over
(sometimes called mirror) servers are often deployed in prior art. Dedicated fail-over
servers remain unused during normal operations and hence resulting in wastage of
such costly resources. Also, a central server process either installed in the failover
server or in a central server is required to initiate the back-up service, in case a
server stops operating. This strategy does not avoid a single point of failure.
Objects of the Invention
It is thus the basic object of the present invention to provide for an advancement
where the failsafe server group would be adapted without a central server and

support from any dedicated failover or mirror server. Instead of allocating a particular
data source (e.g., a camera and other sensors) to a particular server for recording of
data (e.g, video or other data types), it could be allocated to a 'Server group' with
multiple servers in the group.
Another object of the present invention is directed to a failsafe server group where
the members of the group would be adapted to continuously and mutually exchange
their capacity information amongst themselves and automatically share the load
according to their capacity such that in case of breakdown of one or more servers,
the team members automatically detect it and share the load of the failed server(s),
without any central control or without support from any fail-over or mirror server.
Yet further object of the present invention is directed to provide for fail safe server
groups which would be adapted to eliminate the need for costly failover or mirror
server and the load would be always evenly distributed as per the capacity of the
individual server hardware.
Another object of the present invention is directed to advancements in fail safe server
groups adapted for interconnecting a number of intelligent components consisting of
hardware and software, and involving implementation techniques adapted to make
the system efficient, scalable, cost effective, fail-safe, adaptive to various
demographic conditions, adaptive to various computing and communication
infrastructural facilities.
Summary of the Invention
Thus according to the basic aspect of the present invention there is provided a
method for sensory input recording and live streaming in a multi-server environment
comprising: a fail-safe server group each said server group comprising plurality of
acquisition cum recording servers said multiple recording servers adapted to
exchange information amongst one another and left over capacity of each server is
known along with the channel information of every other server such that in case of
any server failure in said server group the remaining active servers in the server
group automatically distribute the required operative load amongst the remaining
operative servers for a fail-safe recording and streaming of the sensory data, without
any external control.

In the above method wherein each recording server auto registers in the system and
a database entry is created with the server ID whereby the said recording server gets
listed in the database and is then ready for recording data from one or more sources.
In the above method wherein the recording is done by breaking the data streams into
chunks or clips of small duration and the clips are initially stored in a local server
storage space and periodically uploaded to one or more network attached storage in
a round robin fashion.
In the above method comprising plurality of server groups which are operatively
connected to network storage and as soon as a server is registered in a Group it
generates a message describing its IP address ,group ID and remaining capacity to
handle more data source/cameras.
In the above method wherein the capacity of the respective servers in a server group
is based on the memory, bandwidth and current processor utilization within the
server.
In the above method comprising assigning the server operatively connected to the
input sensory devices and the capacity of the server determined accordingly with
continuous monitoring of required decrement or increment of capacity based on
addition or removal of sensory input sources.
In the above method wherein a server group is adapted to allocate any one of the
operative servers in said group as the group master server and continuously
monitor the servers in the group and their respective capacities and decide on the
allocation and release of the input sensory source from any server within the Group.
In the above method wherein the said group master server is adapted to release or
add a sensory input source to any other server within the Group based on required
(a) addition of an input source (b) deletion of an existing input source (c ) addition of
anew recording server to the system or when a failed server again re-operates and
(d) when a running server stops functioning.
The framework disclosed herein can be used for such situations, and also for
integrating multiple heterogeneous systems in a distributed environment. The
proposed architecture is versatile enough to interface and scale it to many other
management systems.

The details of the invention and its objects and advantages are explained hereunder
in greater detail in relation to the following non-limiting exemplary illustrations as per
the following accompanying figures:
Brief Description of the Drawings
Fig 1: is a schematic layout of an illustrative embodiment showing an integrated
intelligent server based system of the invention having sensory input/data
acquisition cum recording server group and /or analytics server group adapted to
facilitate fail-safe integration and /or optimized utilization of various sensory inputs
for various utility applications;
Fig 2 : is an illustrative top level view of intelligent video management system with
framework for multiple autonomous system integration;
Fig 3: is an illustration of fail-safe bandwidth optimized recording without any
supporting failover support server in accordance with the present invention;
Fig 4.:is an illustration of the dataflow diagram from a single video source through
the recording server ;
Fig. 4A to 4J: illustrate an exemplary Intelligent Home Security" box involving the
system of the invention;
Fig.5 : is an illustration of the single channel data flow in video analytical engine in
accordance with the present invention;
Fig. 6: is an illustration of intelligent video analytics server in accordance with the
present invention;
Fig.7 : is an illustration of video management interface functionalities in accordance
with the present invention;
Fig 8. Is an illustration exemplifying the manner of adding a camera (ALLOCATE) to a
GROUP of recording servers in accordance with the present invention;
Fig.9: is an illustration of load balancing when an existing camera is deleted from a
GROUP in accordance with the present invention;

Fig.10: is an illustration of the load balancing when a new recording server is added
in accordance with the present invention;
Fig, 11: is an illustration of the method of ALLOCATION when a running server stops
operation;
Detailed Description of the Invention:
Reference is first invited to accompanying figure 1 which shows the broad overview
of an illustrative embodiment showing an integrated intelligent server based system
having sensory input/data acquisition cum recording server group and /or analytics
server group adapted to facilitate fail-safe integration and /or optimized utilization
of various sensory inputs for various utility applications. More specifically, the system
involves the fail safe server group in accordance with the present invention.The
following description in relation to figures 1 to 7 deals with the utilities of the
advancement involving the fail safe server group in an integrated intelligent server
based system and further in relation to figure 8 to 11 further illustrates the manner
of implementing the stated fail safe server group in accordance with the present
invention.
As would be apparent from the figure 1 ,the system basically involves the self-reliant
group of recording servers (101), the group of analytical servers (102) and an
intelligent interface (103).Importantly, said recording servers apart from being
mutually cooperative and self-reliant to continuously monitor and distribute the
operative load based on the number of active servers in the group are also adapted
for bandwidth optimized fail-safe recording ((104 ) and join-split mechanism for multi
channel video streaming ( 105).
The analytical servers (102) are also adapted to cater to atleast one of more of
background estimation (106), identifying moving, static, quasi static objects ( 107),
enhanced object tracking (108), content aware resource scheduling ( 109) , join-split
mechanism for sensory date streaming (110) and resource dependent accuracy
control (111).

The various components of the above system adapted to carry out the above
advanced functionalities in accordance with the present invention is further outlined
and schematically described in Fig 2:
1. Intelligent Video Management System (204)
1.1. Video Recording Server (201)
1.2. Video Management Interface (203)

1.2.1. User management and Client access controller
1.2.2. Event concentrator and Handler (206)
1.2.3. Event distributor

2. Intelligent Video Analytics Server (202)
3. Surveillance Client (207)
4. Web client (207)

5. Mobile device Client (207)
6. Remote Event Receiver ( 206 )
As is clearly apparent from Figure 2, the present system would enable seamless and
intelligent Interconnection of multiple Autonomous Systems (210-01 ;210-02... 210-
On). Thus at the same time, multiple such Autonomous Systems can be used as
building blocks for a distributed system spanning across wide geographical regions
under different local administrative control, with a Centralized view of the whole
system from a single point. An Autonomous system (210-01)) is considered as a
system capable to implement the functionalities and services involving sensory data
and /or its analysis.
Also, the system is capable of handling any sensory data/input and it is only by way
of an illustration but not by way of any limitations of the present system that the
various exemplary illustrations hereunder are discussed with reference to video
sensory data. The underlying system architecture/methodology is applicable in other
sensory data types for a true Intelligent Sensor Management System .
A number of machine vision products spanning the domain of Security and
surveillance, Law enforcement, Data acquisition and Analysis, Transmission of
multimedia contents, etc can be adapted to one or more or the whole of the system
components of the present invention.
Reference is now invited to accompanying figure 3 which shows by way of an
embodiment a fail-safe bandwidth optimized recording without any failover support
server. As apparent from said figure, for the purpose the input from the pool of

sensors (305) are fed not to any single server but to a group of servers
(301).Importantly , communication channel (303) is provided to carry inter-VRS
communication forming a team towards failover support without any central
management and failover server while the communications channel (302) is provided
to carry data to central storage involving intelligent bandwidth sharing technique of
the invention.
The implementation of the Recording System :
The Recording system essentially implements the functionalities and services as
hereunder:
1. Collecting Data real time: Collect data from various images, video and
other sensory sources, both on-line and off-line, archiving and indexing
them to seamlessly map in any relational or networked database in a fail-
safe way making optimal usage of computing, communication and storage
resources, facilitate efficient search, transcoding, retransmission,
authentication of data, rendering and viewing of archived data at any point
of time.
2. Streaming data real time or on Demand: Streaming video and other
sensory content in multiple formats to multiple devices for purposes like
live view in different matrix layout, relay of the content, local archiving,
rendering of the sensory data in multiple forms and formats, etc. by a fail-
safe mechanism without affecting speed and performance of on-going
operations and services.
The Video Recording system is implemented using hardware and software, where the
hardware can be any standard computing platform operated under control of various
operating systems like Windows, Linux, MacOS, Unix, etc. Dependence on hardware
computing platform and operating system has been avoided and no dedicated
hardware and communication protocol has been used to implement the system.
Recording server implements an open interface both for input and output, (including
standard initiatives by various industry consortium such as ONVIF, PSIA, etc.), and
can input video feed from multiple and different types of video sources in parallel,
with varying formats including MPEG4, H.264, MJPEG, etc. OEM specific SDKs to

receive video can also be used. Internal operating principle of the Recording server is
outline below:
Recording Server operating principle is adapted for the following:
1. Auto register itself to the IVMS system so that other components like VMS,
Surveillance Clients, other VRSes can automatically find and connect it even
when its IP-address changes automatically or manually.
2. Form a group with other VRS in the system to implement a failover support
without any central control and without support from any dedicated failover
server.
3. Accept request from VMI to add and delete data sources including video
sources like cameras, receive data from those input sources over IP-network
or USB or other connectivity, wired or wireless, using open protocols or SDKs
as applicable for a particular data source.
4. Record the video and other sensory data in local storage either continuously or
on trigger from external devices including the data source itself or on trigger
from other components of the Video management system or on user request
or on combination of some of the above cases
5. Intelligently upload the video or other sensory data in a cluster of storage
devices, where a cluster contains of one or more network accessible storages,
in an efficient way giving fair share to individual data sources, utilizing
optimal bandwidth and in a cooperative way.
6. Insert information in database so that the data including video data can be
searched easily by any component in the system.
7. Stream the video or other sensory data in their original format or in some
other transcoded format to other devices including the Surveillance clients
when the surveillance client connects it using defined protocol.
Auto registration of servers:
All the servers in the system, including the Recording servers, auto register
themselves by requesting and then getting a unique Identification number (ID) from
the VMI. All the configuration data related to the server including the identification of

data sources including the video sources it caters to, the storage devices it uses, etc
are stored in the database against this ID. This scheme has the advantage that with
only one Static IP address (that of the VMI), one can access any component of the
Autonomous System (AS), and the IP addresses of the individual hardware
components may be kept varying.
Recording Video or other sensory data in local storage and streaming the data to
Client machine:
The cameras, other video sources or sources generating streaming data (henceforth
called Channels) can be auto detected or manually added to the VRS. The details of
the channels are stored in the Central Database. Once done, one or more channels
can be added to the Recording System. The Recording system thus comprises of one
or more Recording servers (VRS) and the Central Database Management System.
VRS-es consults the database, know about details of the system, and records the
channel streaming data either continuously, or on trigger from any external or
internal services, as configured by the user.
The data stream is first segmented into small granular clips or segments of
programmable and variable length sizes (usually of 2 to 10 minutes duration) and the
clips are stored in the Local storage of the server, the clip metadata being stored in
local database.
Reference is invited to accompanying figure 4 which shows the dataflow mechanism
in accordance with the invention from a single video service through the recording
server. As apparent from Figure 4, the sensory data stream viz. video (405) is feed
to a data segment generator (401) which is next stored in segments in local storage
(403/402) and thereafter uploaded through data upload module (404) to a central
storage (406)/407),
Any external component of the system can enquire the VRS to know about the details
of the channels it is using and get the data streams for purposes like live view,
Relaying to other devices etc using a networked mutual client-server communication
protocol
Bandwidth adaptive data uploading to central storage system
In the system of the invention, an efficient technique has been designed to transfer
video or other sensory data received from the channels to the central storage system
via the local storage. Instead of allocating a particular data source (e.g., a camera) to
a particular server (dedicated point to point) for recording of data (e.g, video), it is

allocated to a 'Server group' with multiple servers in the group [Fig 3]. The members
of the group exchange their capacity information amongst themselves and share the
load according to their capacity. In case of breakdown of one or more servers, the
team members share the load of the failed server(s), without any central control or
without support from any dedicated fail-over server. For data uploading, each server
not only monitors the available bandwidth but also the data inflow rate for each
channel into the server, and accordingly adjusts the upload rate for an individual
channel. For the purpose the data stream is segmented into variable sized clips and
the rate of uploading the clips to the central storage is adjusted depending on the
available network bandwidth and data inflow rate for that particular channel [Fig
4].As shown in the figure , the sensor data stream ( 405) is segmented in data
segment generator (401) which is next stored in local storage ( (402 ,403) and
thereafter involving a data upload module (404) the same is sent to the central
storages ( 406/407).
Implementing fail-over support without any dedicated failover server and mirror
central control
The system of the invention is further adapted for back up support in case of server
failure without the involvement of any special independent stand by support server.
Traditionally (prior art), dedicated fail-over servers are used which senses the
heartbeat signals broadcasted by the regular servers. Once the heart beat is found
missing, the failover server takes up the task of the failed server. This technique is
inefficient as it not only blocks the resources as dedicated failover servers, but cannot
utilize the remaining capacity of the existing servers for back up support. Also, failure
of the failover server itself jeopardizes the overall failover support system.
In the proposed system the recording servers exchange information amongst
themselves so that each server knows the leftover capacity and the channel
information of every other server. In case of server failure, the remaining active
servers distributes the load amongst themselves.
The Implementation of the Video Analytics System
The Video Analytics System essentially implements the functionalities as hereunder:
1. Data Content Analysis: Intelligently analysing the data, on-line or off-line, to
extract the meaningful content of the data, identifying the activities of
foreground human and other inanimate objects in the scene from the sensor

generated data, establishing correlation among various objects (living or
non-living) in the scene, establishing correlation amongst multiple types of
sensory data, identifying events of interests based on the detected activities-
-- all either automatically or in an user interactive way under various
demographic and natural real life situations. Several novelties have described
in the relevant sections describing the details of the data content analysis
techniques.
2. Automatic Alert Generation: Generating Alerts, signals, video clips, other
sensory data segments, covering the events automatically as and when
detected.
The Video Analytics system comprises hardware and software, where the hardware
can be any standard computing platform operated under control of various operating
systems like Microsoft Windows, Linux, MacOS, Unix, RTOS for embedded hardware,
etc.
Dependence on hardware computing platforms and operating systems has been
avoided and no dedicated closed hardware needs to be used to implement the
system. At the same time, part or whole of the system can be embedded into other
products with some existing services, without affecting those services.
An example is provided in the form of "Intelligent Home Security" box shown in
Figures 4A to 4J where a specially built hardware is used to provide several services
viz, Digital Photo-frame, Perimeter security, Mobile camera FOV recording & relay,
Live view of cameras, etc.
Referring to FIG. 4A, a schematic diagram of a Networked Intelligent
Villa/Home/Property Monitoring System is shown. All of the intelligent video
management server and intelligent monitoring applications that are described in
previous sections have been embedded into the Videonetics Box. The Box has an
easy to use GUI using touch-screen so that any home/villa/property owner can easily
operate it with minimum button pressing using visual display based instructions only.
The top level systems architecture for the embedded hardware and details of the
components in the hardware system is shown in FIG. 4B.
The following is a micro-architectural components summary for an example of a
multi-channel IP-camera solution. Video from IP-Cameras is directly fed to the
computer without the requirement of any encoder. There are three options: One, no

network switch is required. The Motherboard should have multiple Ethernet ports;
two, the Motherboard has only one Ethernet port assuming all the cameras are
wireless IP-Cameras. The Motherboard should have 1 x Ethernet port and 1 x Wifi
interface; and three, the Motherboard has only one Ethernet port, the cameras are
wired, but a Network switch is required as an external hardware.
On detection of events the following tasks are performed:
a siren blows;
an SMS/MMS is sent;
event clip is archived; and
the event clip is also streamed to any designated device over the Internet.
The following Interfaces are required to handle the above tasks: at least one RELAY
O/P for siren drive or DIO for Transmitter interface; and a 3G interface for SMS/MMS
or sending event clip to Cell Phone. Other usual hardware includes:
a. USB;
b. Touch Screen Interface;
c. external storage;
d. 3G dongle, if 3G is not embedded into motherboard;
e. keyboard, if touch screen is not attached; and
f. DVI port for display.
The following is a micro-architectural components summary for an example of a
multi-channel analog camera solution. Video from analog camera is received by an
encoder hardware. The encoded RAW image is fed to the computer for processing.
System Hardware should be capable to handle the following activities:
1. multi channel encoding, each at 15 - 30 fps for Dl size, but not limited to, higher
frame rate and higher resolution as long as computing bandwidth supports this frame
rate and resolution video data
a. Input to encoder: Analog video in NTSC or PAL
b. Output from encoder: YUV or RGB
There are two options:

a. The encoder could be a separate module connected to motherboard
through PCIE
b. The encoder circuitry may be embedded in the mother board
2. On detection of events following tasks are performed:
a. A siren blows
b. An SMS/MMS is sent
c. Event clip is archived
d. Event clip is also streamed to any designated device over Internet
The following hardware Interfaces are required to handle the above tasks:
a. At least one RELAY O/P for siren drive or External Transmitter interface
(DIO)
b. 3G interface for SMS/MMS or sending event clip to Cell Phone.
c. Ethernet for remote access to the system
3. Other usual hardware:
1. USB :
a. Touch Screen Interface
b. External Storage
c. 3G dongle, if 3G is not embedded into motherboard
d. keyboard if touch screen is not attached
e. DVI port: for Display
Referring to FIG. 4C, a top level heterogeneous system architecture (both IP and
analog cameras) is illustrated. Referring additionally to FIGS. 4D-4J an operational
flow by a user and representative GUI using a touch panel display of the intelligent
monitoring system is detailed in a step-by-step flow.
Thus, a new and improved intelligent video surveillance system is illustrated and
described. The improved intelligent video surveillance system is highly adaptable
and can be used in a large variety of applications can be conveniently adapted to a
variety of customer-specific requirements. Also, the intelligent video surveillance
system is automated, intelligent, and requires a minimum or no human intervention.
Various changes and modifications to the embodiment herein chosen for purposes of
illustration will readily occur to those skilled in the art. To the extent that such

modifications and variations do not depart from the spirit of the invention, they are
intended to be included within the scope thereof.
The Analytics Engine
Various rule sets for inferencing the dynamics of the data (interpretation of Events)
are defined inherently in the system or they can be defined by the users. An Analytics
engine detects various activities in the video or other sensory data stream and on
detection of said activities conforming to one or more Events, sends notification
messages with relevant details to the recipients. The recipients can be the VMI, the
central VMS or Surveillance Clients or any other registered devices. To perform the
above tasks, the scene is analyzed and the type of analysis depends on the type of
events to be detected.
The data flow within the Analytics Engine for a single channel, taking video stream as
the channel data, is as schematized below [Fig. 5],. The functionalities of various
internal modules of the Analytics Engine and other components are described below,
taking Video channel as an example for Sensory data source.
(A) Scene Analyzer (501) : The Scene analyzer is the primary module of the
Analytics engine and that of the IVAS as well. Depending on the Events to be
detected, various techniques have been developed to analyze the video and sensory
data content and extract the objects of interests in the scene or the multi-sensory
acquired data. Importantly, the scene analyzer is adapted to analyze the content of
the media(e.g, video) based on intelligent scene adaptive colour coherent object
analysis framework and method . Implementation of the same has been done so
that it is adaptive to the availability of computational bandwidth and memory and the
processing steps are dynamically reconfigured. As for example, as described further
in detail hereunder a trade-off is done automatically by the Analytics engine to strike
a balance between the accuracy of face capture and the CPU clock cycles available for
processing.
The Scene Analyzer generates meta-data against each frame supplied to it for
analyzing. It also computes the complexity of the scene using a novel technique and
dynamically reconfigure the processing steps in order to achieve optimal analysis
result depending upon the availability of the computational and other resources for
on-line and real-time detection of events and follow up actions. It feeds the metadata
along with the scene complexity measure to the Controller, so that the Controller can
decide the optimal rate at which the frames of that particular video channel should be

sent to the Analytics engine for processing. This technique is unique and saves
computational and memory bandwidth for decoding and analysis of the video frames
(B) Rule Engine (502): The Rule Engine keeps history of the metadata and correlates
the data across multiple frames to decide behavioural patterns of the objects in the
scene. Based on the rules, various applications can be defined. As for example it is
possible to detect whether a person in jumping a fence or whether there is a
formation of crowd or whether a vehicle is exceeding the speed limit, etc.
(C) Event Decider (503): The behavioural patterns, as detected by the Rule Engine is
analyzed by this module to detect various events in parallel. The Events can be
inherently defined or it may be configured by the user. As for example, if there is
crowd formation only in a specific zone whereas other areas are not crowded, that
may be defined to be an Event. Once an Event is detected, a message is generated
describing the type of event, time of occurrence of the Event, the location of
occurrence of the Event, the Video clip URL, etc.
The Event decider can also control any external device including a PTZ camera
controller which can focus a region where the event has taken place for better
viewing of the activities around that region or recording the scene in a close up view.
One such advanced framework is detailed hereunder as enhanced object tracking
where the utility of an Object tracking system is enhanced using a novel technique
using a PTZ camera along with the Object tracking system.
The Analytics Engine Controller
A Controller module (602) as shown in Figure 6 has been designed which can receive
multiple video channels, possibly in some compressed form (e.g, MJPEG, Motion
JPEG2000, MPEG, H.264, etc. for video and relevant format for other sensory data
such as MP4 for audio, for example but not limited to), and feeds the decoded video
frames to the Analytic engine. The Controller uses an advanced technique to decide
the rate of decoding of the frames and feed the decoded video frames of multiple
channels to the Analytics engine in an optimal way, so that the number of frames
sent per second for each video channel is individually and automatically controlled
depending on the requirement of the Analytics engine and also on the computational
bandwidth available in the system at any point of time. The technique has been
described in detail in relation to video content driven resource allocation for analytical
processing.

The Controller also streams the video along with all the Video Analytics data (existing
configuration for Events, Event Information, video clip URL etc), either as individual
streams for each channel, or as a joined single stream of video data for all or user
requested channels. A novel technique for joining the video channels and
transmitting the resulting combined single channel over IP network has been
deployed to adapt to varying and low bandwidth network connectivity. The technique
is described in detail in relation to video channel join-split mechanism for low
bandwidth communications.
The Controller can generate Events on its own for the cases where Events can be
generated without the help of Video Analytics engine (eg, Loss of Video, Camera
Tampering as triggered by Camera itself, Motion detection as intimated by the
Camera itself, as so on).
The implementation of Video Management Interface (VMI)
The Video Management Interface (702) is shown in figure 7 which interfaces between
an individual Autonomous System and rest of the world. It also acts as the
coordinator among various other components within a single Autonomous system,
viz, Video Recording System (703), Intelligent Video Analytical Server (704),
Surveillance Clients (701), Remote Event Receiver (705), etc. [It essentially
implements the functionalities including:
1. Filtering and need based transmission of data: Distribution of whole or part
of the collected sensory data, including the video and other sensory data
segments generated as a result of detection of an Event by the Analytical
engine, at the right recipient at the right point of time automatically or on
user interaction.
2. Directed distribution of Alerts: Distributing Event information in various
digital forms (SMS, MMS, emails, Audio alerts, animation video, Text,
illustrations, etc. but not limited to) with or without received data segments
(viz, video clips) to the right recipient at the right point of time
automatically or on user interaction.
3. Providing a common gateway for heterogeneous entities: Providing a unified
gateway for users to access the rest of the system for configuration,
management and monitoring of system components.

The Interface operating principle involved in the system is discussed hereunder:
1. Auto register itself to the IVMS system so that other components like
Surveillance Clients (including Web Clients and Mobile Clients), Remote Event
Receivers, can find and connect it even when its IP-address changes;
2. Accept request from Surveillance clients to add and delete data sources like
cameras to the VRSes and IVASes and relay the same to the corresponding
VRSes and IVASes.
3. Receive configuration data from the Surveillance clients and feed them to the
intended components (viz, VRS, IVAS, DBMS, Camera etc) of the system. For
VRS , the configuration data includes Recording parameters, Database paths,
Retention period of recording, etc. For IVAS, it is the Event and Application
settings, Event clip prologue-, after event- and lifetime-duration, etc.
4. Receives Event information from IVAS on-line and transmit it to various
recipients including Remote Event Receivers. Fetch outstanding Event clips, if
any, from IVAS. Outstanding clips may have been there inside IVAS, in case
there was a temporary network connectivity failure to IVAS.
5. Periodically receive heartbeat signals along with status information from all
the active devices, and relay that to other devices in the same or in other
networks.
6. Serve the Web clients and Mobile embedded clients by streaming Live video,
Recorded Video or Event Alerts at the right time.
7. Join multiple channel video into a single combined stream to adapt to variable
and low bandwidth network. A novel technique for joining the video channels
and transmitting the resulting combined single channel over IP network has
been deployed to adapt to varying and low bandwidth network connectivity.
The technique is described in relation to video channel join -split mechanism
for low bandwidth communication.
8. Enable the user to search for the recorded video and the Event clips based on
various criteria, including Data, Time, Event types, Video Channels.
9. Enable the user to perform an User-interactive Smart search to filter out
desired segment of video from video database
In essence, once the Interface (702) is installed, the VRS (703), IVAS (704) and
other components of the system can be configured, and the user can connect to the
System. However, at run time all the VRS and IVAS can operate on their own, and do
not require any service from the VMI, unless and otherwise some System
configuration data has been changed.

Independence for of the servers from any Central controller for their routine
operation gives unprecedented scalability with respect to increase in number of
servers. This is because, it does not add any extra load to any other component than
the server itself. This is a unique advancement where the Video Management Server
Interface acts only as a unified gateway to the services being executed in other
hardware devices, only for configuration and status updating tasks. This opens up the
possibility of keeping the User interface software unchanged while integrating new
type of devices. The devices themselves can supply their configuration pages when
the VMI connects to them for configuration. Similarly, the messages generated by the
servers can also be shown in the VMI panel seamlessly.
The Video Management Client(701), Web client(707), Mobile device embedded
client(708)
All the above client modules in essence implement the functionalities including:
Providing Live view or recorded view of the data stream: Enabling user to view
camera captured video in different matrix layouts, view other sensory data in a
presentable form, recorded video and other data search and replay, Event clips
search and replay, providing easy navigation across camera views with help of
sitemaps, PTZ control, and configuring the system as per intended use.
The VMS system can be accessed through the standalone surveillance client or any
standard Internet browser can be used to access the system. Handheld devices like
Android enabled cell phone or tablet PCs can also be used as a Client to the system
for the purposes (wholly or partially) as mentioned above.
The Remote Event receiver (705)
RER (705) shown in Figure 7 is the software module which can be integrated to any
other modules of the IVMS. The Remote Event Receiver is meant to receive and
display messages and ALERTs from other components, which are multicast or
broadcasted. Those messages include Event ALERTS, ERROR status from VRS or
IVAS, operator generated messages, etc. The Messages can be in the Video as well as
Audio form, or any other form as transmitted by the Video management system
components and the resulting response from by the RER depends on the capability
and configuration of the hardware where the RER is installed. When integrated with
the Surveillance clients (IVMC), the IVMC can switch to RER mode and thus will
respond to ALERTs and messages only.

The Central VMS system
Central VMS System (204 in Figure 2) is adapted to serve as a gateway to any
Autonomous System (210-01...210-0n) components. It also stores the configuration
data for all ASes in its Centralized database. It is possible to integrate otherwise
running independent VMS systems into a single unified system by including Central
VMS in a Server and configure that accordingly.
The Sitemap Server
A Sitemap server is included within each Autonomous System (210-01...210-0n) and
also within the Centralized VMS(204 in Figure 2). The Sitemap server listens to
requests from any authorized components of the System and responds with positional
data corresponding to any component (Camera, server, user etc.) which is linked to
the Site map. The Site map is multilayered and components can be linked to any
spatial position of the map in any layer.
The above describe the framework, architecture and system level components of the
Intelligent system of the invention. The technology involved in the development of
the system can be used to integrate various other types of components not shown or
discussed above. As for example, an Access Control System or a Fire Detection
System can be integrated similar to VRS or IVAS, configured using IVMC and VMI,
and their responses or messages can be received, shown or displayed and responded
to by IVMC or RER, stored as done for Event clips or Video segments and searched on
various criteria.
The system of the invention detailed above is further versatile enough to interface
and scale to many other management systems such as the involvement in intelligent
automated traffic enforcement system also discussed in later sections.
Reference is now invited to accompanying figures 8 to 11 which illustrate the fail-safe
mechanism for sensory data such as video recording and live view streaming in a
multi -server ,multi-camera system in accordance with the present invention.
In Figure 8 the manner of adding a camera (ALLOCATE) to a GROUP of recording
servers is shown by way of components/features 901 to 908.
In figure 9 the manner of load balancing when an existing camera is deleted from a
GROUP is shown by way of components/features 1001 to 1002.

In figure 10 the manner of load balancing when a new recording server is added is
illustrated by way of components/features 1101 to 1109.
In figure 11 the manner of ALLOCATE method when a running server stops operation
is shown by way of components/features 1201 to 1202.
What is disclosed is a fail-safe architecture for recording video in a multi-camera
Video Management system, a novel technique for estimating server capability for load
balancing, automatic uniform distribution of video recording load across all the active
servers, auto-registration of recording servers when they are active in the network,
use of multiple distributed NAS/SAIM storage devices , automatic back up of recorded
video in the server local storage space in case of failure of the central storage,
automatic upload of the video files to the central storage once the storage system is
recovered from failure, video streaming to the clients without passing the video
through any central hardware and thus avoiding single point of failure, automatic
camera add and release operation on new server addition in the system and in case
of server failure, without any manual intervention. The recording system thus
constituted using multiple servers is highly scalable with respect to increase or
decrease in the number of cameras, tolerant to intermittent or permanent failure of
one or more servers or one or more storage devices.
Video Management System using IP enabled video capturing devices (Cameras, etc)
has become an integral part of Surveillance industry today. A basic requirement of
this type of systems is to input compressed video streams from multiple cameras and
record the video in storage devices. In the earlier days when DVR and then NVR were
predominant components, the complexity and hence the challenges for efficient
deployment of the system were less. This is because each DVR or NVR was a
standalone system taking feed from a handful of cameras (typically 16 or 32), and
used their dedicated local storage devices to record the video. However, when the
number of cameras started to increase beyond 100, and typically to a few hundreds,
and the users demanded a unified system to record, view and search video from
these hundreds of cameras efficiently, Video Management System emerged as a
solution. In a typical Video Management System there are multiple servers, each
catering a set of Video Capture devices (e.g., Cameras), one or more network
accessible RAID configured storage devices, and multiple workstations. Each server
now needs to handle 64 or more cameras, stream the video from the cameras to the
client machines. Traditionally, the servers are grouped into one or more clusters and
one or more redundant servers are kept as standby per cluster so that they can back

up the functionalities of the failed server(s). This has the disadvantage of non-
optimal use of the server resources, both under normal scenario as well as when one
or more servers fail. To back up against server failures, one or more dedicated fail-
over (sometimes called mirror) servers are often deployed in prior art. Dedicated fail-
over servers remain unused during normal operations and hence resulting in wastage
of such costly resources. Also, a central server process either installed in the failover
server or in a central server is required to initiate the back-up service, in case a
server stops operating. This strategy does not avoid a single point of failure.
A present invention thus proposes a fail-safe mechanism without a central server
and support from any dedicated failover or mirror server. Instead of allocating a
particular data source (e.g., a camera and other sensors) to a particular server for
recording of data (e.g, video or other data types), it is allocated to a 'Server group'
with multiple servers in the group. The members of the group continuously and
mutually exchange their capacity information amongst themselves and automatically
share the load according to their capacity. In case of breakdown of one or more
servers, the team members automatically detect it and share the load of the failed
server(s), without any central control or without support from any fail-over or mirror
server. This eliminates the need for costly failover or mirror server and the load is
always evenly distributed as per the capacity of the individual server hardware. This
is a clear advancement in the related art. This can be implemented as an example of
cooperative social networking implemented in machine level.
Detailed description: A recording server, when introduced in the system, announces
its presence and auto-registers itself to the Video Management Server. A database
entry is created with the Server ID. The server gets the list of network accessible
storage devices (typically NAS or SAN) from the database and is thus prepared to
record data once one or more data sources (viz, cameras) are added to the server.
The recording is done by breaking up the video stream into chunks or clips of small
duration (typically 2 to 5 minutes), and the clips are initially stored in the local server
storage space. Periodically, the clips are uploaded to the NAS/SAN using all the
NAS/SAN in a round robin fashion.
The administrator of the system can form several "Server groups" by first forming a
GROUP and then assigning any server to that GROUP. Otherwise, all servers are
assigned to the DEFAULT group. As soon a server registers itself, it starts
multicasting a message describing its IP-address, group-ID and remaining capacity to
handle more cameras. The capacity is represented with a number. The number is
calculated based on the memory, bandwidth and current processor utilization within

the server, or it can be set by the administrator to be equal to the number of
cameras the server should handle, and the number is decremented or incremented
when a camera is added or removed from the server, respectively.
The Video Management Server and all other recording servers within the GROUP
listens to all such messages and maintains a list (LIST), as described below [taking
example for 4 Video Recording Servers (VRSes)]

Whenever a new server is introduced in a GROUP and starts announcing its capacity,
other servers enter into a contention avoidance session to decide who will be the
GROUP MASTER. Once the GROUP MASTER is elected, it consults the table above,
and balance the load amongst the servers by RELEASE and ALLOCATE operations.
RELEASE takes a camera away from the server, while ALLOCATE assigns a camera to
the server. This task of RELEASE and ALLOCATE is taken up by the GROUP MASTER
for the following cases which are discussed in relation to Figures 8 to 11:
1. When a new camera is added to the system (Fig-8)
2. When an existing camera is deleted from the system (Fig-9)
3. When a new recording Server is added to the system, or a failed server has
started operation again (Fig-10)
4. When a running server has gone down (Fig-11)
It is thus possible by way of the method according to the present invention to achieve
the following:
1. No dedicated, redundant server is required for back up support for recording.
It reduces cost and enables optimal utilization of costly hardware recourses.
2. No central point of failure exists. This is because there is no dedicated
redundant server. Had there been a dedicated server for back up support, if
that server fails no backup service is available in case a recording server stops
functioning.

3. No central hardware to serve client for live view or for recording video to
storage devices. This advanced feature not only avoids the risk of single point
of failure, but also does not limit streaming capability depending on the
configuration of a single server.
4. Failsafe against Storage and Server failure. Multiple storage devices are used
uniformly by the servers so that failure of a single or more storage devices
does not stops recording.
5. Round Robin scheduling of storage devices for recording for each channel. This
has the advantage that if a storage device is damaged beyond repair, still
recording for a prolonged duration at a stretch is not lost for any channel.
6. Multiple storage devices can be geographically distributed. This protects the
system from physical damage or damage of any particular storage device due
to hazards like fire etc at a particular site.

We Claim:
1. A method for sensory input recording and live streaming in a multi-server
environment comprising: a fail-safe server group
Each said server group comprising plurality of acquisition cum recording
servers
said multiple recording servers adapted to exchange information amongst one
another and left over capacity of each server is known alongwith the channel
information of every other server such that in case of any server failure in said
server group the remaining active servers in the server group automatically
distribute the required operative load amongst the remaining operative servers
for a fail-safe recording and streaming of the sensory data.
2. A method as claimed in claim 1 wherein each recording server auto registers in
the system and a database entry is created with the server ID whereby the
said recording server gets listed in the database and is then ready for
recording data from one or more sources.
3. A method as claimed in anyone of preceding claims wherein the recording is
done by breaking the data streams into chunks or clips of small duration and
the clips are initially stored in a local server storage space and periodically
uploaded to one or more network attached storage in a round robin fashion.
4. A method as claimed in anyone of preceding claims comprising plurality of
server groups which are operatively connected to network storage and as soon
as a server is registered in a Group it generates a message describing its IP
address , group ID and remaining capacity to handle more data
source/cameras.
5. A method as claimed in anyone of preceding claims wherein the capacity of
the respective servers in a server group is based on the memory, bandwidth
and current processor utilization within the server.
6. A method as claimed in anyone of preceding claims comprising assigning the
server operatively connected to the input sensory devices and the capacity of
the server determined accordingly with continuous monitoring of required
decrement or increment of capacity based on addition or removal of sensory
input sources.

7. A method as claimed in anyone of preceding claims wherein a server group is
adapted to allocate any one of the operative servers in said group as the
group master server and continuously monitor the servers in the group and
their respective capacities and decide on the allocation and release of the
input sensory source from any server within the Group.
8. A method as claimed in anyone of preceding claims wherein the said group
master server is adapted to release or add a sensory input source based on
required (a) addition of an input source (b) deletion of an existing input
source (c) addition of anew recording server to the system or when a failed
server again re-operates and (d) when a running server stops functioning.

ABSTRACT
There is disclosed a fail-safe architecture for recording video in a multi-camera Video
Management system, an advanced technique for estimating server capability for load
balancing, automatic uniform distribution of video recording load across all the active
servers, auto-registration of recording servers when they are active in the network,
use of multiple distributed NAS/SAN storage devices, automatic back up of recorded
video in the server local storage space in case of failure of the central storage,
automatic upload of the video files to the central storage once the storage system is
recovered from failure, video streaming to the clients without passing the video
through any central hardware and thus avoiding single point of failure, automatic
camera add and release operation on new server addition in the system and in case
of server failure, without any manual intervention. The recording system involves
multiple servers and is highly scalable with respect to increase or decrease in the
number of cameras, tolerant to failure of servers/storage devices.