Skip to content
NovaVMS Manual

How NovaVMS preserves chain of custody for exported clips

How NovaVMS preserves chain of custody for exported clips

Law enforcement, insurance adjusters, and internal investigators need video they can trust. A clip emailed to a police officer is useless in court if the opposing side can argue the file was edited on the way. NovaVMS exports MP4 clips with embedded metadata and a hash of the original recorded segments so a reviewer can verify the file is what we produced (per D25).

What gets embedded

Every exported clip carries a metadata block inside the MP4 container. The block sits in a standard udta (user-data) atom so it survives being copied, uploaded, or re-attached to email without being stripped.

  • Camera ID — the UUID of the source camera.
  • Site — the site name and ID the camera belonged to at export time.
  • Time range — start and end timestamps in RFC 3339 UTC, matching the recording’s wall-clock times.
  • Org ID — the UUID of the organisation that produced the export.
  • Export initiated by — the user ID and email of the operator who clicked Export.
  • Export timestamp — when NovaVMS generated the file.
  • Source segment SHA-256 — a hash of the original recorded segments (the ring-buffered RTP data that produced the clip) taken before re-mux. Anyone with the segments and the file can recompute this hash and compare.
  • NovaVMS version — the cloud backend version that produced the export, for later forensics.

The block is human-readable ASCII JSON so a reviewer with nothing but a hex editor can read it.

How to verify

For now, verification is manual. Any modern tool that reads MP4 metadata exposes the block.

  • ffprobe -show_format -show_streams clip.mp4 lists the udta metadata including the JSON block.
  • MediaInfo shows the same data under the General track.
  • Forensic video tools (Amped FIVE, ProVision) surface it as custom metadata fields.

A verification CLI that takes the export plus the original segment archive and recomputes the SHA-256 is on the roadmap. Until it ships, reviewers verify by reading the metadata block and confirming the camera, time range, and exporter match the audit log entry NovaVMS wrote at export time.

What it doesn’t do

Be honest about the limits. This is tamper-evident for court, not tamper-proof against adversaries.

  • No trusted certificate authority. The file is not cryptographically signed by a third-party CA. A reviewer cannot prove it came from Novalien’s private key, because there is no such key in v1. They can only prove the metadata block and the original segment hash match.
  • No revocation. If the hash is compromised later (for example, a cloud backend with write access is breached), there is no mechanism to mark old exports untrusted.
  • No hash of the exported MP4 itself. We hash the source segments, not the final file. A re-encode or transcode produces a different-looking MP4 with the same source-segment hash. Treat the hash as “this frame data came from NovaVMS,” not “this exact file is untouched.”
  • No audit across re-export. If someone re-exports the same clip an hour later, they get a new file with a new export_initiated_by and export_timestamp. The two files describe the same recording but are not bit-identical.

This matches what Arcules ships as “External Case Sharing” and Eagle Eye ships as “secure clip sharing.” None of the competitors we surveyed ship a full cryptographic trust chain either. The bar in the industry is tamper-evident metadata, and that is what NovaVMS meets.

Trade-offs

  • Export size. The metadata block adds roughly 2 KB to every export. Negligible on a 30 MB clip, noticeable on bulk exports of tiny snapshots.
  • Export time. Computing the source-segment SHA-256 during re-mux adds a few hundred milliseconds per clip. An operator exporting one event will not notice. An operator exporting a hundred events in bulk adds roughly a minute of wall-clock time for hashing. The trade is worth it — an export without the hash is an export the reviewer cannot verify.
  • Cannot redact without re-export. Once the hash is baked in, clipping off the first ten seconds means running a new export that produces a new hash over the new segments. There is no way to “edit and keep the original signature valid.”

See also