Where Is the Rest of the Video?

Video investigators often receive files with little or no information surrounding the source, acquisition or handling. The files are often created by people with little knowledge of the legal requirements of data type and continuity. These issues, and quite a few others, all impact on the initial investigation as discrepancies can cause major problems further along in a case.

Let’s look at this file for example…

All images with sensitive data have been redacted.

Upon viewing in Windows, the thumbnail and extension are shown, and hovering over the thumbnail reveals further information.

I am being told that it’s a Windows Media Video, it’s just under 4Gb and has a length of just under 27hrs.

The CCTV request for footage did detail a time duration of 27hrs so it all looks good so far.

As the title of this blog post is, “Where Is the Rest of the Video?”, you just know that things are going to go wrong!

It’s now time to review this footage so let’s drop it into an Amped FIVE project.

Upon loading, we can see a problem – the video only lasts 11hrs and 53mins.

Playback using the default Video Engine (FFMS) is fine, with no problems in frame by frame movement, searching or scrubbing.

In the Tools, under the Basic File Information, we also see a duration of 11+ hours.

Before digging deeper, I usually like to test other video engines.

Inside Amped FIVE we may have different file information, with different Video Engines and different File Info tools. It happens quite a few times that users contact us because they are seeing different information within different tools in FIVE. This may be a problem with your investigation, but it’s actually an asset. Problematic videos often give different results with different industry-accepted tools. This is the key to forensics: study, experiment and validate! So you thought video was easy?

Having the ability to decode a video through different engines within the same application is a huge time saver and gives users a much easier way to test and compare.

Heading to Microsoft’s DirectShow first, as this should, in theory, be able to play a Windows media file without any problems, I see more interesting issues.

The video plays back very fast, with a duration of 48mins and 36secs! It also would not scrub properly.

(Scrubbing: In digital video editing, scrubbing is an interaction in which a user drags a cursor or playhead across a segment of a video clip to see it. Scrubbing is a convenient way to quickly navigate a video file. The term apparently comes from the early days of the recording industry and refers to the process of physically moving tape reels to locate a specific point in a video or audio track; this gave the engineer the impression that the tape was being scrubbed, or cleaned – Taken from Wikipedia on Audio Scrubbing.)

With FFmpeg, it scrubbed OK and played at the correct speed, but it presented a duration of 26:59:59.800.

Scrubbing the file through revealed that it paused at 11:53:43 – the same as the full duration given by FFMS.

So….where are we at?

The duration requested for the recovery was 27hrs..
Windows says 27hrs (well, just under).
FFmpeg says 27hrs.
DirectShow plays back very fast which would explain the 48mins duration.

FFMS displays 11:53:43

It’s time to have a look at the Advanced File Info.

As we can see, the summary gives us 27hrs again.

Just as we could decode and review the file with different engines, we can also utilize the different analysis programs built into FIVE. Again, it makes things so much easier to compare and identify issues.

Looking at MediaInfo, this brings up some new information.

It also offers 27hrs as a duration but, in addition to that, it reports 30 FPS. This would be the same as the speed of playback presented using DirectShow as a video engine.

Let us review the next tab, ffprobe….

The duration here is reported in seconds and equates to just shy of 27hrs!

Next up, we have ExifTool, an often overlooked metadata tool when it comes to CCTV.

What’s this?

The send duration is the time we have, but the video presents a duration much longer and is the time we expected.

Before we move on, it’s time to investigate these attributes in the ASF format.

https://docs.microsoft.com/en-us/windows/win32/medfound/mf-pd-asf-fileproperties-send-duration-attribute

Within this document, it says, “….Specifies the time, in 100-nanosecond units, needed to send an Advanced Systems Format (ASF) file. A packet’s send time is the time when the packet should be delivered over the network.”

At this point, I begin to form some theories….

  • It’s possibly a transcode based on the WMV V8 encoding.
  • The file was being written as a 27hr file and it reached the 4Gb file size limit of the writing destination. This was 11hrs and 53mins into the footage.
  • The Container was written to hold the data requested, so that has the expected duration, not the real one.

In order to test some of these theories and identify exactly what video is inside the container, we can simply use ConvertDVR within the Video Loader filter settings to write the video into a new WMV container.

We must Copy Stream only…

We must use the same container format….

It is best practice to disable stripping if it is simply performing a reformat.

This results in a file with the same frame count and the duration of 11+hrs with no errors.

Time for a recap!

The investigation receives a file after requesting 27hrs of footage. 

The file reports 27hrs of footage but FIVE only displays 11+hrs.

Where is the rest? Well, it was never sent, or may have never been created. Why? We may never know, but the file only contains the 11+hrs.

I felt it important to share this file with you as it highlights several key points.

  • Received files must be checked properly immediately after being received. CCTV systems overwrite. Any delays in identifying errors can cause problems as the evidence you thought you had would probably now be deleted.  
  • Use the tools available to you. Having all the Metadata tools in one place is a huge benefit. Review your files and note any discrepancies or differences.
  • Remember to use video engines. Observing how each one copes with the video can help you identify issues and compare those issues with the reported metadata.
  • Use ConvertDVR to re-format a video or transcode if necessary, to review timing and frame counts.
  • Containers can have one set of information and can often override the information given by the stream.

I hope you have enjoyed this little walkthrough of a file analysis to try and answer the question of duration problems.

Stay safe out there!