Software scene analysis of CCTV signals is an increasingly important tool in many surveillance applications. Video compression – which is required to transmit video signals over standards-based Ethernet or SDH networks – can ‘throw away’ valuable video scene information that’s required by effective scene analysis software.
Software analysis will become even more significant in the future as camera counts increase. That being the case, video compression can limit the future use of these tools.
However, transmission systems designed to avoid these limitations are now available. They have all the benefits of the standards-based networks, but also the ability to carry uncompressed video signals. They also transport other required services of both Ethernet and traditional low speed data.
In a market where ‘going IP’ has become the mantra over the past few years, there’s now an increasing need to look at how we ensure the future proofing of CCTV systems. Future proofing becomes even more pertinent when we examine large-scale surveillance applications (traffic management projects among them, so too other transport applications such as airports, ports and railways).
Even larger industrial applications like oil and gas refineries increasingly demand that uncompressed video signals be fed back to the CCTV Control Room.
The fact is that when employing IP-based transmission, the end user actually compromises the video signal just to make it more convenient for the transmission system, and that then begins to limit the future usefulness of the signal in a pretty significant way.
Traditional uncompressed video transmission
Historically, the challenge for the transmission system was to send a picture from the camera to the user, who would view the video signal on a monitor. Traditional transmission systems designed specifically for video were, in the main, point-to-point as well as being limited in transmission distance capabilities, non-resilient and unmanaged.
Each camera would have a single fibre link back to a cluster point where it would be re-transmitted on a multichannel link (ie 16 cameras sited along a motorway would need at least eight fibres). This approach has significant drawbacks when any kind of fault arises. It also makes the addition of further cameras – and the moving of cameras – somewhat more difficult.
Therefore, some method of using the ring architectures of SDH or Ethernet was sought, offering the benefits of:
– significantly reduced fibre count
– dual route redundancy – resilience to fibre breaks and node failures
– drop and insert architectures
– virtually unlimited transmission distance
– integrated switching and routing
– anywhere-to-anywhere connections
– simultaneous multi-site viewing
– integration with other signals
– very large capacity networks
That said, in order for the end user to take advantage of these networks, the video signal must be compressed.
Video compression: what’s it all about?
An uncompressed video signal requires 140 Mbit/s of bandwidth from the transmission network. In order to carry many video signals, compression has to be used for the cost-effective transmission of multiple video signals over an Ethernet or SDH network. Compression can bring the bandwidth requirement down to between 25 Mbit/s and 64 kbit/s per camera signal (depending on the video quality requirement and the bandwidth available).
Various compression standards are used in the CCTV market to fulfil this requirement. These include, of course, MPEG-2, MPEG-4, MPEG4-10, H.263, H.264, Wavelet, MJPEG and MJPEG 2000.
The choice of which technology to apply is typically determined not only by when the decision is/was made, but also by the cost and capabilities of the respective compression algorithms. Capabilities have improved with time in terms of reduced bandwidth requirement versus quality. However, backward compatibility hasn’t been maintained. This continues to be a serious problem when selecting a specific technology.
Some manufacturers attempt to accommodate future improved technologies by using DSP-based, non-algorithm specific architectures but, as the technology moves forward, so too does the processing power requirement. Hence, older DSP-based systems no longer have the capacity to move to the newer algorithms.
Video compression can mean compression ‘within a frame’ as well as compression from ‘frame to frame’. A static low content video scene may be sent with a minimum of bandwidth. As the scene content increases with more detail, so the ‘within the frame’ bandwidth requirement is increased. As the motion within the scene is increased, the ‘frame to frame’ bandwidth requirement is increased accordingly.
Bandwidth requirement may be further compromised if low latency compression is required for PTZ camera systems. Therefore, choice of algorithm should include specifications for the worst anticipated case in terms of scene detail, activity, latency and resolution. These can then dictate the algorithm and the overall bandwidth requirement of the network for the end user.
It’s important to note, however, that all of these algorithms throw video information away. Information that cannot be recovered. If the Ethernet or SDH networks could accommodate the uncompressed video bandwidth then this would obviously be the algorithm of choice.
Limitations of video compression
The traditional limitations with the use of video compression – as associated with viewing quality and response latency – are still an issue for some applications. Moreover, further topics are now coming to the fore. The more significant of these are:
– the inability to take advantages of third party scene analysis software at the time of installation or, more significantly, at any time in the future
– the total loss of the system when the network crashes, together with the skilled network support resource needed to reinstate and maintain the network
– the simultaneous multiple agency use of the video, each with its own transmission limitations
– problems associated with the creation of a National Operations Centre, bringing in signals from many Regional Control Centres
– system latency
– frozen frames
– susceptibility to hacking
Let’s examine the implications of some of these issues.
Scene analysis software
The use of sophisticated scene analysis software is becoming a significant tool for the processing of CCTV images. This is not only because the number of cameras is increasing and the use of human operators becoming impractical, but also due to the fact that software capabilities are improving and are now more successful.
These software applications can be developed independently of the transmission system, their usefulness dependent on the quality of the video scene information available to them. It’s important that the video transmission system doesn’t compromise or limit future use of any such software packages.
The effect is currently best demonstrated when using video processing software for smoke detection in tunnels, for example. For a system which could raise an alarm within a few seconds of the first appearance of smoke when presented with an uncompressed video stream, this is delayed until virtually the whole scene is filled with smoke when presented with an MPEG-4 video stream.
The point is also demonstrated with the inability of ‘off-the-shelf’ commercial traffic flow software – even for the most simple functionality – to operate with a compressed video stream reduction. Not to mention the reduction in the reliability of some Automatic Number Plate Recognition video processing software when used with compressed video streams.
Sophistication of scene analysis software and the requirement for more detail from the video stream is only going to increase in the future. The way to maximise the video scene information available is to avoid compressing the video prior to it being processed. This means either processing it at the camera or transmitting it back to the Control Room in an uncompressed format.
In terms of the latter method, it’s clear that the system can be future proofed against any incompatibility between any scene analysis software and the method used to transmit the signal to it. The former method is fine if the software harbours all the requirement capabilities.
Network capabilities and transmission
The use of an IP-based system for video transmission does place demands on the network above and beyond what would normally be required for a relatively ‘simple’ data network. These demands may only become apparent as the camera count increases.
Large systems with over 150 cameras – but sometimes smaller depending on the type of network – can require network routing and quality of service protocols which are not available within low cost ‘simple’ networks. The result of not having them can lead to a significant amount of network congestion which, at the minor end of the spectrum, leads to non-access to certain signals. With an incorrectly configured network, it can also yield a network crash.
That leads me nicely to another issue associated with fully IP networked-based system. IP networks do crash. Sometimes this is due to a mistake by an engineer. The larger the system, the more likely this is going to occur. In the case of a fully IP network-based CCTV transmission system, this means that none of the camera signals would be available.
The use of a separate transmission system specifically designed for the collection of video to a distribution point, Control Room or processing point prior to being put onto an IP network ensures that the video will always be available at that location even in the event of a network crash.
Another factor not always taken into account is the quality of the IP network support resource required to reinstate and maintain the network. This can be an expensive overhead associated with operating an IP network.
Multiple compression: a further limitation?
Another limitation that can be caused by compression results from the requirement of multiple users to simultaneously view the same video signal. This is fine if all the agencies require the same quality of signal. However, if the collection of the video to a distribution point has used compression of one type and the onward routing also requires compression of another, the video signal may have to be brought back to an uncompressed format.
Re-compression of a previously compressed signal can be problematic. The way to ensure that a video signal can be onward-routed to any user from a distribution point is to transmit the signal to the distribution point in an uncompressed format.
Hacking of IP-based networks
The only secure way to prevent the hacking of an IP-based network is to prevent access to that network! Methods for hacking into CCTV networks are readily available on the Internet. Here, you’ll find illustrations of not only how to access the network but also how to ‘jam’ video streams, freeze them and even replace them. This issue is very significant for real security environments.
Taking the IP node to remote roadside locations allows for relatively easy access to the network. Using an uncompressed video transmission network to collect the video from the remote roadside locations and bringing it back to a controlled environment prevents access to the IP network. The processing can then take place in the controlled environment before being compressed and put onto an IP based network.
Uncompressed video transmission networks
It’s clear that if Ethernet or SDH networks could easily transmit the video uncompressed then this is the way it would be done. As this is unfortunately not the case, there is now a range of transmission equipment for end users that has been designed to replicate the benefits associated with the Ethernet and SDH networks but without compressing the video. The solution doesn’t compress the video, and what’s more is immune from the limitations listed above.
For the video collection, it’s possible to amass channels of video and distribute Ethernet, low speed data and audio signals on a single unit located at the roadside. These can be connected on a dual redundant ring architecture with a single fibre daisy chaining between each unit.
The benefits of this approach are the minimal use of fibre, ease of camera addition (or other field service devices), the ability to drop off signals at multiple locations and the effectively unlimited transmission distance. The dual redundant capability ensures that the operation is maintained in the case of a fibre break or loss of power at a unit.
The system can be fully managed via industry standard SNMP or via a proprietary GUI to highlight any faults in the fibre, while full operation is maintained at all times. It also monitors video availability and loss of power.
Recommendations for the future
When it comes to future proofing CCTV transmission, it’s evident that careful consideration needs to be given to a number of key factors. It’s equally clear that any organisation planning the development of a new wide area surveillance system needs to give due consideration to the method chosen for transportation of the video signal.
The wrong choice made at the outset could seriously limit the effectiveness of the system, not to mention restrict the ability of future upgrades configured to take advantage of the expected advances in the capabilities of important tools such as scene analysis software.
Dr Alan Hayes is the founder and managing director of AMG Systems
