Forensic Video Workflow with Amped FIVE – Part Two: Analysis of Video Evidence

Reading time: 6 min

Now, in the second episode, the analysis of video evidence: turn messy timestamps and inconsistent metadata into a timeline. Inside FIVE, we reconcile timings, inspect structure, and prepare clean clips that tell one story: the suspect’s movements, minute by minute.

Welcome back to this series in which we’re following a full Amped FIVE workflow as part of a case. If you missed part one, then be sure to check that out. To briefly summarise, I will be working on various types of digital media evidence to build a forensic video case from the initial steps to file analysis and through to presentation in response to a murder investigation. We have body worn video, dashcam footage, drone footage, mobile phone footage, CCTV footage and action camera footage.

We’ve already created our FIVE project and hashed our files, so we can verify them throughout if required. We’ve made sure to perform an initial review of the files so we can strategize any particular concerns or techniques.

Now, it’s time for the analysis step. Within this post, I’ll be looking at the files in depth and I’ll be showing you the following workflows:

• File Analysis
• Editing, Adjustments and Correcting Issues

Let’s dive right in, shall we?

File Analysis

As part of my file analysis, I’m first going to focus on timing since we don’t have reliable timestamps for a number of these video files.

Let’s start with the file “MOVI0002.mp4”, which is the covert police body worn video.

I’m already aware of the strange colour issue at the start of this file. This could be down to poor handling of light and exposure by the device (since the colours seem to stabilise further on in the file). However, I’m not too concerned about this and I tend to try and avoid commenting on colour due to it being so subjective and prone to interference.

What I am concerned about is the massive timestamp inaccuracy and what other timings we have available to us within the metadata, since I’ll need to be able to explain the discrepancy here. The file has a pixel-embedded timestamp showing “2025/06/10”, but we know the arrest actually happened on the 11th, the day after! We absolutely need to work out why and explain this, maybe even allowing for the education of our front-line officers on how to ensure the date and time are accurate, if possible.

We’ll use Advanced File Info for this, so let’s take a look at some of the file timings:

… Wow. Ok, so there are a fair few issues here! The file creation date seems to make the most sense, since this would be the time the footage was downloaded from the camera following the arrest at 14:30 on 11th June. This timestamp includes the local time, which was an hour ahead of UTC at the time.

I’ve requested the device make and model for this type of covert camera and looked into how it works. I can see that the time and date are set via a text file stored on the SD card. This method of setting the time on the device seems to have caused all sorts of weird and wonderful oddities. There’s no dedicated playback software supplied with this device that could correctly (or incorrectly…) decode any other timestamps either, so this is all we have.

This means I can’t fully rely upon a lot of the timing data from this file. However, I can explain it and verify the time and date of this capture with the police radio records and officer statements if required.

Luckily, the drone footage contains EXIF CreateDate timestamps that match the times of the search for the suspect prior to the arrest:

As mentioned before, this drone footage includes a subtitle file with the flight data that we can use for presentation purposes later on.

So that’s our police generated footage looked at, now onto our witness-provided footage, starting with the dashcam video footage, “20151001_171451.MOV”.

It’s a classic story; the witness has a dashboard camera in their car and has used it for years, but they never thought to check or change the time and date. Now we have another timestamp we can’t rely on! We will once again have to rely on file creation times as opposed to encoded times. For this file, the creation time shows a local timestamp of 2025-06-11 15:53:46.796, which indicates when it was saved to the external drive.

Looking at the GOP Analysis tab within Advanced File Info, we see something interesting:

The GOP seems to start with two B frames and finish with a partial GOP. A GOP should start with an I frame, so seeing this at the start of the file is indicative of a previous GOP no longer in this file. Perhaps, this is down to stream clipping and the way the files are written to the SD card by this particular camera. I have also seen this behavior before with body worn video footage, too.

In this case, my dashcam footage shows the suspect fleeing the scene and will be used for continuity and story building. However, if I were to use this for speed estimation, I would certainly consider the frame analysis, timing, and GOP information from this file. So it’s worth bearing this sort of analysis in mind and being meticulous!

In terms of other timings, the CCTV from the scene (the apartment building) shows a CreateDate of “2025:06:11 – 10:20:51” which matches the time and date provided by the pathologist. We can’t rely on any of the timing from the GoPro camera, nor the mobile phone footage, since this has been stripped of metadata after being sent via WhatsApp. The clue is in the file name: “WhatsApp Video 2025-06-11 at 13.46.41_bc958cf2.mp4”!

This is why we should always try and recover the original files where possible, as we risk losing valuable file data when using cloud assets or social media images or videos.

I’ve also run Frame Hash from within Advanced File Info over each file to check for duplicate frames at this stage, which demonstrates there aren’t any in this case.

Editing, Adjustments and Correcting Issues

Now I will perform any edits or adjustments that may be necessary to help with presentation purposes further down the line. First, I’m going to use Range Selector to clip the portions of the video to where I want them. This will show only the suspect moving from the scene to the weapon deposition site and finally being caught.

You can see below a snapshot of the file “VID_20250611_062051_00_021.mp4”, which is from the apartment complex. I’ve now added a timestamp using Add Timestamp, based on the file’s timing information from my earlier file analysis.

I was able to help verify that the timestamp, taken from the file metadata, appeared to be correct by using “Add Text” to show the “PTSTime” and “PTSDuration” macros and checking this whilst seeking through the file frame by frame and using PTS-Based Playback. This is a handy trick for comparing timings during playback and identifying gaps or motion detection.

So I’ve now selected all the portions of footage I’ll require for the next step of the case. If I needed to, I’d also perform any enhancements and adjustments at this stage. However,  in this instance, this isn’t required.

Because I want to eventually use Timeline to present my footage, I need to use Convert Frame Rate to make sure all my files have the same frame rate. I’m going to be preserving my original files alongside my presentation copies and will make it clear what changes to the files have been made. In this instance, my files range from 22fps all the way to 60fps (with some variability).  I’d rather duplicate frames than lose any, so we’ll select 60fps as our converted frame rate.

Final Note

My files are now analysed and prepared. The next stage of my workflow will be documenting my presentation tasks, which I’ll be discussing in the next and final post of this series. So I’ll see you in the final chapter of this investigation!