Many people still use the term CCTV as a label for video surveillance of any kind. It has been the standard for decades. As I go into much more detail in my book, CCTV stands for “closed circuit television” which uses the 100 year old analog television system (NTSC & PAL) over coaxial, making them private and not publicly distributed. Typically the cameras were connected directly to a monitor (point-to-point) or a controller or multiplexer. DVS stands for Digital Video Surveillance or Digital Video Security. The primary difference here is the analog video is encoded digitally (1′s and 0′s) and the delivery method over a new and/or existing network infrastructure. It’s video over an IP network, client/server, rather than point-to-point. This makes it possible to view the video (being digital rather than analog) over an IP network from anywhere you have the client software installed (and the network configured). The real value in a DVS architecture is the simple fact that you do not need to run point-to-point connections. You can use an existing network infrastructure as long as that network has enough bandwidth, and can be configured for streaming video (QoS, Multicast, etc).
This proof-of-concept document is quite popular, all over the world. I thought I’d re-post it with a summary. Typically, a Video Management Software (VMS) takes control of an encoder and/or IP Camera when commissioning the device into the system. There are also encoders and/or IP cameras that will lose their individual intelligence when connected to a general VMS system, because the compatibility is minimal outside their own proprietary software. However, there are specific brands that allow bi-directional communications (proof-of-concept uses Axis and Verint, only because they were the two I had on hand in my lab at home), meaning that if someone logs into the web or telnet interface of the encoder and/or IP camera and makes changes, those changes are then automatically modified within the VMS, and visa-versa. There’s a synchronization that occurs. In a dual VMS architecture, you need a smart enough VMS system that will communicate bi-directionally with the devices (the proof-of-concept uses Genetec Omnicast and OnSSI). This way, wherever configuration changes are made, both VMS system and/or devices will all synchronize, continuously using the same, single Multicast stream. Operationally, collaboration and compromise may be required because the stakeholder using one VMS may wish to archive video at a higher resolution, but the stakeholder with the other VMS may not have the storage capacity, thus reducing their archive retention period.
The real value of this collaboration is that it does not require any additional hardware, if the right networking equipment is available to configure a shared Multicast stream.