Camera Control Video Surveillance

rftg.development.googlepages.com
Creation Date: January 20, 2008 Version: v0.10 - 5/MAI/2008 Author: Ricardo Fili
pe Teixeira Gomes
DISCLAIMER
This document was prepared by Ricardo Filipe Teixeira Gomes, who reserve all rig
hts. © 2008 Ricardo Filipe Teixeira Gomes This document is available for consult
ation and use if they are in compliance with all copyright and / or intellectual
property. A copy of all or part, by any means, texts and images available in th
is document is expressly prohibited unless the user respects the rights of autho
rship and / or intellectual property, citing it properly to the document, includ
ing imperterivelmente a clear reference to the author's website: "rftg.developme
nt.googlepages.com. The material contained herein is only a general information
based on personal experiences and is not intended in any way influence the reade
r on any specific matter. The contents of this document are provided as a conven
ience to readers and consist solely of non-binding information. The contents of
this document are provided "as is" and does not offer any guarantee on it. The r
eport's author disclaims any liability for losses that may occur because someone
is based on information contained herein, since this information is for informa
tional purposes only, not promised or guaranteed to be accurate, complete and up
dated. The same applies to the contents of any reference made to it. Any dispute
s arising out of or relating to use this document, or relating to copyright and
/ or intellectual property rights in materials that are part of this document sh
all be governed by Portuguese law and subject to the jurisdiction of the courts
of Portugal. Reading this document and its use implies the acceptance of these c
onditions.
© 2008 Ricardo Filipe Teixeira Gomes. rftg.development.googlepages.com
CONTROL CHAMBER OF VIDEO SURVEILLANCE
Ricardo Filipe Teixeira Gomes
Electrical Engineering Department
Instituto Superior de Engenharia do Porto 2008
This report satisfies all of the requirements contained in Instances of Mechatro
nics Laboratory, 2nd year of Masters in Electrical Engineering and Computer
Applicant: Ricardo Filipe Teixeira Gomes scientific Orientation: Lino Manuel Bap
tista Figueiredo Company: Supervision: Lino Manuel Baptista Figueiredo
Department of Electrical Engineering
Instituto Superior de Engenharia do Porto May 5, 2008
Summary
This work aims to develop a Dynamic Link Library (DLL) and an Application Progra
mming Interface (API) capable of providing high-level methods that enable the co
mmand / diagnosis of a video surveillance camera SONYTM IPELA SNC-RZ25. Addition
ally, it also aims to develop a demo application potential of DLL and API. This
same application also provides a starting point for an application desenvolviemn
to video conferencing and multi-multiintervenientes spaces, totally independent
of equipment manufacturer. It also proposed a system architecture of a distribut
ed video conference, and made some considerations about its implementation. Keyw
ords video surveillance, IP cameras, SONYTM IPELA SNC-RZ25, video conferencing.
i
Index
ABSTRACT ................................................. .....................
............................. ..................................................
..... I CONTENTS ................................................ .............
..................................... ..........................................
........ ...... III CONTENTS OF FIGURES ........................................
...... .................................................. ......................
............. V INDEX OF TABLES ........... ....................................
.............. .................................................. ..............
. VII ACRONYMS ................................................ ................
.................................. .............................................
. IX 1. INTRODUCTION ................................................. .........
......................................... ................................... 1
1.1. 1.2. 1.3. 1.4. 2. BACKGROUND ..............................................
... .................................................. .................... 1 OB
JECTIVES ................................................ ......................
............................ .................................... SCHEDULE 3 ...
................................................................................
.... .................................... 3 ORGANIZATION OF REPORT .............
................................. ..............................................
.... ......... 4
APPROACH TO THE PROBLEM ............................................... ........
.......................................... ........ 5 2.1. 2.2. 2.3. CONDITIONAN
TS ................................................. ...........................
....................... .......................... MOTIVATION ..................
.............................. 6 ...............................................
... ................................... 6 FRAMEWORK ............................
.................... .................................................. ........
.................. 7
3.
ARCHITECTURE OF THE SYSTEM ............................................... .....
............................................. ....... 9 3.1. 3.2. 3.3. The DLL .
............................................... ................................
.................. .......................................... 10 API - FULL_FOR_
SNC_RZ25 ............................................. .........................
......................... ..... 17 THE APPLICATION CON2MEC .....................
......................... .................................................. ...
........... 19
4. 5.
FUTURE DEVELOPMENTS ................................................ ...........
...................................... CONCLUSIONS .............................
................... 23 .................................................. ......
............................. 27
DOCUMENTARY REFERENCES ................................................ ........
.......................................... ........... 29
iii
Index of Figures
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9
Figure 10 Figure 11 Figure 12 Figure 13 Architecture of the developed software
.................... .................................................. .... 9 c
lass System ............................................... ....................
.............................. ................. 12 class Exclusive_camera_contr
ol ............................................... .............................
...... 13 class DAYNIGHT ............................................... .......
........................................... ............ 14 class PanTiltZoomFoc
us ............................................... .............................
.................. 15 class Camera_control_mode ................................
............... ......................................... Class Camera .........
...................................... 15 ......................................
............ ............... 16 class Other_operation ..........................
..................... .................................................. . 17 Ge
neral view of the application with the panel of CON2MEC arrows assets ..........
............... 20 Panel sliders application CON2MEC ...........................
............... ....... 20 ToolStrip to add new camera .........................
.................. .................................. 21 Dialog box for data ent
ry of new camera ....................................... . 21 Architecture of a
distributed video conference ..................................... 24
v
Index of Tables
Table 1 Timing of the project ............................................. ....
........................................... 4
vii
Acronyms
API DLL IP HTTP WWW URL JPEG - Application Programming Interface - Dynamic Link
Library - Internet Protocol - World Wide Web - Hypertext Transfer Protocol - Uni
form Resource Locator - Joint Photographic Experts Group
MJPEG - Motion JPEG MPEG Moving Picture Experts Group
ix
1. INTRODUCTION
With the increase in transmission capacities of current data networks, appear ev
ery day new applications and new perspectives of development of products based o
n the Internet. These developments prompted the interest in the business of vide
o-surveillance, resulting in the appearance of cameras for video surveillance ov
er Internet Protocol (IP). Currently, such devices due to its low cost, ease of
interaction and high technology are used in various other types of applications
including video conferencing.
1.1.
BACKGROUND
The majority of cameras for video surveillance over IP provide the captured imag
e using a computer that runs an embedded web server. This way enable the monitor
ing of the image through a simple browser. This is the simplest method of access
to the images [1]. The most common format of the images displayed by this type
of equipment is the Joint Photographic Experts Group (JPEG). In this case,€the t
erm "streaming video" is certainly not the right one, given that only images are
transmitted, or
1
frames in JPEG each time the server receives a request from the client (through
a browser or application that implements the same mechanism) [1] [2]. Much of th
e equipment already is providing transmission in Motion JPEG (MJPEG). In this ca
se it is only necessary to send a command HyperText Transfer Protocol (HTTP) for
 the camera provides a sequence of frames in
JPEG format, at a predefined cadence, ie streams which in practice comprises a v
ideo. Most technologically advanced devices already offer the acquired images in
formats that enhance the high quality video, such with the Moving Picture Exper
ts Group - 2 (MPEG-2) and MPEG-4 [2]. To the human eye, although cadences of fra
mes to 16 frames per second (fps) to cause the sensation of descontinuiade image
(typically "flash" image), cadences above 10 fps is sufficient to create a vide
o can convey the feeling of movement. Currently, it is considered that a video a
t 24 fps has cinematic quality. Usually the manufacturers of video cameras provi
de surveillance over IP, along with the equipment, a whole range of software. Th
e characteristics of this type of software varies between manufacturers, models
and ranges of equipment. All equipment to allow monitoring of images collected,
and if the equipment permits, the control / remote diagnostics as well as stream
ing audio uni-directional or bi-directional, and even videos. Some software pack
ages, most complete, have an integrated solution that allows management of acces
s to one or more chambers (creating user accounts, assigning permissions, ...),
simultaneous monitoring of images captured by several cameras, recording images
collected in digital format, motion detection, motion tracking, video conferenci
ng, and various other features.
Although several devices allow the control / dignóstico through the web server i
ntegrated in the equipment, using HTTP GET and POST commands, the communication
protocols between applications / control and diagnostic equipment are mostly pro
prietary and closed (for security reasons and / or commercial).
2
However, SONYTM has developed a proprietary protocol opened with the aim of stan
dardizing the command / diagnosis of video equipment. This is called VISCATM (Vi
deo System Control Architecture). But requires the use of an RS-232 to establish
connections between devices [3].
1.2.
OBJECTIVES
Based on a video camera surveillance SONYTM IPELA SNC-RZ25, the main goals of th
is project are: • Development of a Dynamic Link Library (DLL) and an Application
Program Interface (API) in C # language, so to enable monitoring / diagnostic e
quipment using methods of high-level, • Provide all documentation to support int
eraction with DLL and API developed directly in the DLL and API; • Ensuring the
robustness and reliability of the DDL and API developed through implementation o
f techniques for handling errors and exceptions; • Development of an application
capable of integrating simultaneously monitoring several IP cameras as well as
the control / diagnostic camera video surveillance used during project • Demonst
rate and validate the potential of DDL and API developed through the application
of its use in monitoring, control and diagnosis; • Ensuring scalability, modula
rity and flexibility of DDL, API and application developed in order to enhance f
uture developments; • Optimize application performance with use of multi-threadi
ng.
1.3.
SCHEDULE
In order to meet the objectives proposed, was designed to temporal distribution
of the various tasks throughout the period of time available for the project. Ta
ble 1 presents this timetable.
3
Table 1 Timing of the project
Activity \ week teaching project report preliminary report functional prototype
delivery of the final report of the Drafting presentation preparation arguência
Study protocol VISCATM Test command basic Pan-Tilt-Zoom Studies / interpretation
of "CGI command manual" Development of the Library "Full_for_SNC-RZ25" and hold
er Application Development "CON2MEC" Testing and Error Correction Test Final Pre
paration of the final report of November 4 th 5th 6th 7th 8th December 9 th 10 t
h 11 th Christmas Break January 12 th 13 th
1.4.
ORGANIZATION OF THE REPORT
In Chapter 1 we provide a brief presentation and contextualization of this work,
outlined the main objectives related to its achievement and presented the sched
ule for the completion of their basic tasks. In the following chapter 2, there i
s a brief overview of the problem and said some condionantes, motivation and the
ir framework of the project. Throughout the 3rd chapter describes the system arc
hitecture, explaining the DLL, API and application development. Following is the
4th chapter, where future developments are put in perspective, being a brief fi
nal note, the listed priorities. The 5th and final chapter presents some of the
conclusions result from this project.
4
2. APPROACH TO THE PROBLEM
The generality of equipment for video surveillance over IP software are able to
provide monitoring image, and control / diagnostic equipment. This can run on th
e client machine or the equipment itself and is accessible through a web browser
or a dedicated application. Notwithstanding the advantages of an application de
veloped by professionals dedicated to a particular manufacturer, factors such as
lack of flexibility / modulariade and closed source applications, limit its use
and determine possible solutions for integration with equipment from different
vendors and technologies. Solutions capable of such integration are not at all c
ommon. For the equipment used in the project (video surveillance camera SONYTM I
PELA SNC-RZ25), it is noted that it has an integrated server that implements sev
eral commands HTTP GET and POST, in a way that could be considered as a method o
f high- level. But they remain in their syntax and semantic characteristics of l
ow-level actions, nor can the abstraction it desirable for the medium.
5
2.1.
RESTRICTIONS
Equipment manufacturers already provide such applications and software packages
extremely complete, which allow the monitoring / diagnosis and monitoring. In pa
rticular, the equipment will be used for project development, has a very compreh
ensive software package with all the features already listed. Clearly not make s
ense to develop a similar application. Typically each manufacturer has a set of
command / communication protocols distinct, so that in the context of this proje
ct was not feasible a generalist approach at the level of control / diagnostic e
quipment than that available for its completion. The use of IP takes advantage o
f the perspective control / remote diagnostics (from virtually any location with
access to the World Wide Web (WWW)) and eliminates the need for two separate ca
bles for the same equipment (command + image transmission). But has some weaknes
ses in terms of security and any requirements of real-time. In contrast, connect
ing via RS232 can ensure real-time control and overcome weaknesses in security.
However, despite being still possible to monitor images from any location, the d
istance between the equipment and the control station / remote diagnosis is redu
ced to an extremely distance limited (limitations of standard RS-232).
2.2.
MOTIVATION
Analyzing the information gained, and the constraints laid down, there is a pote
ntial problem that needs to be resolved. The development of an implementation mo
nitoring cameras for video surveillance over IP takes on a character in itself i
rrelevant, since there are already several applications available on the WWW tha
t satisfy this requirement in a manner quite satisfactory. But an application ca
pable of concentrating the monitoring of several cameras for video surveillance
over IP, such as providing command / diagnosis camera available for this project
, may raise interest.
6
Known the purpose of the future, integrating the equipment in question in a vide
o conferencing application, the perspective of developing an API DLL and a robus
t, modular and flexible assumes an important character, not least because, when
studying the state of the art performed there were no similar solution. The pote
ntial inherent in the object-oriented programming, especially when it uses the C
# language, as well as the growing numbers of developers this kind of language
and ease of learning of it, motivates the development of all code is done in thi
s language.
2.3.
FRAMEWORK
The solution described in this work is intended to fall within the desenvolvimem
to an application of video conferencing,€allowing for the exchange of images bet
ween multiple physical spaces and multiple users simultaneously. The developed a
pplication already meets some of these requirements, particularly as regards mon
itoring and management of cameras displayed. The independence of the DLL and API
towards the application, ensure that changes to any of these components do not
bind the solution encontarda, enhancing future developments.
7
3. ARCHITECTURE OF THE SYSTEM
The project conducted possessed was limited only to desenvolviemnto software. Th
e architecture of the developed system is based on three fundamental components,
representable by the layering scheme of Figure 1:
Application
API DLL: Camera ... ... ... PanTiltZoomFocus
Figure 1 Architecture of the developed software
9
3.1.
The DLL
The HTTP GET and POST commands, provided by the server in this equipment alone a
re already likely to be considered as methods for interacting with a subject (th
e camera), providing a high level of abstraction in relation to the actions of l
ow inherent internal functioning equipment. However, there is no type of error h
andling and / or exceptions on the client side as well as some semantic level of
controls remains a logic low level (eg, the positions of Pan are in hexadecimal
format and not shaped angular degrees). Additionally, any return Inquiries resu
lting from the device is received in the form of a string, consisting of the con
catenation of several parameters simultaneously. The DLL developed aims, through
the introduction of a new software layer to abstract the programmer from these
details. Thus, access to the device is performed at a higher level, using method
s consistent format, semantics clear / direct and simplified syntax. The fact of
error handling / exceptions be provided at the DLL provides, in a fully transpa
rent, effective containment of the spread of errors / exceptions directly on the
lower layer, avoiding the propagation to the application layer.
The BDS is composed of several classes of objects, and each of those classes has
a specific set of methods. The structure implemented aims to recreate the comma
nd structure presented in [4]. Each class of objects is not more than a bunch of
commands (System Exclusive camera control, Date and time, ...), and that each o
f its methods, like public, correspond to each of these commands (WelcomeText "<
Text>" AbsoluteZoom "<zoom position>", ...). With this it is intended, and also
decrease the learning time and interpretation necessary, arrange in a simple way
the various commands. The interaction with the device is bidirectional, ie, whe
re there is, there is a method to allocate a certain characteristic of the equip
ment (eg
private string AbsolutePan (pan_angle short, short speed))
and a method
complement that lets you know the status of a particular characteristic. The lat
ter
10
always begin with "get_" (for example:
pan_angle, short speed)).
private
string
get_AbsolutePan (short
Although not implemented all the methods of each class of objects corresponding
to each of the commands of the various groups of commands, all are defined and s
tructured. This will make sure that future developments meet the basic requireme
nts of integration without changing the structure set. Pay attention to the foll
owing descriptions. 3.1.1. ASPECTS COMMON TO ALL CLASSES
All classes of objects have a set of identical methods and variables are fundame
ntal to the implementation of definite structure, these being the following: •
internal string set_LoginCredentials (New_Username string, string
new_password)
- A method that allows the definition of access credentials
equipment with which you want to interact, the level of access defined - interna
l - this method is visible only up to grade level where he was pronounced; • •
set_URL internal string (string new_URL)
- A method that allows the definition of
Uniform Resource Locator (URL) of the equipment with which you want to interact;
Private Request (string action)
- Method used to perform the WebRequest
formulated, the level of defined access - private - so this method is visible on
ly within the class where it is created, it is noted that only receives as input
parameter "string • • • • •
action ";
private string URL
- Variable that allows the URL, can only be set by
set_URL method;
private string command_URL
- Variable that allows the static component of the command
to formulate common to the respective group of controls;
private string action
- Variable that allows the dynamic component of the command
formulate;
private string username
- Variable that allows the value of the username, can only be
defined by using the method set_LoginCredentials;
private string password
- Variable that allows the value of the password, can only be
defined by using the method set_LoginCredentials;
11
As presupposes the object-oriented programming, variables and methods of no inte
rest to the upper layers are protected by restricting its domain to its scope. 3
.1.2. CLASS "SYSTEM"
This class aims to implement controls inherent in the interaction with the equip
ment at identifying properties / characteristics of the system (model, serial nu
mber, control of axes available, ...), as well as basic states in terms of its l
ayer presentation (text "welcome", a definition of how to allocate URL, ...). Fi
gure 2 summarizes all the available methods in the class "System". Note that the
methods that they are to be made available to the higher layers of software com
e with a defined level of public access-type. We can also identify the presence
of a particular method -
inq_system () private string
- Whose aim is the realization of the inquiry request, and receiving response
which followed a string with all the strands of the Inquiry Parameter "system" a
ssociated with system.cgi [4]. This method will always be called by any of the m
ethods "get_ ..." when its use.
Figure 2 class System
12
Figure 3 Exclusive_camera_control class
3.1.3.
CLASS "EXCLUSIVE_CAMERA_CONTROL"
In this class, besides the methods common to all classes, there are three contro
l methods (and their complementary Inquiries related) which affect the control o
f the equipment. In a similar way to the class "System", there is a specific fun
ction for the inquiry posed by this group of methods. 3.1.4. CLASS "DAYNIGHT"
For the class "DAYNIGHT" it is noted that only two methods were implemented most
important of this group: • •
public string DayNightMode (string order)
- To define how
as
equipment does the night vision mode;
public string DayNightOnOff (string order)
- Allows on / off mode of vision
night. Additionally yet implemented their complementary (and get_DayNightMode
get_DayNightOnOff)
and also the method associated with the process of inquiry (inq_camera).
13
Figure 4 class DAYNIGHT
3.1.5.
CLASS "PANTILTZOOMFOCUS"
It is in the class "PanTiltZoomFocus" which are established methods for the cont
rol of mechanical functions of the camera, as well as those that allow to obtain
the physical coordinates of the view plane. In order to make your utlização mor
e intuitive and simple, this class has some differences with regard to the simil
arity of their methods for commands presented in [4], so it is advised to consid
er only the presentation available in this work. It is noteworthy that some of t
he methods listed in this class need to resort to methods of class "Camera" in o
rder to fulfill their duties. Thus the constructor of the class "PanTiltZoomFocu
s" appears overwhelmed by an object "cam" type class "Camera" -
public PanTiltZoomFocus (Camera cam).
Thus it is
allowed within the class "PanTiltZoomFocus" there is an object of type "Camera"
(the "path"), so the methods from the "Camera" can be used [5].
14
Figure 5 class PanTiltZoomFocus
3.1.6.
CLASS "CAMERA_CONTROL_MODE"
This class provides the methods needed to define parameters related to the metho
d of physical control of the chamber.
Figure 6 Camera_control_mode class
15
3.1.7.
CLASS "CAMERA"
The class "Camera" was undoubtedly the largest of the development. Some of the m
ost important and most relevant properties of the equipment, which can be contro
lled, contained in this class.
Figure 7 Camera class
16
3.1.8.
CLASS "OTHER_OPERATION"
For this class, was implemented only one method (besides those taken with key).
This allows to start or restart the machine.
Figure 8 class Other_operation
3.1.9.
CLASS NOT IMPLEMENTED
All classes that are not listed above have not been developed. But its structure
and methods / core variables were implemented.
3.2.
The API - FULL_FOR_SNC_RZ25
As mentioned in the previous chapter, the DLL provides methods developed that ab
stract the programmer from all aspects of the formulation and implementation of
HTTP GET and POST commands, error handling and exceptions,€Inquiries return form
atted commands and transduction of low-level semantics. However, the intention t
o integrate all the objects of the DLL, and need for some methods rely on the me
thods of other objects, led to an API that was developed. With use of this API,
the programmer, after adding namespace
Full_for_SNC_RZ25 you just need to create an object of type NetCam_SNC_RZ25 (or
an array of this kind) to access various groups of methods, that these groups ar
e in fact objects in the domain of the API.
17
For example, if you want to change the contrast of the image available, change t
he absolute orientation of the camera and know the current image CODEC in use, s
imply the following code:
using Full_for_SNC_RZ25; ... (... / / Object creation NetCam_SNC_RZ25 NetCam_SNC
_RZ25 CAM1 = new () / / put cam1.Camera.Contrast contrast = 5 (5) / / Pan = 30;
Tilt = 60 º; travel speed = 10 cam1.PanTlitZoomFocus.AbsolutePanTilt (20 , 60, 1
0) / / puts the value of the CODEC from "CODEC_em_uso string CODEC_em_uso cam1.C
amera.get_ImageCodec = (); ... ) ...
Between
other
possibilities,
the
that
API
may
without
any
type
of
objection / difficulty of integrating directly or indirectly sets new methods th
at makes available another type of action, using the existing methods. For examp
le, notice the following snippet of code:
... / / New instance method that "sweeps" the entire area visible public void va
rrer_ambiente () (int tilt; for (tilt = -30; tilt == 90; tilt + = 10) (PanTlitZo
omFocus.AbsolutePanTilt (170, tilt, 20) ; While (PanTlitZoomFocus.getTilt ()! =
tilt); While (PanTlitZoomFocus.getPan ()! = 170); PanTlitZoomFocus.AbsolutePanTi
lt (-170, tilt, 20); While (PanTlitZoomFocus.getPan ()! = -170); / / if zoom ran
ge, lower pitch tilt, change speed, change path, schedule, motion, etc ... ))
18
3.3.
APPLICATION CON2MEC
The developed application - CON2MEC - presents itself as an end solution capable
of providing monitoring functions of several cameras for video surveillance ove
r IP, as well as to monitor / diagnose for a camera SONYTM IPELA SNC-RZ25. Assum
ing that the application would have only one thread, considering that from the m
oment it is realized in a given WebRequest in order to acquire a frame until it
receives the entire frame, the application does not perform any other action. Th
e solution to this problem is found to be used for multi-threading techniques. T
hus multiple tasks can be performed "simultaneously" within the same parent appl
ication. In order to proceed with the implementation of techniques multhi-thread
ing, more efficient and robust, it was decided to create a vector of type
Thread
eight positions, each of these corresponds to each
PictureBox hosting the displayed image. Whenever a camera is added a new thread
is launched, and the method associated with it,
camBox_handler (object position), private void
triggers the necessary actions to update
image of their PictureBox at a rate of 10Hz. This occurs until it is off to the
chamber panel of the application when it is called the method
close_connection (short cam_number)
to end the thread corresponding to
Board index cam_number vector threads.
As can be seen in Figure 9, the application CON2MEC provides a series of command
s to interact with the camera used in the project. In particular note that the c
ommand is visible through a panel PanTiltZoom arrows. Alternatively you can sele
ct the command PanTiltZoom through sliders (selecting "slidebar control") presen
ted in Figure 10, which supersedes the position occupied by the panel of arrows.
The addiction of new cameras is easily accomplished by using the menu "Configur
ation" -> "Add Camera" -> "Add new camera", as shown in Figure 11, which activat
es the dialog shown in Figure 12.
19
Figure 9 General view of the application CON2MEC with the panel of active arrows
Figure 10 Panel sliders application CON2MEC
20
Figure 11 ToolStrip addition of new camera
Figure 12 Dialog for data entry of new camera
21st
4. FUTURE DEVELOPMENTS
A possible future development of this project may be based on building an infras
tructure for video conferencing flexible, scalable, distributed and capable of s
upporting a large number of actors / spectators. Figure 13 shows an enlarged dia
gram of a possible structure. The figure does not mention any details concerning
logical connections established between each of the agents,€so the following de
scription is crucial. Due to the camera video surveillance to provide a manageme
nt service access control, configuration and monitoring through an integrated se
rver, it will be entrusted with the security of access to such equipment. Howeve
r necessary to ensure that both the data network (LAN) or the amount of media se
rver (SERVER), the security of such information will not be called into question
.
23
@ My_domain1 Board controlled locally via RS232 or via ETHERNET Total transparen
cy in networks SWITCHED ETHERNET cameras controlled remotely via Ethernet @ My_d
omain1
LOCAL CAM
SWITCH
RS232
@ My_domain2
ETHERNET
SWITCH
`
LOCAL CLIENT
LOCATION ADMIN LOCAL CLIENT
@ My_domain3
LOCAL CLIENT
SERVER
Remote Client
Remaining Services + INTERNET
REMOTE CLIENT
REMOTE CLIENT
Total openness to Wireless
`REMOTE REMOTE CLIENT ADMIN
Possibility of remote administration
Camera controlled remotely via the Internet
Figure 13 Architecture of a distributed system of video conferencing
24
Each device only has the ability to manage the direct access to an administrator
and 9 users (using authentication USERNAME + PASSWORD). It is also possible to
allow / prevent access by policies limiting the level of IP. In each chamber sho
uld be configured an administrator with full privileges, by assigning a pair USE
RNAME + PASSWORD. The server, which will have just as role disponibizar multimed
ia content for Internet or LAN, should be designed exclusively with privilege of
read access to multimedia content of each chamber. Thus links are established p
eer-to-point secure, which can be authenticated by a set USERNAME + PASSWORD, an
d under total control of the Trustee. The safety of access to multimedia content
available from the SERVER should be controlled by the same or another qualified
entity (eg.: FIREWALL). All media content via Ethernet or circulate only in a m
ore abstract way, via the Internet. However, data related to the control / confi
guration of the devices may move via Ethernet or through point to point links (A
DMIN LOCAL CHAMBER) via RS232 protocol using the VISCATM.
Taking into account these peculiarities, as a matter of system architecture, all
local client (local client), sputum is strictly necessary, they are accessing c
ontent through the server, as if they were remote clients (REMOTE CLIENT). Thus
the local scale is never compromised by limitations related to the characteristi
cs of the camera. Easily be inferred that the proposed architecture ensures full
scalability in terms of direction and spatial distribution of the stakeholders,
 ie, implements the concept of video conferencing and multi-space multi-user, as
opposed to the classic model of "duo-conference." Additionally, it is still val
id to say that the dynamics of access will only be dependent on the capabilities
of (s) SERVER (s), or the level of access management, both in the provision of
services (internal / external). Thus is raised the security level and broken lim
iting the number of players in the video conference. Note however that in order
to achieve this objective, it crucial that initially was developed the code nece
ssary to the acquisition and transmission / reception
25
audio via IP. Improvements to the level of image format presented should be achi
eved by presenting the MJPEG format as the most flexible in this project.
26
5. CONCLUSIONS
The completion of this project premit conclusion, clearly, that on IP video surv
eillance cameras have several potential level of development of applications in
the areas of video surveillance, but also video-conference. It was also possible
to conclude that the interaction of the programmer with a web server, owned adv
antageous features, especially when the objective is the development of small ap
plications, or other HTTP-based. But this same factor determines the development
of applications for medium or large scale. Due to the nature of the application
CON2MEC was possible to prove that the implementation of DLLs and APIs dedicate
d, despite consuming substantial development times, present themselves as the mo
st effective solution to such problems. Despite the difficulties encountered dur
ing the development of the project at all times were clear advantages inherent i
n using a programming language oriented to objects, such as C #.
27
Documentary references
[1] Brick House Security - All About IP Network Video Cameras, Brick House Secur
ity, New York, 2007, http://www.brickhousesecurity.com/about-ip-network-videocam
eras.html. Kirilov, Andrew - Camera Vision - video surveillance on C #, The Code
Project, Latvia, 2006, http://www.codeproject.com/KB/AUDIO-VIDEO/CAMERAVIEWER.A
SPX. SONY - EVI-D30/D31 Command List (Ver. 1.21), SONY, 1999. SONY - SNC-RZ25N /
P CGI command manual version 1.1, SONY Corporation, 2006. ARCHER, Thomas - Insi
de C #, McGraw-Hill, 2002, ISBN 972-773-155-4.
[2]
[3] [4] [5]
29