Before You Trust a Video, Read the Container¶
How binary-level container analysis can reveal structural inconsistencies, post-processing traces, and provenance questions before content analysis begins.
Rami Khashmel
Published June 2025 · Updated May 2026 for ContainerForensics v0.2.0
Every MP4 or MOV video file is two things at once.
The first is what you see — the video itself. Frames, motion, audio. The thing that plays when you press play.
The second is something most people never look at: a structured technical record embedded in the file that may preserve information about how it was created, processed, or modified. What device recorded it. What software touched it after recording. Whether the internal metadata is consistent. Whether the structure matches what the file claims to be.
That record is called the container. And it is readable — if you know where to look.
Container analysis does not tell you whether a video is true or false. It tells you whether the file structure is consistent with the story being told about the file.
What a Video Container Is¶
An MP4 file is not just a stream of video frames. It is a structured hierarchy of data blocks called boxes or atoms, each with a type code and a precise position in the file. The ftyp box declares what kind of file this is. The moov box contains all the metadata — track structure, timestamps, codec parameters, recording information. The mdat box holds the actual media data.
Recording devices and software often write container structures in recognisable patterns. An iPhone writes a specific structure. A dashcam writes a different one. An Android phone writes another. These patterns are documented in the ISO/IEC 14496-12 international standard — the specification that defines how MP4 files are structured.
When a video is re-encoded, edited, or synthetically generated, the container structure can deviate from those patterns in documented, detectable ways.
The atom hierarchy of an MP4 file read at the binary level. Every box has a type, a size, and a position. This structure encodes information about how the file was created and processed.
What Editing and Re-Encoding Can Leave Behind¶
When software processes a video file, it can leave traces in the container that the content itself does not show.
Encoder strings. FFmpeg commonly writes encoder/library strings such as Lavf60.16.100 into the metadata of files it processes. HandBrake writes its own string. Adobe Premiere writes its own. These strings sit in the binary structure of the file and identify what software last touched it. Many legitimate tools — WhatsApp, body-camera export software, evidence management systems, screen recorders — also write these strings without modifying the content. Their presence indicates post-processing. It does not, by itself, indicate manipulation.
Edit list boxes. The elst box records post-capture modification operations. An authentic, unedited recording typically has no edit list, or a single trivial one. Complex edit lists may indicate the video has been trimmed, reordered, or assembled from segments.
Timestamp inconsistencies. Every box that records a timestamp — the movie header, each track header, each media header — should tell a consistent story for an authentic recording. When those timestamps contradict each other, or contradict the stated recording device, that inconsistency is worth examining.
Container ordering anomalies. The position of structural boxes within the file follows patterns associated with specific devices and software. When a file's structural layout is inconsistent with the device it claims to come from, that inconsistency is documentable.
None of these are visible when you play the video. All of them are readable in the binary structure.
Why Container Analysis Comes Before Content Analysis¶
Most forensic analysis of disputed video focuses on content — what the video shows, whether it has been manipulated at the pixel level, whether compression artifacts suggest synthetic generation. That analysis is important.
But it is the second step, not the first.
The container tells you the history of the file before you examine a single frame. It answers questions that content analysis cannot answer:
- Was this file written by a camera, or by post-processing software?
- Has anything touched the container since original capture?
- Are the internal timestamps and structural parameters consistent with the device this file claims to come from?
A file whose container structure is inconsistent with authentic device capture represents a documented technical finding that may assist counsel, investigators, or examiners in deciding what further analysis is required — before any content-level examination begins.
Container structure analysis is the first step in a SWGDE-aligned forensic methodology. It establishes the provenance baseline that every subsequent analysis builds on.
Introducing ContainerForensics¶
ContainerForensics is an open-source forensic triage instrument that reads the binary container structure of MP4, MOV, MXF, and AVI files and produces a structured triage report.
It is not an authentication tool. It does not conclude that a video is fake. It identifies structural features that warrant further examination, documents each one with the specific technical value found and the published standard it is based on, and presents the findings in a format an examiner can include directly in a forensic report.
A triage finding is a prompt for further examination — not an authentication opinion.
The triage report opens with a TRIAGE RESULT count and a prominent disclaimer. Every finding is documented with severity, technical detail, and citation.
Example: A File That Played Normally but Had Structural Red Flags¶
One of the test files run against ContainerForensics during development was a video submitted as authentic dashcam footage. It played back cleanly. Nothing in the content raised a visual alarm.
The container told a different story.
At binary offset 1,563 in the file, the tool found: Lavf60.16.100. FFmpeg's encoder string, written into the metadata when FFmpeg processed the file. The device signature database matched the file's structural profile to the FFmpeg Re-encoded pattern, clearly ahead of any authentic dashcam profile. The timestamps across all three header boxes showed zero — no device clock had been set, which is a structural characteristic worth noting in combination with the other findings.
The triage report documented each of these findings with its specific technical value, the standard it deviates from, and what innocent explanations exist alongside the concerning ones.
The file was later confirmed to be AI-generated. Container analysis did not prove that by itself — but it correctly identified structural features inconsistent with ordinary device capture and consistent with post-processing or synthetic generation. It flagged the file for priority forensic examination before a single frame was analysed.
The M5 finding — post-processing software signature identified. The encoder string is documented verbatim, cited to Hall (2015) and ISO/IEC 14496-12, and given forensic significance that leads with innocent explanations.
What the Report Produces¶
Every ContainerForensics report includes:
A SHA-256 hash of the input file computed before any analysis — the chain of custody baseline. The tool opens the file read-only and never modifies it.
A TRIAGE RESULT summary showing how many structural features were identified and at what severity — NOTE (worth documenting), FLAG (warrants examination), or SIGNIFICANT (recommended for priority forensic review).
Detailed findings for each check performed, with the specific technical value observed, the standard or research it is based on, and the forensic significance — including innocent explanations where they exist.
A device-class profile comparison against 18 documented device and software profiles — iPhone, Android, dashcam, GoPro, DJI, OBS Studio, WhatsApp, Axon body camera, and others.
An atom structure map — a visual diagram of the complete box hierarchy, colour-coded by finding severity.
The exact tool version, Python version, all dependency versions, and the device signature database version are recorded in every report. The analysis is fully reproducible.
Every report records the SHA-256 hash of the input file, the exact tool and dependency versions, and confirms the input was not modified.
Who This Helps¶
SIU investigators dealing with disputed dashcam footage, questionable injury videos, or manipulated surveillance clips. Container triage can support early investigative review before a matter reaches expert-report or litigation stages.
Civil litigators handling defamation, fraud, employment, or family law matters where digital media provenance is in dispute. Structural findings raise evidentiary questions before content analysis is even required.
Criminal defence lawyers examining prosecution media for structural inconsistencies. Container analysis provides the first layer of a structured examination of whether evidence is consistent with authentic capture.
Forensic practitioners looking for a SWGDE-aligned, open-source triage instrument as the first step in a multimedia forensic methodology.
Important Scope Limitation¶
ContainerForensics establishes provenance at the structural level only. It does not authenticate content. A clean triage result — no structural features identified — is not a finding of authenticity. It means the file presented no structural indicators on the checks performed.
Absence of structural features does not rule out content manipulation. Presence of structural features does not prove it.
Container analysis is the first step in a methodology, not the final word on a file. What it finds — or does not find — informs what comes next.
Availability¶
ContainerForensics is free, open-source, and available now.
GitHub: github.com/ramikhashmel/ContainerForensics
Full usage guide — including how to cite the tool in a forensic report — is at USAGE.md.
ContainerForensics is part of RK Tools — open-source forensic instrumentation for the multimedia authentication community. Questions and contributions welcome via GitHub.