Throughput

When selecting servers, it is vital to consider the potential data throughput that a security system may require as and when higher resolution image capture is added.

2014 represented the first year that IP cameras outsold analogue CCTV with High Definition 1080P cameras rapidly becoming the ‘de facto’ camera of choice in most professional CCTV applications. 4K has become the latest buzz word, which at 8 megapixels is 4 times the resolution of 1080P and over 20 times the resolution of a conventional analogue CCTV camera and recently we have seen CCTV cameras available on the market with resolutions of up to 30 megapixels on a single sensor.

With additional resolution comes larger image sizes, so using comparable compression standards and frame rates the data produced by a HD camera will increase proportionally with resolution. One option to record sufficient cameras on a server is to reduce frame rates or increase compression and whilst H.264 is a very efficient video compression standard the fact remains that over compressing a megapixel image will eventually outweigh the advantages the additional resolution gave you in the first place.

So, let’s have a look at how H.264 works. H.264 is motion-compensation-based video compression standard. Image streams consist of I-Frames, a full frame reference image, followed by a number of P or predictive frames which only update pixel change from the reference image or previous image. This process massively reduces the data stream by not re-creating data we already have stored. Because of this many industry calculators will ask you to define scene complexity for each of the cameras as the amount of data created (and therefore the processing and storage calculations) will be entirely dependent on the amount of movement in the image, as movement increases pixel change increases and therefore so do the individual frame sizes and the total data stream from the camera.

In general industry calculators are poor and often give wildly varied results and partial information. When calculating your server requirements there are two important numbers you need for any h.264 device, Average bandwidth and Peak bandwidth. Average bandwidth is the sum of the individual I and P frames in one second during routine operation measured in Mbps (Megabits per second); this is this number that will be used for storage calculations. Often absent in industry calculators however is the Peak bandwidth value, the maximum potential bandwidth output should all pixels be changing at the same time.

The server you select must be able to handle the peaks caused by high pixel change on all cameras simultaneously or you risk server failure at potentially the most critical time. On many cameras and VMS’s a bandwidth cap is applied allowing for an easy calculation but as a rule of thumb peak bandwidth could be four times that of a quiet scene and double that of a busy scene. 

As an example of where this calculation is important, think of a hotel. Generally, there will be a few people walking in the corridors at any one time, a few people at the bar and a few at reception, most cameras are ticking over on very low bandwidth as pixel change is minimal. Imagine now that there is a fire in the middle of the night, the alarms go off, emergency lighting on, smoke, flames, sprinklers and general chaos. Suddenly all of the cameras will experience very high motion simultaneously and your server must be prepared as this is one of the mission critical applications the CCTV system was installed for in the first place, the last thing you need is the core of your system failing and shutting down.

So, you have done your bandwidth calculations, what are your options? Most industry available servers are rebadged generalist servers designed for multi-tasking, to host websites, databases, backup, email servers and likely most of the data on social media sites we all use on a day to day basis, they will also run your VMS if you wish. However, remember there is nothing more data intensive than video other than multiple streams of HD video. Because of their generalist nature IT centric servers will also often have a restricted throughput seriously limiting the number of HD cameras recording to a single server.

There is a common misconception in the industry that to increase the throughput of a server you simply need to upgrade the processor, however with specialist knowledge and components there are many more ways to optimise throughput. There are a few server manufacturers emerging in the industry today who truly understand how IP video works, how it gets from A to B, who have taken the time to analyse the intricacies and modus operandi of the various VMS options and who are creating servers to meet the demands of increasing camera resolutions without having to make compromises on camera performance. Specialist servers for HD Surveillance are available today with a throughput of up to 4000Mbps (input and output) equivalent to 15 off the shelf, IT Centric servers commonly on offer.

The VMS you use and other parallel video applications such as Mobile Gateway, LPR or video analytics will all impact the overall performance of your server, often requiring multiple servers or virtualisation to achieve the end requirement. Industry calculators will often only deliver an average throughput and a storage number, sometimes suggesting a processor that might be required, however they will never provide enough information for your local server manufacturer to build an optimised solution for the application. Consulting an HD surveillance server specialist can often save considerable time, money, rack space and power not to mention the peace of mind that your hardware solution has been designed with an in-depth knowledge of both IT and IP Video.

As a final thought, recording compressed streams of HD video is only part of the battle, serious consideration should also be given to the hardware requirements to decode and display multiple streams of HD live and playback images, especially given the recent popularity of HD Panoramic cameras. But that is a different paper…