C2PA BMFF hash exclusions: reviewing MP4 video integrity

Preserve the MP4 copy and the validator output

Save the exact MP4 file before opening it in a validator. Record where it came from, the download time, filename, size, and a file identifier. If a platform supplies an original and several converted copies, give each copy its own identifier. C2PA validation applies to the bytes in the copy being checked; a result from one copy should not be transferred to another. This evidence log is an operational recommendation from this article, not a reporting format required by C2PA.

Use a validator that supports the current c2pa.hash.bmff.v3 assertion and save its complete output, including the tool name and version. C2PA 2.2 says validators ignore the older c2pa.hash.bmff assertion as though it were absent. A tool that reports only a badge can hide which assertion version it processed, which boxes it excluded, and which comparison failed.

Frame the review narrowly: determine whether the validator calculated the covered bytes of this MP4 and matched the value recorded in its BMFF-based hash assertion. Publisher identity, caption accuracy, and whether the depicted event happened remain separate questions.

Read the exclusion entry as a matching rule

The BMFF hash covers the file bytes except boxes, or parts of boxes, that match an entry in the exclusions array. A box excluded in full loses its header and contents from the hash input. A box included in full contributes its header and contents. When an entry excludes only a subset, each relative offset starts at the beginning of the box, including its header. Subset ranges must appear in increasing offset order and must not overlap.

Record the exact xpath shown by the tool. C2PA limits this field to full paths made from BMFF four-character box codes and optional positive occurrence indexes. It does not allow descendant syntax such as //. An entry may match no boxes or several boxes, so do not rewrite a path as though it always named one unique object.

Other fields can narrow a match. length must equal the complete box length, including its header. version applies to a FullBox. Three-byte flags can require an exact match or, when exact is false, require at least the specified bits. A data condition compares stated bytes at a relative offset. Copy these fields from the validation output rather than inferring them from a familiar MP4 layout.

Check offsets, Manifest boxes, and free space

For a root box not excluded in full, the v3 hash input includes its absolute file offset as an eight-byte big-endian integer followed by the box data minus exclusions. C2PA makes an exception for the stated Merkle-tree case. The absolute offset binds a covered root box to its position, so inserting C2PA boxes can change values stored elsewhere in an MP4 and can change the offsets used by the hash. The specification requires post-embed values, not the values from before the Manifest was inserted.

If the C2PA Manifest is embedded in the file, the box containing it must appear in the exclusion list. The specification also describes preserving layout with free boxes. Removing a non-root excluded box after Manifest creation requires a same-size free replacement. Space reserved for a later excluded box must itself be excluded. These rules prevent a layout change from invalidating covered offsets and boxes, but they do not make every excluded byte trustworthy.

Keep a compact table with the file identifier, assertion version, algorithm, hash status, each exclusion path, match conditions, subset offsets and lengths, and any reported free-box handling. Mark a field as unreported when the validator does not expose it.

Limit what a match or mismatch means

A successful comparison supports a specific observation: for this copy, the validator computed the included BMFF bytes under the recorded exclusions and obtained the asserted value. It does not show that excluded boxes are accurate, that the signing credential is trusted, that every Manifest assertion is true, or that the scene in the video is real. Those checks need their own records.

A mismatch or structural rejection means this copy did not pass the specified integrity check. It does not identify who changed the file, when a change happened, which visible frame was affected, or whether the depicted event was staged. Preserve the exact status code and compare another copy only after validating that copy independently.

For a separate probabilistic signal, submit the saved copy to the deepfake video detector. Keep that output outside the C2PA record and tie it to the exact file analyzed. Automated analysis can produce false positives on authentic video and false negatives on synthetic or altered video. A high-risk signal supports further review; a low-risk signal neither authenticates the MP4 nor repairs a C2PA mismatch.

Leave a reproducible integrity record

A second reviewer should be able to open the same file, use the documented validator version, find the same exclusion entries, and repeat the comparison. Store the file identifier, complete C2PA output, detector result if used, source-page checks, and human decision as separate evidence. Unknown fields stay unknown.

Verify real-world claims with the original publication, the account or organization presenting the video, the claimed time and place, and independent evidence about the event. BMFF hash validation is useful because it answers a byte-level integrity question without pretending to answer those broader questions.

Sources

• C2PA, "C2PA Technical Specification: BMFF-Based Hash": https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_bmff_based_hash