Welcome back to our series on CCTV Acquisition where in this post we will be looking at remote acquisition using a mobile device. We briefly looked at this in a previous post where we examined the challenges of CCTV and video evidence that are submitted to the police by the public.
Many CCTV owners will not realize the differences between what they are viewing and recording on their tablet or cellphone, compared to the original recording on the DVR. Consequently, incorrect decisions are made on a piece of footage caused by the lower quality. The situation is often exacerbated by poor evaluation processes and then bad quality Digital Evidence Management System (DEMS) transcoding.
Mobiles and Tablets
We all now have a smartphone and many will have a tablet PC. All these mini-computers have the ability to access a computer network and play and record video. The result is that they are then ideal to receive video data from a CCTV system and then save it as a file.
To manage the video, an app is required. What app to get is often made easier by the companies that supply a download QR code within their manuals or user interface. However, many do not and it may take some searching to find the correct app for the individual device.
Network Access
The CCTV device must be attached to a network. We took a detailed look at this in a previous post. The app will search the network for compatible devices and, upon detection, will be linked.
All apps will work differently, with many different function names, but in general, they will consist of:
- Device list
- Camera list
- Single and multiview preview of live footage
- Preview of recorded footage through a search function
- Saving images and videos from recorded footage
- Downloading files from the DVR
The two main areas that we will be concentrating on are the recording of playback video and then the downloading of files.
Understanding an App
Before we begin to capture some video, let us have a look at an app designed for the remote acquisition using a mobile device. The first thing required is the link between the app and the CCTV device. In this app, there are several methods including a handy QR code reader.
As the device was already set up for network access, as detailed in a previous post, it was quickly detected and added to the Device List.
Although it was named with the serial number, this could be easily changed to aid in identification by a user. Especially important when several devices were being connected.
A quick tap on the required device leads us to the camera preview.
There are various options here, including which live stream to view, the HD or SD stream. If the network is congested, viewing a HD stream may not be possible. However, the low-quality SD stream would allow real-time playback. For our purposes, we need to search for an incident or time period.
Identifying Recorded Video
The first hurdle is that the app required for this test DVR only allows you to search within the 24hr period you are in. It is not possible to search yesterday’s recorded footage. This is obviously a concern, as a user may accidentally believe that a problem has occurred and no data is available when there would be recorded footage on the device.
Putting that small issue aside, this app switches from SD preview to HD when you search previously recorded footage. There are some that do not, which results in the footage obtained being the sub-stream and not the main-stream.
When in playback mode, there is an easy scrub bar indicating the time to navigate. The challenge is that there is no text input. So, getting this to a specific point can be a little frustrating. As you can see, there are two icons under the video, for image and video, that allow the saving of a snapshot and a video file.
With snapshots, it does save the full frame size, which is great. Unfortunately though, with this app, the video must be playing to grab the snapshot. Therefore, it may not be exactly the image needed. You cannot take a snapshot whilst paused.
With video, it is slightly easier, and the video icon changes to a timer whilst the footage is playing and being recorded. What that file is and how it differs from other methods of acquisition will require testing, analysis and comparison. So far, we have managed to obtain some images, although not the best ones. We have also recorded some videos. Shortly, we will find them and see if we can extract them from the tablet.
Downloading Video
Although not always an easy option, and one that will require testing and data verification, remote acquisition using a mobile device can still be an option, especially if it is a backup file whilst further research and work is done to perform a native recovery from the DVR. With this app, there is a download option. But, as previously stated, it is unable to see any data outside of the 24hr period.
Selecting the files allows them to be downloaded to the mobile device’s internal memory or storage card. This, however, must be done carefully as there is an option to switch between the streams with the SD/HD option button. Select the wrong one and you will get a much lower-quality video, the sub-stream.
Exporting the Files
This is where things became a little interesting when using our test DVR and this app. As you can see, 3 video files are shown.
During the testing and preparation for this article, there were considerably more video files downloaded and recorded. So, where were the others? Playback of the three visible files within the app revealed several points:
- The data timestamp was visible. This was not present when using the DVR directly and not present when using network access.
The only other time that this data was viewable is through Amped FIVE, after the conversion engine cleaned the H264 data stream and extracted this important data timestamp. - The aspect ratio was not as the stored size. It was being adjusted automatically on playback.
- The file extension was .mp4. You may remember that DVR USB downloads were between .h264 and .avi, and the network acquisition was .h264.
- The files visible were only the recorded playback clips, not the downloaded files.
Let us come back to the “lost” downloaded files a bit later and look at how we remove the files from the device.
Export
Luckily, at the bottom of the file list is a share button. This has all the usual share options that are possible on that device, with linking to online storage providers supported. These make sharing very easy for a user to upload a video somewhere and then share a link with the police. But they must be very careful.
As we have discussed many times, and in particular in the challenges of public submission of video evidence post, most online storage and sharing platforms will change the data. Share to Google Drive, and it will change the images and the video unless specifically set to keep the original. Use a messaging platform like WhatsApp, and it will reduce the quality significantly. Use iCloud and share a link, it will be changed.
The movement of data, especially for evidential use, must be carefully controlled. Depending on the device and storage options, such as the presence of a micro SD card, the extraction of the data safely from the device could involve transfer to a computer.
We will look more at this later in the series when dealing with master and working copies. So, let us move on to our missing files.
Missing Files
Within the app data folder, deep in a directory tree on the mobile device, were the MP4 files.
They had the naming convention of the serial number of the device and also a comma in the filename that could cause some problems. They were unplayable on the tablet device used for this blog series. After removing them safely from the tablet, they were unable to be decoded on a PC but, analysis revealed that they did contain video data. An important component of the file, the MOOV Atom, was not present.
Components on an MP4 are known as Atoms, and each one either contains data or instructions on how to decode data. Consequently, they needed fixing. This problem is seen fairly regularly in network systems. It appears that the data is transmitted and stored, but the final stages of placing the data into a container do not get completed correctly. The fixing processes are beyond the scope of this article but, for these, we luckily had some working files from the same camera obtained during the playback and recording method. Using one of these files as a reference, it was possible to fix the broken files and get them all playable.
All the files analyzed, from both the recordings and the downloads, presented the correct size of 944×1080. Frames were compared using Frame Hashing in Amped FIVE and all matched. There were some slight timing control differences, but both reported the correct frame rates. Both also contained the data timestamps.
Before we summarize then, what about any differences between these files, and one obtained directly from the DVR?
Comparing Data
A file was extracted using the method described in this post and the frames and timing were compared to files recovered with the remote acquisition using a mobile device method. All matched! Using Frame Hashing and Video Mixer in Amped FIVE, it was proven that the timing data and the pixels were the same across all different methods.
Summary
Remote acquisition using a mobile device is fraught with challenges. It is easy to get wrong and for the wrong file to be selected. Apps often do not save the highest quality main-stream. We have seen several that save the video in the screen size of the app.
We often have files submitted to assist in recognition evidence where it would be impossible to complete any worthwhile restoration due to it being the preview-only sub-stream. Also, we receive many files that have been shared using consumer services, causing more degradation in the visual data and the complete loss of any native timing data. Finally, those files may be then handled poorly by inadequate Digital Evidence Management Systems.
As we have demonstrated, using a mobile device can be a valid acquisition method. However, there are often many hurdles to jump. Even after the rebuilding of downloaded files, testing and verification of the data had to be completed to prove that the data received was the same as on the DVR.
That was the key – testing and verification. Without that, the question would remain. Has the data changed since it was created? The integrity of digital data must be maintained, and we will continue looking at this in further posts.
Next time we will look at acquisition from a cloud-based service provider. Until then, have a great few weeks and stay safe.
