IFSEC 2014 – DVR Export Results

It’s taken a little longer than expected but my review of DVR exports is now complete.

During my visit to IFSEC 2014 I decided to give myself a challenge. The purpose of this was to highlight some of the challenges faced by Forensic Video Analysts.

I went with 5 questions, all relating to a Video Surveillance System’s ability in exporting evidential video, along with the capabilities of the software provided. I have posted details of each export and subsequent analysis in the following pages:

Before I summarise the review, may I take this opportunity to thank all the sales staff on each manufacturer stand. Seven of the eight completely understood why the video must be understandable, and were very supportive of my efforts to help the industry improve export methods, playback and analysis. Special thanks to Pelco and Norbain, who kept their promise and sent me their exports after the show. It was a shame that Avtech refused to allow an export and failed to understand an important key point. That is, any person considering a video surveillance device must take into account the quality of the recordings and then the ability for it to be exported, played and analysed post incident.

Whilst conducting the exports, I purposely did not document any DVR settings, such as frame rate, pixel size, use of motion detection etc. This was to replicate what happens in reality – Disks and USB devices arriving with little or no information. When I conduct a retrieval, these are some of the points that I document as I know that the chances of this important information being included is pretty minimal.

The following points are in no particular order, but in general I will attempt to keep to Evidential Export, then Playback, then Investigation.

Whilst speaking with the sales staff, it was generally agreed that a devices ease of use, and in particular the export facility, was a key selling point. However, a number of staff had no idea how to export and had never considered it’s importance before it being discussed with them.

A DVR/NVR’s design is linked with it ability to quickly export relevant material. Its great that USB 3.0 is starting to make an appearance, but there is little point putting this on the back of the device.

A number of devices have the ability to allow HDD removal and reading. This is fantastic. Remember that a device must be able to export 10mins, 10hrs or everything…. and all the variations in between. Having the benefit of native HDD reading is a massive bonus. Remember though that the HDD should be in a caddy, or at least, easily removal.

When an optical disk is entered into a standalone NVR/DVR, or a USB data device is inserted, then the export interface should open automatically. Some of the devices examined did not even light up the USB LED to indicate that it was being read.

A clear definition must be made between video suitable for evidential use and video suitable for sending a funny clip to YouTube. If the wrong decision is made early on, it could be too late to recover.

Before a download starts, there should be some form of calculation completed. This should be displayed on screen. What is the estimated data size and how long it is going to take? This is very important in large recoveries where a staged approach is necessary.

Footage must be recoverable from either the site where the cameras are situated or nearby. Analysis of the footage can be hindered due to the Video Surveillance System being managed by a control centre at the other end of the country with even the store manager being refused access. If footage is streamed over a remote network, or stored ‘in the cloud’ then a very good authentication check must be made and presented with any evidential export. This must prove that what was recorded, is what has been provided. Dropped/missing frames and corrupted imagery are becoming a common occurrence due to bad networks.

The settings and recording information should also be exported. Frame rate, frame count, Motion Detection recording, GOP, format, Display Aspect Ratio etc – it’s all important!

Documentation. Generic looking black boxes with no idea of make or model number are a nightmare. Once this information is planted on the front of a machine, all relevent information relating to that device should be found on the manufacturers website. Most common reasons for searching for information appears to be passwords, and how to export and play the resulting footage. I know these things are popular as I review web searches that result in people locating spreadys.com.

These devices last a long time, probably longer than you think. I still have to deal with first generation DVR’s that have no export method at all and went to market around 2000. Remember to keep your legacy device help and information on-line.

The player must be kept as light as possible. Definitely no installation required of either a player or a video codec. The minimum functionality is single camera playback and extract an uncompressed still image.

During playback, individual images should be identifiable through the use of either frame count or milliseconds.

The button for Help should bring the user Help! Most users are not interested in the version number or when it was built… They are looking for help. (The analysts need the Ver. No, so don’t leave this out though!)

Help can either be built-in or on-line. If it’s on-line remember that many corporate networks are restricted. Don’t just supply a button – give the exact URL.

If further functionality is available in the form of client software or plug-ins then put this in the Help file, along with what extra options they provide.

If proprietary encoding is used then full details must be available either at the download stage or on-line. To make it easier – don’t use proprietary encoding – Stick with standards, that’s what they are there for!

The video, and audio if its there, must be able to be exported out of any proprietary container or executable. Preferably it should retain its original form. Transcoding portions of the exported footage must also be possible in order to utilise the footage for whatever purpose. The ability to export a sequence of images should also be possible.

Timecodes, if not hard encoded at capture, should be able to be exported as standard subtitles.

The footage must be ‘transparent’. An investigator should be able to fully analyse its structure and timing in order to correctly interpret the captured event. This includes analysis of macroblock type and motion vector movement between frames. Identification of dropped and missing frames must also be possible.

Manufacturers should integrate with as many Forensic Video Companies as possible. To help you, see My Big List of Links! This is especially important for those who wish to encode using a non standard method.

Technology has allowed the Video Surveillance Industry to move ahead at an unbelievable rate. I believe we have now reached a pivotal moment, where the actual capture and encoding is able to be offset to the camera. This leaves developers a lot more scope to concentrate on the storage device. With network access and large file transfer now possible, the manufacturers who consider what happens to the footage after is has been recorded will be the ones who stand out in a very crowded marketplace.

What I have said above is just the start. There are many more points to consider as we move towards shared network access or inbuilt file sharing options. With those developments comes a new set of challenges. It will be difficult however, to deal with those without dealing with some of the issues here first.

This has been a wonderful opportunity to see some of the latest developments in exporting and playback. I hope that by detailing what would make things better for me, the analyst, the industry can learn, and develop, to make the next version of the hardware / software the best that it can be.

Spready