Matching Video to a Source Camera

The image sensor is the starting point of any camera-specific signature. Manufacturing tolerances mean that no two pixels in a sensor respond identically to the same amount of light. This fixed-pattern variation, called Photo Response Non-Uniformity, is stable across the sensor's lifetime and appears in every frame the device captures. To extract PRNU from a video, the examiner averages many frames to cancel out scene content and noise, leaving behind the fixed pattern. That pattern is then correlated against a reference fingerprint built from a known set of recordings made with the suspect device.

Video introduces complications that still-image PRNU analysis does not face. Compression, particularly at high compression ratios, suppresses high-frequency noise components, degrading the PRNU signal. Motion between frames adds temporal noise that must be separated from the fixed spatial pattern. In-camera stabilisation and digital zoom can geometrically transform the sensor plane, shifting the PRNU pattern in ways that complicate alignment. These challenges mean that PRNU matching in video typically requires more frames and more careful pre-processing than in still-image work, and the resulting correlation values are lower.

Beyond pixel-level PRNU, some sensors produce additional fixed-pattern artefacts: banding from the analogue-to-digital converter, periodic noise from the readout circuit, and hot pixels that consistently over-respond. These can supplement PRNU-based matching, particularly in cases where compression has degraded the PRNU signal to a marginal level. Together, sensor-level signatures provide a physical link between a video and the specific piece of hardware that recorded it, independent of any metadata or codec analysis.

A video codec such as H.264 (AVC) or H.265 (HEVC) is a standard, not an implementation. The standard specifies what a conformant bitstream must contain, but leaves many encoding decisions to the implementer. Camera manufacturers make firmware-level choices about GOP length, the ratio of I to P to B frames, the quantisation parameter range, the specific quantisation tables used for different block types, and whether to use CABAC or CAVLC entropy coding. These choices are made once, encoded in firmware, and applied consistently to every video the device records.

An examiner inspecting a questioned video with tools such as MediaInfo, FFprobe, or a bitstream analyser can extract these parameters from the bitstream header and the sequence parameter set (SPS) and picture parameter set (PPS) in H.264, or the equivalent structures in H.265. The extracted values are then compared against the reference profile. A match on encoder version string, profile/level, GOP length, and quantisation matrix together constitutes meaningful concordance. A mismatch on any of these, for example a quantisation matrix that the suspect device's firmware never produces, constitutes a conflict that must be explained.

Variable bitrate encoding allocates more bits to frames with high spatial or temporal complexity and fewer to static or predictable frames. The rate-control algorithm that makes these decisions is firmware-specific: it defines the target bitrate, the maximum and minimum allowed per-frame bitrate, the look-ahead window, and the speed-quality tradeoff. Because these decisions are made in firmware, recordings from the same device show a recognisable bitrate allocation pattern across similar scene types.

To analyse the bitrate profile, the examiner uses a bitstream parser to extract the coded size of each frame. Plotting frame size against time reveals the rate-control behaviour: how quickly the encoder responds to scene changes, the ratio of I-frame to P-frame sizes, and whether the encoder uses a constant quantisation parameter or a genuine VBR rate controller. These patterns can be compared between the questioned video and reference recordings, particularly when both were recorded under similar conditions.

Bitrate analysis is most useful when combined with other parameters. A questioned video that matches the suspect device's codec fingerprint, colour pipeline, and bitrate profile across all three dimensions provides much stronger evidence than a single-parameter match. Conversely, a bitrate profile that does not match the reference, for example, an unusually low maximum bitrate that the suspect device never produces at the relevant quality setting, is a meaningful conflict even if other parameters agree.

The colour pipeline defines how a camera transforms raw sensor data into the encoded video signal. Key decisions include the colour primaries (typically Rec.601 for older standard-definition devices or Rec.709 for high-definition), the transfer characteristic (the gamma curve), the matrix coefficients used for converting between RGB and YCbCr, and the chroma subsampling ratio (4:2:0 for most consumer cameras, 4:2:2 for higher-end devices). These parameters are recorded in the Video Usability Information (VUI) extension of the H.264 SPS and in the container-level metadata.

The container format itself carries additional device-specific information. An MP4 file's 'moov' atom structure, the order of metadata boxes, and the specific atom types present vary by camera manufacturer and firmware version. Similarly, the audio codec and its sampling rate, the audio-video interleaving pattern, and the specific creation tool string are all container-level characteristics that can be compared against the reference profile.

Metadata fields extracted by tools such as ExifTool reveal camera make, model, firmware version, GPS coordinates, and creation timestamp. These fields are not cryptographically protected in most camera formats and can be edited with freely available software. The examiner's role is to assess whether the metadata is internally consistent, whether it is consistent with the bitstream-level parameters, and whether both are consistent with what the suspect device is known to produce. Internal consistency is necessary but not sufficient: a forger who edits all metadata fields together can produce a consistent but false record.

A reference profile is built from recordings made with the suspect device under known conditions. The examiner records video at each quality setting the device supports, covering different scene types (static, moderate motion, high motion), and extracts the full set of parameters from each recording. The result is a table of expected values and acceptable ranges for each parameter: the PRNU fingerprint, the codec parameters, the rate-control behaviour at each quality level, and the container metadata structure.

When the reference profile is compared against the questioned video, the examiner documents the outcome for each parameter: concordant (the questioned value falls within the reference range), conflicting (the questioned value falls outside the reference range), or indeterminate (the parameter cannot be reliably extracted from the questioned recording due to compression, damage, or unavailability). The overall source attribution opinion is then an aggregation across all parameters, weighted by the evidential strength of each.

When the original suspect device is not available, the examiner may use a population of the same model obtained from other sources, or published specifications, to build a partial reference profile. This is weaker than a device-specific reference profile because firmware updates can alter codec parameters, and manufacturing variation means not all units of the same model behave identically. The examiner must account for this uncertainty in the opinion.

Source camera matching is presented as a weight-of-evidence opinion, not a probabilistic match statistic of the kind used in DNA profiling. There is no agreed population database of camera codec fingerprints equivalent to STR allele frequency tables, so the examiner cannot calculate a likelihood ratio in the strict statistical sense. Instead, the opinion is expressed as a degree of support: the questioned video is consistent with the suspect device across all examined parameters, or specific parameters are inconsistent with the suspect device.

Different jurisdictions apply different admissibility standards. In the United States, federal courts apply the Daubert standard, which requires the expert to demonstrate that the method is based on sufficient facts, uses reliable principles, and has been applied reliably to the facts. In the United Kingdom, courts assess expert evidence under the Criminal Procedure Rules and the Law Commission guidelines on expert reliability. In India, expert evidence on electronic records is governed by the Bharatiya Sakshya Adhiniyam 2023 (which replaced the Indian Evidence Act 1872), and the Bharatiya Nagarik Suraksha Sanhita 2023 sets the procedural framework. In the European Union, national evidence rules apply, but the growing influence of standards such as ISO/IEC 27037 on digital evidence handling shapes what courts expect from examiners.

Regardless of jurisdiction, the examiner's report must document the reference profile construction, the extraction methodology, the tools used and their versions, the specific parameters compared, and the basis for each concordance or conflict finding. The opinion must be expressed in terms that distinguish between exclusion (a parameter the suspect device cannot produce), inclusion (a parameter consistent with the suspect device), and indeterminate findings. Exaggerating the strength of inclusion findings, in particular treating a multi-parameter match as a unique identification without supporting validation data, is a recognised source of wrongful conviction risk in multimedia forensics.