The DVR That Only Plays on the Vendor's Player
During a convenience-store robbery investigation, the loss-prevention manager provides a 42-second MP4 that he created by playing the store's Nexus-8 DVR footage on his laptop and recording the screen with a phone. The DVR stores eight 704×480 cameras at 30 fps with 21 days of retention; the incident occurred nine days ago. The phone recording is 1280×720 H.264 at a variable frame rate, and the laptop's taskbar and a notification pop-up are visible. The MP4 shows the suspect at the counter but has no embedded DVR timestamps. The original DVR remains on site and is still overwriting. The prosecutor asks you to 'clean it up and enhance the face.' You have not yet received anything from the DVR itself. The defense has indicated it will challenge authenticity and timing. The store's POS system logs transactions to the second and is synchronized to a network time server.
1. What should you request from the DVR, and why is the phone recording inadequate as a primary exhibit?
Read the worked answer
Request the native export, not a re-recording: the proprietary container or files, the exact player version, the export log, camera configuration (resolution, fps, GOP, bitrate), and a hash manifest for each file. Also request a clock reference-POS logs, a known phone call, or the DVR's NTP setting-plus time-zone and DST configuration. The phone recording is inadequate because it is a screen capture of a re-decoded playback: it has variable frame timing, no native frame index, no embedded DVR timestamps, and UI overlays. It cannot support frame-specific conclusions or hash-based authentication, and the phone's own compression may drop or duplicate frames. The native export preserves the original bitstream and metadata, allows you to verify the vendor player's decoding, and permits a re-export comparison. Without it, any timing statement is relative to the phone recording's playback, not the DVR clock.
2. Outline the verification steps you would perform on the native export before analysis.
Read the worked answer
- Document custody: who exported, when, with what tool and version, and hash every file at receipt. 2) Play the export on a clean reference machine using the vendor player and confirm it matches the DVR's own playback for the same range. 3) Re-export the same 42-second range and compare frame-by-frame; differences indicate a lossy export or a decode problem. 4) Extract container metadata-codec, resolution, frame rate, GOP, timestamps-and record it. 5) Establish clock offset using the POS log: pick two visible transactions at least 20 minutes apart, compute the offset at each, and derive drift. 6) Confirm the player's time display (local vs UTC) and whether the DVR applies DST. Only after these steps should you analyze the face. The goal is to show the exhibit is a faithful copy and that its time base is characterized, not merely that it plays.
3. If the native export cannot be obtained, what limitations must appear in your report?
Read the worked answer
State that the exhibit is a second-generation screen capture, not the original export; that no hash-based authentication of the DVR data is possible; that frame timing is variable and frame uniqueness is not established; and that timestamps are absent or derived from the phone display. Any time statement should be tied to the phone recording's playback and given a range, not a precise instant. Facial enhancement cannot add reliable identity detail to a re-encoded screen capture, and the taskbar overlay may occlude evidence. The report should say the recording is suitable only as an investigative lead, that the original DVR remains the best evidence, and that continued overwriting may destroy it. If the DVR was later exported, compare it to the phone recording and document any differences rather than assuming they are the same.