Proprietary DVR footage is still evidence.

Last reviewed: 21 July 2026

Why it will not open in a normal player

Budget recorders, a lot of them built by the same handful of Chinese OEMs, do not export clean MP4s. They wrap the video in a proprietary container made for their own playback software:

• Dahua: .dav files, or a DHAV boxed stream.
• Hikvision and bundled exports: a proprietary export that often ships with its own player .exe.
• Uniview (UNV): its own export wrapper.
• XiongMai (the OEM behind dozens of no-name brands): .264 files, usually a raw H.264 or H.265 stream with vendor framing.
• Tuya and Grid Connect (cloud cameras): short clips pulled from the app, re-wrapped.

The picture inside is standard H.264 or H.265. The wrapper around it is not. A normal player does not know how to unwrap it, so it gives up. The fix is to de-frame the file: strip the vendor container and re-mux the video stream into a standard MP4 or MKV that anything will play.

De-framing, step by step

1. Copy first, work on the copy. Never touch the original export, and if you do not have it yet, ask for the recorder's native export before it is overwritten. Hash the file (shasum -a 256) so you can later prove the working copy matches the source.
2. Identify the real format. Read the header, not the extension. ffprobe file.dav, or a hex view of the first bytes, will usually name the container (DHAV, an H.264 start code 00 00 00 01, and so on).
3. Try a straight re-mux. ffmpeg -i input.dav -c copy output.mp4 re-wraps the stream without re-encoding, so there is no quality loss and the original frames are untouched. A lot of .dav and .264 files come across cleanly this way.
4. If the container is unknown to ffmpeg, use the vendor's own export or player to convert to AVI or MP4, or a format-specific de-framer. The vendor player is often the only thing that reads its private index.
5. Re-encode only as a last resort, and keep the re-muxed original beside it. Re-encoding changes every pixel; an evidential copy should stay as close to source as possible.

The footage carries time in five places

This is why it matters for a timeline: the recorder stamps time and events across several layers, and they do not always agree. Reconcile them rather than trusting one.

• Filesystem: file created and modified times on the SD card or HDD. Watch out: these reflect the recorder's clock, and copying can rewrite them.
• Container header: channel, start time and codec inside the .dav or DHAV box. Watch out: the recorder's clock again, so check it against a known event.
• In-stream markers: timestamps and SEI data embedded in the H.264 or H.265 stream. These survive a re-mux, so they make a good cross-check.
• Vendor per-frame data: a private block some DVRs stamp on each frame (channel, time, frame index). This is format-specific and needs a de-framer that exposes it.
• DVR operation log: logins, playback, config and clock changes, motion events, held separately in the DVR's own database. This is the one place a clock change or a recording gap shows up.

The job is to pull time out of each layer and normalise it into one timeline. When the burnt-in on-screen clock, the container time and the operation log all line up, you have a solid anchor. When they do not, the gap itself is often the finding: a clock that was reset, a segment that is missing, a camera that was offline. If the recorder's clock is plainly wrong, you can still rebuild the timeline from the order and spacing of events instead.

The honest limit: a locked modern phone

If the evidence you actually want sits on a locked, current-model phone, be straight about what is possible. Modern iPhones and Android phones tie storage encryption to a hardware-backed secure element (a Secure Enclave or hardware keystore). The data is encrypted with a key you cannot read out, and passcode attempts are rate-limited in hardware.

• There is no lock-screen bypass and no practical brute-force for a current, updated device. Anyone selling you one is selling you nothing.
• Recover from backups instead: an iCloud or Google account backup, a computer (Finder or iTunes) backup, another device signed into the same account, or the account's own data export.
• A DVR or an SD card is a different problem, and those are usually recoverable. Do not let one locked phone make you write off the footage that is not locked.

The short version

Proprietary DVR files (Dahua .dav and DHAV, Hikvision exports, UNV, XiongMai .264, Tuya and Grid Connect) fail to play because of the wrapper, not the video inside. De-frame them, usually ffmpeg -c copy re-muxes the stream without quality loss, then pull time from all five layers (filesystem, container, in-stream, per-frame, DVR log) and reconcile them into one timeline; where they disagree is evidence, not noise. A locked modern phone is the real dead end: no bypass exists, so go to backups.

General guidance on method, not legal advice; a court matter needs a qualified forensic examiner.

Where this comes from

Background reading on the technology described above, so you can check any of it yourself rather than take our word for it:

• Wikipedia: Digital video recorder, what a DVR is and how it records, stores and exports video.
• Wikipedia: Closed-circuit television, an overview of how CCTV systems and their recorders fit together.