A generic scene: a shop is burgled at night, the owner says the camera caught it and the DVR in the back office holds eight cameras of footage. The investigator plugs in a pen drive, chooses export, and comes away with a folder of files that will not open on any computer in the office. This happens every day and it is not the investigator's fault. DVR evidence is hard because the recorder was designed to record and play back on itself, not to hand evidence to anyone.

The guidance we lean on here is SWGDE's Best Practices for Data Acquisition from Digital Video Recorders (version 1.0, 2018) and the OSAC proposed Standard Practice for Data Retrieval from Digital CCTV Systems (version 2.0, June 2020), hosted by NIST. Both are best-practice documents, not law, and both say the same two things: footage is perishable, so act early, and the native proprietary export is the best evidence, so collect it first.

Terms Worth Getting Straight

C
Container and codec
A container is the file structure that holds video, audio and metadata streams; a codec is the method used to compress each stream. A file may use a common codec such as H.264 inside a container nobody else can read. SWGDE's technical overview notes that in DVRs the video, audio and text metadata are often stored separately on the file system and assembled into a sequence only at playback.
I
Image set versus bit-stream duplicate
OSAC uses image set for the exported files and bit-stream duplicate for a sector-level copy of the DVR hard disk. They are different objects with different hashes and different uses.
P
Player-only export
An export that plays only in the manufacturer's viewer, which the DVR may copy to the pen drive alongside the data or which must be downloaded from the maker's site. OSAC advises collecting the player or codec together with the data and confirming playback on another computer before leaving.
Proprietary file format
OSAC defines it as any file format unique to a specific manufacturer or system. It is also the format most likely to preserve the original quality, timing and metadata, which is why both documents put it first.
T
Time offset
The difference between the DVR clock and a trusted reference time, recorded at the scene. Footage timestamps are only meaningful once this offset is known.

Proprietary File Systems and Containers

Many DVRs do not use a PC file system at all. They write video streams into their own layout across the disk, so a DVR drive connected to a Windows machine shows as unformatted or RAW, and OSAC warns that a bit-stream duplicate that looks empty may still hold the footage. The export menu then wraps the chosen period into the maker's container, often with a copy of the maker's player. Convert that to an open format such as AVI or MP4 and three things can happen: the video is recompressed, the frame size or aspect ratio changes and, as OSAC notes directly, time and date metadata may be lost or modified.

So collect the native files and the player first, and take the open-format export as well when time and the system allow, labelled as a convenience copy. If the DVR offers an engineer or administrator login, OSAC observes that it usually unlocks more export options, including native export; the owner's password and permission are part of the record.

  • Native export plus the player is the master evidence
  • Open-format exports are convenience copies and must be labelled so
  • A RAW or empty-looking drive may hold the footage
  • Check that the remote viewer exports video, not stills, if used

Time Offsets and Variable Frame Rates

Never correct the DVR clock, even if it is obviously wrong. SWGDE and OSAC both say to compare it against a known time reference, record the offset, and leave the system alone, because changing the time can disturb the indexing of recorded data. IP cameras on a network recorder may keep their own clock, so OSAC asks that both be documented. Also establish whether anyone changed the time between the incident and your visit, which would make a single offset wrong for part of the recording. Record the local time zone and whether daylight saving applied at the time of the incident, since Indian systems are often shipped with a foreign default.

Frame rate is the other trap. Most DVRs record at a configured rate per camera and many drop frames when nothing moves, so the stream has a variable frame rate. SWGDE's frame timing best practice warns that proprietary video files may produce inaccurate frame rate reporting in many playback and processing programs. The practical rule is that the time of an event comes from the timestamps embedded in the recording and the measured offset, never from a playback counter or from frame number divided by a nominal rate. Report the frame rate as recorded in the DVR settings and as measured, and say if the two differ.

Verifying the Export With Hashes

SWGDE's DVR document points to its integrity-of-imagery guidance for authenticating what was acquired. The routine below is our recommended minimum.

  1. 01
    Hash at the scene

    As soon as the export finishes, compute SHA-256 of every exported file and of the player installer on the collection laptop. Record the values with file names and sizes in your notes. A photograph of the DVR screen showing the export period and camera list belongs beside them.

  2. 02
    Prove playback

    Open the files with the collected player on a separate computer before leaving. OSAC asks you to confirm that the files play, the viewer works, the picture matches what the DVR shows and the right cameras, dates and times were retrieved.

  3. 03
    Hash again at the lab

    On receipt, recompute the hashes and record the match in the chain of custody. From here the native files are the master and are never worked on directly.

  4. 04
    Hash every derivative

    Each conversion, clip or enhanced still is a new object with its own hash, its own tool and version and its own entry in the report. Keep the processing path from master to derivative written down.

  5. 05
    Restore the system

    Return the DVR to its original settings and confirm it is recording again, ideally in the owner's presence, and record that you did so.

When to Image the Whole DVR Disk

Export is the normal route. A bit-stream duplicate of the drive, or removal of the unit, is for the cases below, and it brings its own rules from the OSAC practice.

  • Export is impossible or crippled: no working ports, a locked menu, a failed unit, or a remote viewer that only exports stills.
  • The volume is too large to export in the time available, or the footage is about to be overwritten.
  • The period of interest has already been overwritten or deleted on the recorder and may survive only in unallocated areas of the disk.
  • Shut the system down properly before removing any drive, even one that looks hot-swappable, and photograph the drive positions. Duplicate every internal drive, not just the one in the caddy.
  • Produce a bit-stream duplicate, not an image set, onto a brand new drive. Some recorders will run only with the original drive, so you may have to put the duplicate back and take the original, or take the unit with its drive, power supply, remote, dongle and keys.
  • Weigh the legal and practical side: the owner's business loses its recording while the unit is gone, consent or authority for removal must be clear and the original drive is master evidence.
  • Expect the duplicate to look empty on a PC. Analysis of a proprietary DVR disk is a laboratory task with tools that understand the maker's layout, and it is outside the scope of the acquisition documents.

Documenting the Export

The OSAC practice provides a worksheet in its appendix. These are the fields that matter most when the footage is challenged a year later.

  • Recorder make, model, serial number and firmware version; number of cameras and hard drives; recording mode, quality setting and configured frames per second per camera; retention or overwrite setting.
  • DVR displayed time against the reference time, the source of the reference, the time zone setting and whether any time change occurred between incident and acquisition.
  • Who exported, when, by which menu path, with which export settings, onto which media; the login used and who authorised it.
  • File names, sizes and SHA-256 values for every exported file and for the player; the player version.
  • Playback verification: on which computer, with which player, what was confirmed.
  • Photographs of the recorder, its connections, its screens during export and the media used.
  • A chain-of-custody record starting at the moment of export, not at the lab.

This is an explainer written by the DFRTI editorial team from the sources below. It is not a vendor announcement and DFRTI has not independently tested any product named in it unless the text says so.

  • CCTV
  • DVR
  • proprietary formats
  • video evidence
  • time offset
  • frame rate

Learn this properly

Go deeper with DFRTI

Free pages explain the ground. Structured courses, lab work and a mentor take you from knowing about it to doing it on a case.