HERO11 Black .LRV (moov atom missing) - untrunc reconstructs container but

[Wendelin]

Camera: GoPro HERO11 Black. Firmware: H22.01.02.30.00. Camera serial (from file header): C3471324558318.

Problem: A recording lost its moov atom (classic "moov atom not found" - the file has ftyp + a single huge mdat, no index). The file is 7,207,669,851 bytes (7.2 GB), currently named f25799168.LRV (renamed during export/download, so I can't confirm the original GoPro filename/chapter number). No SD card or other copy exists - this is the only copy.

What I've confirmed so far: Right after the mdat header, there's ~1600 bytes of GoPro's proprietary session-info block ("GPRO" magic, firmware string, camera serial, then strings like HERO11 Black / NATURAL / STANDARD / STEREO / REAL_SPEED / PERFORMANCE / MANUAL / NO_LIMIT etc.) before any actual codec data starts.

Using a working reference file from the SAME camera (a normal chaptered GX010051.MP4, HEVC/hvc1, 3840x2160, 29.97fps, tracks: gpmd+hvc1+tmcd, no audio), I confirmed via untrunc that the broken file is also HEVC (Main profile), and by manually parsing an HEVC SPS NAL found inside the broken file's own mdat (not from the reference's moov), the real resolution checks out as 3840x2160 too - so this isn't a low-res proxy encode, it's full 4K, despite the .LRV extension.

I sampled Shannon entropy at 16 different offsets spread across the entire 7.2 GB (every ~500MB) - entropy is ~7.99-8.0 bits/byte everywhere, no zero-filled or repeating regions anywhere in the file. The payload data itself appears fully intact end to end; only the index is missing. Estimated real duration from bitrate (~94 Mbps, matching the reference file's bitrate) and file size: roughly 10 minutes.

What I tried (untrunc, anthwlock/untrunc fork, built from source on macOS against ffmpeg 9.0.1):

- "untrunc -s -sm ref.mp4 broken.LRV" (with the real camera reference above) completes and reports "Found 18935 packets (gpmd: 836 hvc1: 18098 hvc1-keyframes: 565 tmcd: 1)", i.e. it looks like it recovered the whole ~10 minutes with 565 keyframes.

- In reality, only the very first frame (an IDR right after the GPRO header block, ~offset 1607 into mdat) decodes cleanly in ffmpeg/VLC-style decoding. Every frame after that fails with a consistent pattern of HEVC decode errors: "PPS id out of range: 242", "SPS 2 does not exist", "PPS changed between slices", later "Could not find ref with POC N" / "First slice in a frame missing".

- Tried: default step size (already 1 byte, i.e. finest possible scan), -k (keep unknown sequences), -dcc (don't check chunks inside mdat), -dr (dump raw tracks), forcing ffmpeg to decode through errors (-max_error_rate 1.0, single-threaded). None of these get past frame 1 - either identical frozen output (error concealment repeating frame 1) or a hard decoder abort somewhere in the first ~100-200MB.

- Tried a synthetic H.264 reference and a synthetic HEVC reference (ffmpeg-generated, no real GoPro structure) first, before I had a real reference file - those failed immediately with 0 keyframes found, so I don't think this is a resolution/profile mismatch problem; it looks like untrunc's generic byte-stepping heuristic (-s) just can't reliably re-sync to real sample boundaries within GoPro's interleaved gpmd/hvc1/tmcd chunk layout after the first GOP, even at 1-byte step granularity.

What I'm hoping someone can help with:

1) Does anyone know the actual byte-level interleaving pattern GoPro uses in mdat for HERO11 Black HEVC recordings (chunk header/marker bytes, fixed chunk sizes or alignment, order of gpmd/hvc1/tmcd samples) that would let a tool correctly walk sample boundaries without relying on stsz/stco from a healthy moov?

2) Is there a GoPro-specific fork/patch of untrunc, or another tool, that specifically handles this interleaving (rather than the generic byte-stepping "-s" fallback)?

3) Any recommendation for a data-recovery service that has actually dealt with this exact GoPro HEVC mdat structure successfully?

Happy to share the untrunc build, logs, or any additional byte-offset dumps if that helps someone dig in. The payload data is confirmed intact for the full 7.2 GB, so I believe this is fully recoverable in principle - I just don't have the tooling to nail the per-sample framing beyond frame 1.

[ProWo]

Try with this one:
https://www.videohelp.com/software/MP4-Repair-untrunc-GUI

Create a new video with the same camera and the same settings (resolution, fps aso) as reference file.

In the app settings set skip unknown


[Attachment 93822 - Click to enlarge]

Then click repair.