For solicitors, experts and anyone else checking converted footage — including on the other side
Every Veriframe conversion is issued with a certificate recording what was received, what was produced, and digests of the coded video either side of the conversion. This page sets out how to recompute those digests yourself, so the certificate can be checked rather than believed.
If you are disclosing footage, relying on it, or testing what the other side has disclosed, that is the point of it: the method is ordinary, published, and needs no cooperation from us. Nothing here asks anyone to take Veriframe's word.
Conversion is a container change, not a re-encode: the recorded H.264 is copied out of the recorder's proprietary container and written into MP4 without being decoded. The certificate demonstrates this by digesting the coded picture data on both sides and printing both values.
Because they must differ, and would tell you nothing. The original is a proprietary container and the delivered file is MP4, so their bytes cannot match even when every picture is identical.
Hashing the raw video streams fails for the same class of reason. MP4 stores each NAL unit with a length prefix while an elementary stream uses start codes, and a container change legitimately re-emits parameter sets ahead of each keyframe. Measured on a real 126 MB job, the two streams differed by 36 KB without a single picture being altered.
The digest therefore covers only the NAL units that carry pictures — H.264 types 1 and 5 — concatenated in order, with framing discarded. That measures the video and nothing else, which is why it survives the container change and why a single altered frame breaks it.
The digest is defined by a rule, not by our software. Anyone can apply it, with ordinary tools, and nothing below is specific to Veriframe:
That rule is the specification. Any correct implementation of it produces the value printed on the certificate, which is what makes the check independent of us — an expert instructed by either side can write their own and does not have to trust ours.
The first step is one ffmpeg command:
ffmpeg -v error -i cam01.mp4 -map 0:v:0 -c copy -f h264 - > cam01.264
Provided so nobody has to write one to check a certificate in a hurry. It is deliberately plain and does no error handling; treat it as a demonstration of the rule rather than a tool.
import hashlib, re, sys
d = open(sys.argv[1], 'rb').read()
starts = [m.end() for m in re.finditer(b'\x00\x00\x01', d)]
h, n = hashlib.sha256(), 0
for i, a in enumerate(starts):
b = starts[i + 1] - 3 if i + 1 < len(starts) else len(d)
while b > a and d[b - 1] == 0:
b -= 1
if b > a and (d[a] & 31) in (1, 5):
h.update(d[a:b])
n += 1
print(n, 'pictures', h.hexdigest())
Run it as python3 verify.py cam01.264.
The picture count and digest should equal the values shown for that camera on the certificate. If you also hold the original export, applying the same rule to its extracted stream produces the source digest.
The file digest is a different thing. Each camera also carries a SHA-256 of the whole MP4. That one covers container structure and timing tables as well as video, and exists so a recipient can confirm the file they hold is the file that was produced. It is not expected to match the picture digest, and cannot.
The certificate attests to the fidelity of the conversion only. It says nothing about how the original was recorded, whether the recorder's clock was correct, or whether the export is complete as taken from the recorder.
Where an export begins part-way through a recorded sequence, its opening frames reference a keyframe that was never exported. Nothing can decode them, and they are not carried into the output; where that applies the certificate states it and gives the number of frames affected.
If you are assessing a Veriframe certificate and something does not reconcile, please get in touch — we would rather resolve it than have it raised at a hearing. enquiries@veriframe.co.uk