Epstein Prison Video Analysis

An analysis of the DOJ “RAW” Epstein prison video released by de DOJ

Video source

The video is available for download in the following URLs:

• https://www.justice.gov/video-files/video1.mp4
• https://www.justice.gov/video-files/video2.mp4

URLs provided by Wired: https://www.wired.com/story/metadata-shows-the-dojs-raw-jeffrey-epstein-prison-video-was-likely-modified/

Extracting the video metadata and information

The tools and signatures

There are many command line interface tools to extract information and metadata from media files, some come by default in each operating system, some have to be installed, in my case, I use Homebrew to install exiftool, mediainfo and ffmpeg.

To check the file signature in macOS, we use the following commands:

$ sha256 video1.mp4
> SHA256 (video1.mp4) = ab4105a6da3b053f217e432987ac63cd02ab8ffc9ee99532deff922491d79956

$ sha256 video2.mp4
> SHA256 (video2.mp4) = 8013ddc714ab29a6bff99af69184696e86dfacb1d27a4ac93ec63141cfba9321

File signatures allow us to make sure we are dealing with the same files among other users.

Exctacting the metadata

The exiftool command allow us to extract the metadata of a file to a text file:

exiftool -a -u -g1 video1.mp4 > exiftool_video1.txt
exiftool -a -u -g1 video2.mp4 > exiftool_video2.txt

video1.mp4

Creator Tool

From the metadata extracted from video1.mp4, the Creator Tool property shows the software that created or last edited the video file. In this case, it was Adobe Media Encoder 2024 running on Windows:

Property	Value
Creator Tool	Adobe Adobe Media Encoder 2024.0 (Windows)

History Action

The History Action tag shows the file was saved multiple times and created once, this shows us that this is not the raw original file but it was edited multiple times:

Property	Value
History Action	saved, created, saved, saved, saved

History When

The History When property shows Timestamps when each edit happened (May 23, 2025, with times in Eastern Time):

Property	Value
History When	2025:05:23 20:16:48-04:00, 2025:05:23 16:48:57-04:00, 2025:05:23 20:16:48-04:00, 2025:05:23 20:16:48-04:00, 2025:05:23 20:16:48-04:00

There’s an interesting pattern here, breaking Down the Timeline:

• 2025:05:23 16:48:57-04:00 – This is 4:48 PM Eastern Time.
• 2025:05:23 20:16:48-04:00 – This is 8:16 PM Eastern Time (appears 4 times)

This pattern suggests that the person likely worked on this video project in two distinct sessions:

• Session 1 (4:48 PM): They started the project, probably importing the source videos and doing initial work.
• Session 2 (8:16 PM): They came back about 3.5 hours later and did multiple saves/edits.

The fact that 8:16:48 PM appears exactly 4 times suggests one of these scenarios:

• Batch processing: Adobe Media Encoder processed multiple elements simultaneously at that exact moment.
• Final export session: They made several quick adjustments and saves in rapid succession during the final export.
• Metadata updates: Some of these “saves” might just be metadata changes (like adding titles, descriptions, or export settings) rather than actual video edits.

This looks like someone who:

• Started editing around 4:48 PM (maybe just importing files).
• Took a break (dinner? other work?).
• Came back at 8:16 PM for the final push – making multiple saves/adjustments to get the video just right before exporting.

It’s a very typical editing workflow – the initial setup, then the focused final session where you make several small tweaks and saves before you’re satisfied with the result.

Ingredients File Path

The Ingredients File Path property shows the source files that were used to create this final video, it appears that two original video files were used even if they appear repeated, 2025-05-22 21-12-48.mp4 (possibly recorded on May 22nd at 9:12 PM) and 2025-05-22 16-35-21.mp4 (posibly recorded on May 22nd at 4:35 PM):

Property	Value
Ingredients File Path	2025-05-22 21-12-48.mp4, 2025-05-22 21-12-48.mp4, 2025-05-22 16-35-21.mp4, 2025-05-22 16-35-21.mp4

The duplication suggests the editor used multiple segments from each source video:

• Video A (9:12 PM file): Two different time chunks were extracted
• Video B (4:35 PM file): Two different time chunks were extracted

This editing pattern suggests like someone who:

• Recorded throughout the day – capturing footage at 4:35 PM and later at 9:12 PM.
• Cherry-picked the best moments – instead of using entire videos, they selected specific segments from each.
• Created a highlight reel – combining 4 different clips (2 from each source) into one final video.

Breaking Down the Creator Atom Data

Property	Value
Windows Atom Extension	.prproj
Windows Atom Invocation Flags	/L
Windows Atom Unc Project Path	C:\Users\MJCOLE~1\AppData\Local\Temp\mcc_4.prproj
Mac Atom Application Code	1347449455
Mac Atom Invocation Apple Event	1129468018

The Windows Atom Extension property tells us the video came from an Adobe Premiere Pro project file (.prproj). So the person didn’t just use Media Encoder directly – they created a full editing project in Premiere Pro first.

The Windows Atom Unc Project Path shows the exact location where the Premiere project was stored: C:\Users\MJCOLE~1\AppData\Local\Temp\mcc_4.prproj.

What This Path Reveals

• User: Someone with username starting with “MJCOLE” (probably M.J. Cole or similar).
• Temp folder: The project was saved in a temporary directory, not a regular user folder.
• File name: mcc_4.prproj suggests this might be the 4th version/iteration of a project with “mcc” in the name.

Possible workflow

• Premiere Pro: Person edited the project in Adobe Premiere Pro (combining those source videos we saw earlier).
• Export: They used Adobe Media Encoder to export the final video from their Premiere project.
• Temporary workspace: They were working in a temp directory, possibly for quick/experimental work.

video2.mp4

Creator Tool

From the metadata extracted from video2.mp4, the Creator Tool property shows the software that created or last edited the video file. In this case, it was Adobe Media Encoder 2024 running on Windows:

Property	Value
Creator Tool	Adobe Adobe Media Encoder 2024.0 (Windows)

History Action

The History Action tag shows the file was saved multiple times and created once, this shows us that this is not the raw original file but it was edited multiple times:

Property	Value
History Action	saved, created, saved, saved, saved

History When

The History When property shows Timestamps when each edit happened (May 24, 2025, with times in Eastern Time):

Property	Value
History When	2025:05:24 16:21:37-04:00, 2025:05:24 10:21:21-04:00, 2025:05:24 16:21:37-04:00, 2025:05:24 16:21:37-04:00, 2025:05:24 16:21:37-04:00

Breaking Down the Timeline:

• 2025:05:24 10:21:21-04:00 – This is 10:21 AM Eastern Time.
• 2025:05:24 16:21:37-04:00 – This is 4:21 PM Eastern Time (appears 4 times)

This pattern suggests that the person likely worked on this video project in two distinct sessions:

• Session 1 (10:21 AM): They started the project, probably importing the source videos and doing initial work.
• Session 2 (4:21 PM): They came back about 6 hours later and did multiple saves/edits.

The fact that 4:21:37 PM appears exactly 4 times suggests one of these scenarios:

• Batch processing: Adobe Media Encoder processed multiple elements simultaneously at that exact moment.
• Final export session: They made several quick adjustments and saves in rapid succession during the final export.
• Metadata updates: Some of these “saves” might just be metadata changes (like adding titles, descriptions, or export settings) rather than actual video edits.

This looks like someone who:

• Started editing around 10:21 AM (maybe just importing files).
• Took a significant break.
• Came back at 4:21 PM for the final push – making multiple saves/adjustments to get the video just right before exporting.

Ingredients File Path

The Ingredients File Path property shows the source files that were used to create this final video, with some interesting differences from the previous file:

Property	Value
Ingredients File Path	2025-05-22 21-12-48.mp4, 2025-05-22 16-35-21.mp4, 2025-05-22 16-35-21.mp4, zoomed in, zoomed in

This shows:

• 2025-05-22 21-12-48.mp4 (recorded on May 22nd at 9:12 PM) – appears once
• 2025-05-22 16-35-21.mp4 (recorded on May 22nd at 4:35 PM) – appears twice
• “zoomed in” – appears twice as placeholder text

The appearance of “zoomed in” suggests the editor applied zoom effects or transformations to some clips, and Adobe’s metadata system recorded these as separate “ingredients” even though they’re effects applied to existing footage rather than new source files.

This editing pattern suggests someone who:

• Used the same source footage from May 22nd (both the 4:35 PM and 9:12 PM recordings).
• Applied zoom effects to enhance certain segments.
• Created a more visually dynamic version by combining regular footage with zoomed-in portions.
• Focused more heavily on the 4:35 PM footage (used twice) compared to the 9:12 PM footage (used once).

Breaking Down the Creator Atom Data

Property	Value
Windows Atom Extension	.prproj
Windows Atom Invocation Flags	/L
Windows Atom Unc Project Path	C:\Users\MJCOLE~1\AppData\Local\Temp\mcc_5.prproj
Mac Atom Application Code	1347449455
Mac Atom Invocation Apple Event	1129468018

The Windows Atom Extension property tells us the video came from an Adobe Premiere Pro project file (.prproj). So the person didn’t just use Media Encoder directly – they created a full editing project in Premiere Pro first.

The Windows Atom Unc Project Path shows the exact location where the Premiere project was stored: C:\Users\MJCOLE~1\AppData\Local\Temp\mcc_5.prproj.

What This Path Reveals

• User: Same user as the previous file – someone with username starting with “MJCOLE” (probably M.J. Cole or similar).
• Temp folder: The project was saved in a temporary directory, not a regular user folder.
• File name: mcc_5.prproj suggests this is the 5th version/iteration of a project with “mcc” in the name, indicating this is a follow-up or revision to the previous mcc_4.prproj file.

Possible workflow

• Premiere Pro: Person edited the project in Adobe Premiere Pro, reusing the same source videos from the previous project but with different editing choices.
• Export: They used Adobe Media Encoder to export the final video from their Premiere project.
• Temporary workspace: They were working in a temp directory, possibly for quick/experimental work.
• Iterative process: This appears to be version 5 of an ongoing project series, suggesting they’re refining their approach across multiple versions.

Other CLI tools

To exctract other information from the files we can use mediainfo and ffprobe, but there isn’t something relevant there:

mediainfo --Full video1.mp4 > mediainfo_video1.txt
mediainfo --Full video2.mp4 > mediainfo_video2.txt

ffprobe -v quiet -print_format json -show_format -show_streams video1.mp4 > ffprobe_video1.json
ffprobe -v quiet -print_format json -show_format -show_streams video2.mp4 > ffprobe_video2.json

Visual Video Analysis

• Upscaling
• Asymmetrical Pillarboxing and Cropping
• Timecode drifts
• Chapter Mark in video1.mp4 at 04;18;02;23.

Upscaling

The video1.mp4 shows timecode and information in the upper left, lower left and lower right corners, based on the pixel size of those texts and the pixelation of the video, it appears that the video is upscaled or upsampled from a lower resolution, it is possible that the original footage resolution could be 640x360px instead of 1920x1080px with the pillarboxing present, which doesn’t belong to that aspect ratio.

Asymmetrical Pillarboxing

The video1.mp4 shows asymetrical pillarboxing, the left black pillar is 196px wide while the right pillar is 155px wide, this is atypical, if a user drags a video with an aspect ratio of 4:2 (from an old CCTV) to a 16:9 Adobe Premiere timeline, the software automatically centers the video, showing a symetrical pillarboxing.

This suggest that either the video position was modified, maybe to zoom into an area, or that the video is cropped, and the cropped pixels in the upper left texts suggest that.

Timecode drifts

The video1.mp4 shows a timecode in the lower left corner, at the first frame it reads 8/9/2019 7:40:00 PM, at frame 23 it changes to 7:40:01 PM, and 30 frames latter it shows 7:40:02 PM, from that fact and from the exiftool metadata extracted on the property Start Timecode Time Format, we can deduce the vide uses a frame rate of 29.97 fps (drop) and that the video timecode at the begining starts at 19:40:00;07.

NLE editors like DaVinci Resolve provide a way to visualy sync the timecode with the editor, so I created a project with 29.97fps drop frame timecode (as the metadata suggested), and set both, the clip and timeline, to start at 19:40:00;07.

When the visual timecode shows 11:58:00 frame 0 (which can be interpreted as 23:58:00:00) DaVinci Resolves timeline show a timecode of 23:55:25:12 with drop frame option enabled, and 23:55:10:02 with drop frame disabled, so we have a time drift of around 3 minutes:

Frame Rate	Visual Timecode	Actual Timecode	Difference
29.97 Drop Frame	23:58:00:00	23:55:25:12	-00:02:48:02
29.97 Normal	23:58:00:00	23:55:10:02	-00:03:03:11

I tried other framerate configurations in the timeline and clip without getting to match both the timeline and clip timecode, I finally used the Rate Stretch Tool in Adobe Premiere to finaly fix the timecode drift, it is around 98.9% but the floating point is being rounded by the GUI.

I would like to apply Hanlon’s razor rule of thumb: “Never attribute to malice that which is adequately explained by stupidity”, but the time shift isn’t justified by just mere incompetence, it appears deliberated and unjustified.

Clips mismatch

Based on the original video timecode from video1.mp4, from the the frame 04;16;23;11 to 04;16;23;12 (the next frame), there is a evident visual mismatch:

The visual timecode shows a jump in time of 00:01:01:13, as user of various CCTVs solutions, I know that consumer level Digital Video Recorders (DVR) or Network Video Recorders (NVR) in CCTV systems never skips a second, even cheap Chinese DVRs here in Guatemala.

The video1.mp4 timecodes in relation to visual timecodes:

Video timecode	Visual timecode
04;16;23;11	23:58:58;25
04;16;23;12	00:00:00;10

Visual artifacts

In addition to the misalignment and asymetric pillarboxing and the cropping of the upper-left corner texts, the video1.mp4 shows a sharpening filter applied, the video2.mp4 which presents the same content, shows an extreme sharpening filter, and both shows macroblocking, a type of video artifact characterized by the appearance of large, block-shaped artifacts in compressed video frames, often due to high compression rates, transmission errors, or generational degradation, it suggest the video has undergone multiple rounds of compression.

Again, I would like to apply Hanlon’s razor rule of thumb, but we are talking about of a high level case handled by the best US agencies.

Points of interest

The video1.mp4 shows come activity in the following timestamps:

• 00:06:43:04 – Point 1
• 00:16:26:00 – Point 2
• 00:35:46:26 – Point 3
• 01:26:37:18 – Point 4
• 01:30:58:01 – Point 5
• 01:42:13:23 – Point 6
• 04:16:23:11 – Point 7 – time jump
• 04:17:57:18 – Point 8
• 04:22:06:10 – Point 9
• 07:29:28:16 – Point 10
• 07:31:42:26 – Point 11
• 07:57:16:21 – Point 12
• 08:05:50:24 – Point 13
• 08:18:59:13 – Point 14
• 08:25:12:27 – Point 15
• 09:40:18:12 – Point 16
• 09:42:31:10 – Point 17
• 09:51:16:20 – Point 18
• 10:01:15:02 – Point 19

My conclusion

I cannot categorize this as a “doctored video” because we don’t have an original video to compare it with, the metadata suggest it is the product of copilation of other clips, the file name convention of the files in the metadata (2025-05-22 21-12-48.mp4 and 2025-05-22 16-35-21.mp4), suggest they were recorded or re-encoded on May 22, 2025. The name convention YYYY-MM-DD HH-MM-SS.mp4 suggest the file came from a DVRs, but I can’t pinpoint which brand use that name convention.

The asimetrical pillarboxing, the 00:01:01:13 missing footage, the timecode drifts, etc. shows a monumental incompetence by the people in charge of delivering the video, and one can especulate this is deliberated.

By “raw” video from a DVR, the DOJ should have made the videos available to the public directly extracted from the DVR without any re-compression, adjustment or manipulation, even if that required multiple downloads due to the limitations of certain file systems, or the use of specialized software due to non-standard video codecs.

Below is a table summarizing the file naming conventions for exported video files from popular CCTV DVR/NVR brands, focusing on whether they use or support the YYYY-MM-DD HH-MM-SS.mp4 format or similar timestamp-based conventions. The information is based on common practices, user reports, and available documentation for brands like Hikvision, Dahua, Swann, and Lorex, as well as general trends in the CCTV industry.

Brand	Default File Naming Convention	Supports YYYY-MM-DD HH-MM-SS.mp4?	Notes
Hikvision	YYYYMMDD_HHMMSS.mp4 (e.g., 20250522_163521.mp4)	Yes (configurable)	Often uses underscores by default but can be configured to use hyphens. Timestamp-based naming is standard for exports via NVR/DVR interfaces or software like VsPlayer.
Dahua	YYYY-MM-DD_HH-MM-SS.mp4 or YYYYMMDD_HHMMSS.mp4	Yes (default or configurable)	Frequently uses hyphenated or underscore formats. Scripts for downloading from Dahua NVRs validate YYYY-MM-DD HH:MM:SS for start/end times, indicating support for this format.
Swann	YYYY-MM-DD_HH-MM-SS.mp4 or YYYYMMDD_HHMMSS.mp4	Yes (configurable)	Timestamp-based naming is common, with hyphens or underscores depending on model and export settings. Often user-configurable via export menus.
Lorex	YYYY-MM-DD_HH-MM-SS.mp4 or similar	Yes (default or configurable)	As a Dahua subsidiary, Lorex follows similar naming conventions, often using hyphens or underscores in timestamped MP4 exports.
Generic/OEM	Varies (e.g., YYYY-MM-DD HH-MM-SS.mp4, Clip_YYYYMMDD_HHMMSS.mp4)	Often supported	Many budget or OEM DVRs use timestamp-based naming, with hyphens or underscores, depending on firmware or export software. User customization is common.

Notes on File Naming Conventions

• Timestamp Format: The YYYY-MM-DD HH-MM-SS.mp4 format (e.g., 2025-05-22 16-35-21.mp4) is a widely adopted standard in CCTV systems for its clarity and chronological sorting. It typically represents the start time of the recorded clip.
• Variations: Some DVRs use underscores (_) instead of hyphens (-) or omit spaces (e.g., YYYYMMDD_HHMMSS.mp4). Additional prefixes like CH01 (channel number) or Clip may be included, depending on the system.
• Configurability: Most modern DVRs/NVRs from brands like Hikvision, Dahua, Swann, and Lorex allow users to customize file naming conventions through the device’s export settings or software, enabling the exact YYYY-MM-DD HH-MM-SS.mp4 format if desired.
• Export Method: The naming convention may depend on whether the video is exported via USB, downloaded through a web interface, or processed with third-party software (e.g., VsPlayer for Hikvision, SmartPSS for Dahua). Tools like ExifTool or Flash Renamer can also rename files to match this format post-export.
• Metadata: The timestamp in the file name typically reflects the recording’s start time, often embedded in the video’s EXIF metadata, which can be used for renaming or cataloging.