Field notes
The phone went flat, the Camera app quit, or it overheated and stopped while it was
still recording. There is a video in Photos with a thumbnail that will not open, or an
IMG_1234.MOV you copied off that nothing will touch. Here is what to try,
in the order that costs you least.
Do not record anything else on that phone yet, and do not delete the video from Photos to "clear space". Work on a copy once you have one, and keep the untouched original somewhere else. Some repair tools rewrite the file where it sits, so a failed attempt can leave you worse off than the interruption did.
This step has no equivalent on any other camera, and it is where an iPhone owner most often spends their one good chance. Pull the card out of a GoPro or a Canon and the file is simply there. An iPhone keeps the recording inside the Photos library, and what you end up holding depends entirely on how you take it out.
An iPhone recording names the phone inside itself, so you can tell an original from a copy without opening anything:
strings IMG_1234.MOV | grep -m 2 iPhone
On the recordings tested here that prints the phone and the lens it used, along the lines
of iPhone 11 back camera 4.25mm f1.8. If nothing comes back, you are either
holding a converted copy or the take was cut very early; the free check below tells those
two apart, so run it before assuming the worst.
If the file is a sensible size rather than a few kilobytes, the video is almost certainly still inside it. What a phone writes last, when a recording stops cleanly, is the index saying where every frame lives. Stop before that and you have a complete recording with no map, which every player refuses to touch. That is why the thumbnail in Photos can look right while nothing will play it.
On a Mac, this tells you which case you are in:
ls -l IMG_1234.MOV strings -t d IMG_1234.MOV | grep -m 5 -E 'ftyp|mdat|moov'
ftyp and mdat present but no moov is the good
outcome: the footage is there and only the index is missing.
The detail of what that means. A file of a few
kilobytes means the footage was never written, and device level recovery software is the
only remaining route.
This runs in your browser. The file is not uploaded, and only the first and last megabyte are read, which is where the markers that decide the answer live. Works on any computer, including Windows, even though the app itself is Mac only.
This checker has its own page at cinesalve.honorboxx.workers.dev/check — easier to pass to someone else who needs it.
The index cannot be copied from another clip. It holds the exact byte position and size of every frame in your recording, so it has to be reconstructed from the raw footage itself.
untrunc is free and open source and does this job, if you are willing to compile a command line tool. Try it before paying anybody. If it will not build on your Mac, these are the errors and what they mean.
A Mac app that does the same job. Drop in the file that will not open and it rebuilds the index so the file plays again. Nothing is uploaded; it runs entirely on your Mac. $69 once.
An iPhone needs no second clip. A phone cannot know it is about to be dropped, so about ten seconds into a take iOS lays a complete index into the middle of the recording and keeps extending it as the take goes on. A take that ends normally writes its real index at the end. A take that ends in a flat battery leaves that one behind, and it is the camera's own account of what it wrote and where, so there is nothing to search for and nothing to guess at.
It is measured against real iPhone 11 recordings, HEVC 1080p, camera original and cut mid‑take. Every recovered frame and every recovered audio packet is compared against the original by byte position and size:
| Real iPhone footage, no reference clip | Frames | Sound | Decode errors |
|---|---|---|---|
| 1080p 120fps, cut at 50% | 297 / 297 | 431 / 431 | 0 |
| 1080p 120fps, cut at 60% | 297 / 297 | 431 / 431 | 0 |
| 1080p 120fps, cut at 85% | 596 / 596 | 862 / 862 | 0 |
| 1080p 29.97fps, cut at 85% | 300 / 300 | 431 / 431 | 0 |
Picture and sound both, every frame and every audio packet at the exact offset and size the phone wrote, and the repaired file decodes end to end without a single error. The index describes the take as of its last checkpoint, and the first one falls about ten seconds into a recording, so a take shorter than that has none to read: the app says so and asks for a reference clip rather than guessing. It also tells you how much footage lies past the final checkpoint.
A damaged iPhone clip is genuinely useful: it goes into the test suite and the fix ships for everyone. cinesalve@proton.me (or the contact form), with the phone and the recording mode. You will get an honest answer about whether it can be recovered, including when the answer is no, and there is no pitch attached.