How a 1.6 GB unplayable 20251025075725.mp4 (SplitCam screen recording, Windows) was diagnosed as unrecoverable — and the checks that prove an mdat is garbage before you sink hours into untrunc.

Bottom line

moov atom not found usually means “interrupted recording, repairable with untrunc”. But if the recorder crashed before flushing any frames, the mdat is just preallocated NTFS clusters holding stale deleted-file data. That is unrecoverable by any tool. Verify the payload first.

Symptom

ffprobe 20251025075725.mp4
[mov,mp4,m4a,3gp,3g2,mj2] moov atom not found

Top-level atom walk showed the classic interrupted-recording signature:

AtomSize
ftyp32 B
free8 B
mdatsize field = 0 → “extends to EOF”

No moov. Writers stream mdat first and append moov (with avcC, SPS/PPS, and the sample table) at clean shutdown — so a crash loses the index.

The usual fix (and why it didn’t apply)

untrunc (anthwlock fork) rebuilds a missing moov by re-parsing the mdat, using a known-good reference recording from the same encoder/app to learn codec params and frame layout.

macOS packaging

As of 2026-07 Homebrew has no untrunc / untrunc-anthwlock formula. You must build from source. Don’t plan around a brew install.

Not worth it here, because the mdat had nothing to parse.

Proving the mdat is garbage — the 5 checks

1. Walk AVCC NAL units from the start of mdat

H.264 in MP4 is length-prefixed (4-byte big-endian length + NAL). Walking from mdat’s first byte:

  • NAL 1 — SEI, 686 B, containing the x264 version string ✔
  • NAL 2 — IDR slice, 68 837 B
  • NAL 3 onward — length prefix nonsensical, parse fails ✘

So only ~69 KB of real video ever reached disk.

2. Brute-force resync scan over the whole file

Scan all 1.7 GB for any chain of 4 consecutive valid NAL headers, validating:

  • forbidden_zero_bit == 0
  • nal_unit_type ∈ {1, 5, 6, 7, 8, 9, 12}
  • nal_ref_idc consistency: types 1/5/7/8 require ref != 0; types 6/9/12 require ref == 0

Zero hits. Repeated with a loose test (chain of 3, type set only, no ref check) over a 120 MB window — also zero hits.

3. Shannon entropy sampling

Sampled at 7 offsets: uniformly 7.997 bits/byte, 256 distinct byte values everywhere. Real H.264 is high-entropy but not that flat — this is the signature of unrelated compressed/encrypted residue, not a video bitstream.

Searched for moov / moof / mdat / avcC / stbl across the file. Hit count matched random chance (≈ 1.7e9 / 2^32 per 4-byte tag). No fMP4 fragments to salvage.

5. Tail check

The last 10 747 952 bytes were all zeros — freshly-zeroed, never-written clusters.

Root cause

SplitCam crashed mid-recording on Windows. NTFS preallocated ~1.6 GB of clusters; the video data was never flushed. The clusters still hold stale content from previously deleted files — hence max entropy, no structure, no NAL chains.

Only the first ~69 KB of genuine H.264 ever hit disk, and even that is undecodable: SPS/PPS live in avcC inside the missing moov.

Verifying the local copy wasn’t the problem

Trace where a downloaded file came from (macOS)

xattr -p com.apple.metadata:kMDItemWhereFroms <file> | xxd -r -p | strings

This recovered the origin URL — the Tailscale-served file browser (filestash).

Then, on the source host (telep-mainframe):

  • Source found at /mnt/win/Users/kisapus69/odi/data/SplitCam/ on the read-only ntfs3 mount
  • Compared md5 of 2 MB chunks at offsets 0 / 100 MB / 1 GB — identical to the local copy
  • Source file is equally dead; no other copies existed

Takeaway (reusable procedure)

Order of operations for a headerless MP4

  1. Walk top-level atoms — confirm moov missing, mdat size 0.
  2. Walk AVCC NAL units from mdat start. Do the first few parse?
  3. Resync-scan for chains of valid NAL headers across the file.
  4. Sample entropy; search for box tags; check the tail for zeros.
  5. Only if steps 2–3 find real NAL structure, invest in building untrunc + sourcing a reference recording.

Max-entropy payload + zero valid NAL chains = preallocated-but-never-written mdat = unrecoverable. Stop there.