Video repair terms
explained precisely.

Without the moov atom, no player can decode a single frame — even if all the raw data is still sitting in the mdat. When a recording is cut off, the moov atom is missing in roughly 70% of cases, because the encoder only writes it once the recording ends cleanly.

The mdat atom is where all the raw frames and audio samples sit one after another, in sequence. It typically accounts for 99% of the file size. The sample table in the moov atom points to individual frames in the mdat using byte offsets. In most "broken" videos the mdat block is intact — only the index is gone.

The ftyp atom carries the major brand (e.g. "mp42", "isom", "qt "), the minor version and the compatible brands. Decoders read this first — when it is missing, many players give up on the spot. In files recovered by DiskDrill the ftyp can come from an unrelated sector and carry the wrong brand bytes.

The sample table is made up of several sub-atoms (stts for decode times, stss for keyframes, stsc for sample-to-chunk mapping, stsz for sample sizes, stco for chunk offsets in the file). It is the central data structure the decoder needs to seek, decode and stay in sync. During repair it has to be rebuilt from the NAL units in the mdat block.

MOV was defined by Apple in 1991, and MP4 (1998) is based directly on it. Both use the same top-level atoms (ftyp, moov, mdat, trak, and so on). MOV permits more proprietary codecs (ProRes, Animation), while MP4 is more restrictive. For repair tools they are largely interchangeable — the container-repair code is the same.

Every video frame is made up of one or more NAL units. They are marked either by start codes (0x00 00 00 01) in the Annex B format or length-prefixed in the MP4 format. NAL types distinguish between IDR frames (keyframes), P/B frames, SPS, PPS and — in HEVC — VPS. Repair tools scan the mdat block for NAL boundaries to find frame edges when the sample table is missing.

The SPS has to be decoded before the first frame. It carries the resolution, bit depth, chroma format (4:2:0, 4:2:2, 4:4:4), profile (Baseline, Main, Main 10, High) and level (frame-rate limits). During repair the SPS must either be extracted from the bitstream or taken from a reference recording.

The PPS references an SPS and holds frame-level parameters. A stream can carry several PPS, and each frame points to one of them. Like the SPS, the PPS is extracted from a reference or from the bitstream.

The VPS was introduced with HEVC and carries cross-layer information for scalable coding (SHVC) and multi-view (MV-HEVC). Even though most HEVC streams never use those features, the VPS still has to be present before the first frame.

IDR frames are the sync points in a video stream. Every recording starts with an IDR. When you seek, the decoder jumps to the nearest IDR and starts decoding from there. During repair the first IDR is the anchor for the entire frame table.

XAVC-I codes every frame as an intra frame (no inter-frame compression) — up to 600 Mbit/s. XAVC-L uses GOP compression, which is more efficient but harder to repair. XAVC-S is the consumer variant found in the A7 models. The bitrate class (240, 480) is critical for repair — profiles 5.1 and 5.2 are not interchangeable.

The ProRes variants (Proxy, LT, 422, 422 HQ, 4444, 4444 XQ) differ in bitrate and colour depth. ProRes 4444 supports an alpha channel. Every ProRes variant lives in a MOV container — remuxing to MP4 is not standards-compliant, because MP4 does not officially list ProRes as a codec.

H.264 (= AVC, MPEG-4 Part 10) has been standardized since 2003. Its profiles range from Baseline (webcam) to High 10 (professional 10-bit). It is configured in MP4 through the avcC box. Repair is robust here, because decoders are widespread and forgiving. The success rate for a standard repair is around 85%+.

HEVC has been standardized since 2013. Its profiles range from Main (8-bit 4:2:0) to Main 10 / Main 4:2:2 (professional). It is configured in MP4 through the hvcC box. Repair is harder than with H.264 because of the length-prefixed NAL units and stricter decoders. On the Sony FX series, iPhone Pro, GoPro HERO11+ and DJI Avata 2, HEVC is the default.

Dolby Vision stores dynamic tone-mapping metadata (RPU) in dedicated NAL units, one per frame. Profile 8.4 (iPhone Cinematic mode) is backward-compatible with HDR10 (static metadata). When a damaged file loses its DV RPU streams, the decoder falls back to SDR — and the picture looks flat.

HDR10 uses BT.2020 colour primaries and PQ (Perceptual Quantizer) as its transfer function. The mastering-display metadata (Max Content Light Level, Max Frame Average) is written once in the container — unlike Dolby Vision, which carries per-frame metadata. During repair this metadata has to be taken from a reference.

BT.2020 (ITU-R Rec. 2020) is the colour-space standard for 4K, 8K and HDR. It is flagged in the bitstream VUI (Video Usability Information) as colour_primaries=9. If that information is lost during repair, the footage is interpreted as BT.709 — and the colours come out oversaturated.

It shows up mainly on Sony XAVC with 24-bit PCM, because the audio stream has a pre-roll ahead of the first video frame. Untrunc and similar tools hand back the file with that pre-roll uncorrected. Specialized tools measure the drift by cross-correlating against the reference and shift the audio track to match.

It happens when the audio decoder reads container-header bytes or video bytes as audio. On many Sony and Canon files this occurs predictably. The fix: a per-50ms-window peak scan of every track — anything above −3dB in the first second is flagged as a burst and silenced (with padding for a smooth transition).

iPCM is uncompressed audio, well suited to professional recording (XLR inputs). During repair, iPCM is easier to reconstruct than compressed AAC, because there are no codec frames to decode. The Sony FX3, FX6 and FX9 use iPCM with up to 4 parallel tracks.

untrunc-anthwlock on GitHub is the maintained fork. It works well on H.264 and less reliably on HEVC 10-bit. Important: use the -s flag (skip unknown sequences) on Sony XAVC with iPCM. No audio-drift fix, no support for modern codecs.

With -err_detect ignore_err, ffmpeg can copy corrupt packets straight through. When the moov is missing, ffmpeg gives up immediately — there is no repair path. It is excellent for hev1↔hvc1 tag conversion and for remuxing.

Around 99 USD. Very robust container repair, but no audio-drift correction and an ancient UI. It is widely used in digital forensics. For modern professional codecs it is not as specialized as Haven or Aeroquartet.

Not a software product — a service with a diagnostic front end and manual repair carried out in Barcelona. It has a high success rate on severe damage, but it is expensive, slow, and requires a cloud upload.

DiskDrill scans sectors for ftyp signatures and then reads linearly up to the next one. On a fragmented card that can produce MP4 files whose uuid bytes are mixed in from other sectors. Repairing files like these calls for profile verification via the mdat frame structure, not via the uuid.

CFexpress Type A (Sony) and Type B (Canon, Nikon) use NVMe-PCIe instead of SATA. Theoretical speeds reach 1700 MB/s, and in practice 800–1200 MB/s sustained. For 8K RAW or XAVC-I 4K50p a good Type B reader is essential — cheap readers can introduce data errors on files of 20+ GB.

The hvcC box is the HEVC counterpart to the avcC box (for H.264). It lives in the moov and carries profile_idc, level_idc, chroma_format, bit_depth, length_size_minus_one and the arrays of SPS/PPS/VPS NAL units. Get a single byte wrong and decoder initialization fails — and all you see is a black frame.

With hvc1 encoding, all codec parameters must live exclusively in the hvcC box (out of band). With hev1 they are also allowed in-band in the bitstream. When tools convert between the two tags without copying the parameters between box and stream, the result is a file with an empty hvcC and nothing but black playback.

Sony, Canon and other manufacturers store proprietary data here, such as the camera model, recording profiles and codec settings. On Sony XAVC the profile bytes sit at byte 0x6e: 7A 10 33 = 25p Class 240, 7A 10 34 = 50p Class 480. After a DiskDrill recovery these bytes can be mixed in from neighbouring sectors and show the wrong values.

Specified in ISO/IEC 14496-12. It defines the recursive box structure (also called "atom") that underpins every modern container format. MP4 (ISO/IEC 14496-14), MOV (Apple QuickTime) and M4A all build on the same base structure — they differ only in their brand and the codecs they permit.