Fix it now
- Drop the file
- Repair runs locally
- Download the result
The Insta360 X4 shoots 360 video up to 8K30, recording H.265 into an .insv file. An .insv is an MP4-based container carrying the dual-fisheye raw footage; at 5.7K and above the X4 packs both lens tracks into a single main .insv (older cameras wrote two). When power is lost mid-recording, that container never gets its finalized index, and Insta360 Studio refuses to import it. This tool rebuilds the MP4/.insv container in your browser so Studio can open the file again. Be clear on the division of labour: we rebuild the container — the 360 stitching and reframing still happen afterward in Insta360 Studio. We don't stitch.
Why an .insv stops importing into Studio
An .insv is a standard MP4 container underneath, so it obeys the same rule as any MP4: the index — the moov atom that maps every frame and describes the H.265 streams — is written only when the recording is finalized. Cut power to the X4 before that and you're left with a container full of real footage and no index. Insta360 Studio then reports that it can't recognise or import the media.
On a 360 action cam the interruption is usually one of these:
- The battery dies or is swapped while recording is still running.
- The card is pulled before the camera finished closing the file.
- An impact or a hot-shutdown ends an 8K recording early — the highest-bitrate mode is the most fragile.
One X4-specific wrinkle: because 5.7K+ footage keeps both fisheye tracks inside one main .insv, a single unfinalized file is the whole recording. Studio also expects the sidecars alongside it — the low-res .lrv proxy in particular — so don't rename or move the files; keep the set together in one folder.
What the rebuild does — and what Studio does after
The rebuild scans the surviving H.265 data in the .insv and reconstructs the sample tables and index the camera never wrote, producing a container that opens again. That's the part standard players and repair tools choke on. It is not a stitch: the file still holds dual-fisheye raw, so once it opens you take it back into Insta360 Studio to stitch, reframe, and export the flat video you actually share. Think of it as getting the door open — the editing room behind it is still Studio's.
Because the streams are H.265 with the X4's particular 360 layout, a healthy .insv from the same X4 in the same shooting mode (same resolution, same encoding) is the best possible reference: it carries the exact stream configuration the broken file is missing, which is the same principle Insta360's own File Repair tool uses when it asks for a reference from the same camera and settings. Grab any normal clip shot in the same mode and keep it ready — you'll be asked for it only if the file needs it.
Why not to upload 360 footage
360 capture is uniquely exposing — it records everything around the camera, in every direction, so a single .insv can hold far more of a place and the people in it than a framed shot ever would. X4 files are also large: 8K H.265 runs to gigabytes per clip, making an upload slow as well as revealing. Upload-based repair sites take a full copy onto servers you can't inspect, under terms you didn't write.
Here the container rebuild runs entirely in your browser: the .insv is read from your disk, rebuilt in the tab, and saved back. Nothing is transmitted, and you can verify it — open the Network tab and watch 0 bytes leave your machine. Then you finish the job locally in Insta360 Studio, so the footage never leaves your control at any stage.
What this can and can't fix
Can fix
- An .insv that won't import into Insta360 Studio after a power loss or card pull (unfinalized container)
- 8K / 5.7K X4 clips that open as corrupt or zero-length in every player
- Container damage inside the MP4-based .insv: missing index, wrong offsets, truncated tail, when the H.265 data survived
- Files where Insta360's own File Repair couldn't finish but the encoded footage is intact
Can't fix
- The 360 stitch, reframe, or flat export — that's done in Insta360 Studio after the container is rebuilt
- Footage physically lost to a failing or corrupt microSD card — recover the card first, then repair
- A file that reads as 0 bytes or mostly zeros (nothing to rebuild from)
- A missing .lrv proxy or renamed sidecar — keep the original file set together so Studio can find its partners
If a repair fails, we tell you why (missing data versus broken structure), and you are never charged for a failed repair.