Manatee

Insta360 .insv files will not open on a Mac. What they actually are

· 6 min read

You copy footage off an Insta360 camera and the Mac shows files ending in .insv. Double-clicking does nothing useful. QuickTime refuses them, Preview shows no thumbnail, and the Finder treats them as documents of unknown type.

The files are not damaged. They are a standard video container with a non-standard extension and unusual content inside, and understanding both halves tells you what you can and cannot do with them.

What is actually in the file

An .insv file is an MP4. Renaming it to .mp4 is enough to make most players attempt it, and you can confirm the structure without renaming anything:

ffprobe -v error -show_entries format=format_name,duration \
  -show_entries stream=index,codec_type,codec_name,width,height \
  -of default=noprint_wrappers=1 VID_001.insv

You will typically see format_name=mov,mp4,m4a,... and one or two H.264 or HEVC video streams. The extension is the camera manufacturer’s marker, not a different format.

The complication is what those streams contain. A 360 camera has two fisheye lenses pointing in opposite directions, and the raw recording is the two circular images side by side. Play it and you see two distorted hemispheres rather than a scene. That is correct output for the file, and it is not what anyone wants to watch.

Turning the two fisheye images into a single spherical or flat video is stitching, and it requires knowing the precise lens geometry and calibration of the specific camera model. That information is in the metadata the manufacturer writes, and general-purpose tools do not interpret it.

The practical consequence

You can play, convert and compress an .insv file with ordinary tools. You cannot stitch it with them. If your goal is a normal-looking video, stitching has to happen in the manufacturer’s own software, or in the camera app on a phone, and that step comes first.

So the order is:

  1. Stitch in the manufacturer’s app, exporting a normal MP4.
  2. Do everything else (trimming, compressing, converting) with whatever you prefer.

Trying to skip step one and work on the raw file directly is where most of the frustration in this comes from.

Getting a look at the file before stitching

If you simply want to check that footage recorded correctly before committing to a stitching workflow, rename a copy and play it:

cp VID_001.insv /tmp/check.mp4
open /tmp/check.mp4

Work on a copy rather than renaming the original, since the camera’s software may rely on the extension to recognise its own files.

You will see the dual fisheye view. Distorted, but enough to confirm the exposure was right and the recording is not empty.

Why there are often two files per recording

Higher resolution modes record the two lenses into separate files, so one take arrives as a pair with matching names and different suffixes. Both are needed for stitching, and copying only one leaves the software unable to proceed.

There is also a low-resolution proxy file recorded alongside for preview purposes, which is much smaller. If a file is unexpectedly tiny, that is what it is. Keep the whole set together when copying off the card.

When the file genuinely will not open

Everything above assumes a healthy recording. Distinguish that from actual damage with the same test you would use on any video:

ffprobe -v error -show_entries stream=codec_type,duration \
  -of default=noprint_wrappers=1 VID_001.insv

A healthy file reports a duration. A file that reports none, or that errors out, has lost the index that maps frame positions, which happens when a battery dies mid-recording or a card is pulled while writing.

That failure mode is worth understanding because it is common with action cameras. In an MP4, the picture data sits in an mdat block and the index sits in a moov block, and cameras write moov last because the index cannot be completed until the recording stops. Inspecting a healthy file shows the order:

ftyp → free → mdat (the video data) → moov (the index)

Interrupt the recording and you keep all the frames and lose the map to them. The file is large and unplayable at the same time, which is why people assume it is empty when it is not.

Manatee rebuilds that index from the surviving frame data and writes a clean copy, working from a duplicate so the camera original is never modified. It will not stitch a 360 file, since that needs the manufacturer’s lens calibration, but a repaired .insv can then go into the stitching app that previously rejected it. Repairing a corrupted GoPro or drone video covers the same failure on other action cameras.

Compressing the result

Stitched 360 footage is large, because the equirectangular frame that holds a full sphere needs high resolution to look acceptable when only part of it is on screen at once. A stitched export at 5.7K is substantially bigger than ordinary 4K.

Once stitched, it is a normal video file and normal compression applies. Preserve the spherical metadata when you convert, or players will treat the result as a flat video and the interactive view stops working:

ffmpeg -i stitched.mp4 -c:v libx265 -crf 28 -tag:v hvc1 \
  -c:a copy -movflags use_metadata_tags -map_metadata 0 smaller.mp4

-map_metadata 0 carries the source metadata across. Check afterwards that the spherical tags survived, since a player that has lost them shows a strangely warped rectangle rather than an interactive view.

Questions

Can I just rename every .insv to .mp4 and be done? For playback and inspection, yes. For a usable video, no, because the content is still dual fisheye. Renaming solves the opening problem and not the watching problem.

Why does Preview show no thumbnail? macOS generates thumbnails based on file type, and .insv is not a type it knows. Renaming a copy to .mp4 restores thumbnails for that copy.

The stitching software says the file is invalid. Usually one of three things: the paired file is missing, the recording was interrupted so the index is gone, or only the proxy was copied. Check that you have the complete set from the card, then test with ffprobe for a valid duration.

Is it worth keeping the original .insv files after stitching? If storage allows, yes. Stitching software improves, and a re-stitch from the original produces a better result than anything you can do to an already-stitched export. The originals are the negatives.