Practice with mock tests, learn from structured notes, and get your questions answered by a global forensic community, all in one place.
CCTV and DVR systems record differently depending on whether they are analogue, IP-based, or hybrid, and each architecture demands a tailored acquisition strategy to preserve evidential integrity. This topic covers the hardware and storage formats investigators encounter, the methods for extracting video without altering the original, and the chain-of-custody obligations that govern video exhibits.
Last updated:
Walk into any convenience store, car park, or office lobby and there is almost certainly a camera watching the entrance. When something goes wrong in that space, the recorder behind that camera becomes evidence. The problem is that the people who installed it were thinking about security, not courtroom admissibility, and the result is a zoo of proprietary formats, embedded operating systems, and storage quirks that can baffle a first-time examiner. Getting the footage out in a form that is both complete and provably unaltered is the whole skill this topic addresses.
CCTV systems fall into two broad families: analogue systems that feed coaxial cable into a Digital Video Recorder (DVR), and IP-based systems where cameras send compressed streams over a network to a Network Video Recorder (NVR). Each family has its own storage conventions, compression schemes, and failure modes. Older analogue DVRs multiplex footage from eight or sixteen cameras into a single proprietary file. A modern NVR might store standard H.265 streams in a folder tree, or it might use a vendor-specific container just as opaque as anything from a decade ago. Neither architecture is inherently better for the investigator; both demand a documented, write-protected acquisition before any analysis begins.
This topic maps the hardware, explains what multiplexing does to frame rate and timing, walks through the three main acquisition routes (physical disk imaging, network export, and proprietary player extraction), and ties it all back to the chain-of-custody obligations that come from the ACPO guidelines used in the UK and the SWGDE standards followed in the United States and elsewhere. Get the acquisition wrong and everything that follows, however careful, is built on sand.
The camera on the wall tells you almost nothing about what is happening inside the recorder.
Analogue CCTV cameras output a continuous composite video signal over coaxial cable. The DVR at the other end of that cable samples the signal, compresses it using a codec (H.264, MPEG-4, or an older proprietary algorithm), and writes it to disk. The camera itself has no intelligence: it sends a raw signal and the DVR makes all the encoding decisions. This centralised design means all the forensic complexity lives in the recorder, not the cameras.
IP cameras are fundamentally different. Each camera is itself a small computer. It captures the image, compresses it to H.264 or H.265, and sends the compressed bitstream over the network. The NVR's job is storage and playback management; it does not re-encode the stream. The result is that an IP camera's footage is, in principle, more portable: if the NVR stores in a standard container format, any compliant player can open it. In practice, many NVR vendors wrap the streams in proprietary containers or apply custom extensions, so the examiner still needs to verify playback before declaring the export clean.
| Feature | Analogue DVR | IP / NVR |
|---|---|---|
| Camera output | Composite analogue signal | Compressed digital stream (H.264/265) |
| Encoding location | DVR hardware | Camera itself |
| Storage format | Usually proprietary container | Proprietary or standard (MKV, MP4) |
| Multi-camera recording | Multiplexed single file | Separate stream per channel (typically) |
| Network access | Optional add-on | Native; web UI standard |
| Forensic imaging approach | Remove drive, hardware write-block | Remove drive OR network export |
Hybrid systems exist: an older building may have had analogue cameras installed ten years ago but a newer DVR replacing the original recorder, or the IP cameras may feed a cloud storage service rather than a local NVR. Investigators should never assume the architecture from the cameras alone. The first step is always to locate the recorder, identify its make and model, and consult the vendor's documentation.
A sixteen-camera DVR does not give you sixteen full-rate recordings.
A budget DVR rated for sixteen cameras typically records at 25 frames per second (PAL) or 30 fps (NTSC) total across all channels combined, not per channel. With sixteen cameras active, each channel gets roughly 1.5 fps. The recorder cycles through channels, writing a short burst of frames from camera 1, then camera 2, and so on. Inside the recording file the data from all channels is interleaved: a block for channel 1, then a block for channel 2, repeating continuously.
To recover individual channel timelines, the examiner must demultiplex the recording. Some forensic tools (Amped FIVE, DVR Examiner) automate this. Others require manual frame extraction. In all cases the examiner should document the effective frame rate per channel, because a court trying to understand whether an action in the footage happened before or after another action needs to know how coarse the temporal resolution is.
Three routes exist; choose the one that does least to the data.
Acquisition method selection depends on the device state, the time available, and the risk of data loss from powering off the recorder. The three main approaches are physical disk imaging, network export, and proprietary player extraction. They form a rough hierarchy of forensic robustness.
The write-blocker designed for a laptop drive may not speak the language of an embedded DVR.
Hardware write-blockers intercept the command interface between a drive and the host computer. For standard SATA or USB drives this works transparently. Inside a DVR, the drive connects to the recorder's main board over a SATA interface, but removing it requires opening the enclosure and, sometimes, defeating tamper seals. Once extracted, the drive is treated like any other SATA device: insert into the write-blocker, connect to the forensic workstation, image, and hash.
Some DVRs use 2.5-inch laptop drives; others use standard 3.5-inch desktop drives; a growing number of NVRs use NVMe SSDs on M.2 slots. The examiner should carry adapters that cover all three form factors. If the internal drive uses a non-standard power connector, photograph and document the connector type before any modifications.
The footage is only as reliable as the paperwork behind it.
Chain of custody for a CCTV exhibit begins at the moment the investigator decides the footage is relevant. Before touching the recorder, the scene should be photographed: the recorder in situ, its connections, any on-screen display showing date and time, and the physical labels on the device. The investigator should note the displayed time against a trusted reference (GPS time or NTP-synchronised mobile) to establish the recorder's clock offset. Clock drift is one of the most common sources of evidential dispute in CCTV cases.
ACPO (the UK Association of Chief Police Officers, whose digital evidence guidelines remain widely referenced internationally even after ACPO itself was restructured into the National Police Chiefs' Council) sets out four principles for digital evidence: it must not be changed; any person accessing it must be competent; a log of all actions must exist; and the investigating officer bears responsibility for ensuring the law and these principles are adhered to. SWGDE guidance in the United States echoes these principles and adds specific validation requirements for the tools used.
A recording from 21:42 may actually be from 21:55 if no one checked the clock.
DVR clocks drift. A system installed years ago with no NTP synchronisation may be minutes or even hours out. Establishing the offset is essential for placing events in the correct chronological context and for correlating the footage with other evidence sources (mobile phone records, access logs, witness testimony).
The standard approach is to photograph or video the DVR's on-screen time display alongside a simultaneously captured reference: a mobile phone showing GPS-locked time, or a radio clock. The difference between the two is the clock offset. This offset, and its direction (recorder fast or slow), must be recorded in the forensic report and applied to any time reference drawn from the footage.
The on-screen time burned into a CCTV recording is not the time the event occurred. It is the time the recorder's clock said it was. Those two things are only the same if the clock has been verified.
Some DVRs embed timestamp metadata in the file header separately from the on-screen burned-in text. Both should be checked. It is possible for the on-screen display to have been manually corrected while the file metadata retains the old (drifted) value, or vice versa.
A sixteen-camera DVR is rated at 25 fps total. What is the approximate effective frame rate per camera?
Test yourself on Forensic Audio, Video and Image Analysis with free, timed mocks.
Practice Forensic Audio, Video and Image Analysis questionsSpotted an error in this page? Report a correction or read our editorial standards.