I see this question come up over and over (and over and over) again on discussion groups (Facebook, REDDIT, etc.). Folks see “8K camera” or “5.7K camera” and expect that will be better than an HD camera or 4K camera.
But not with a 360 camera.
With a normal camera, you have a lens recording a square/rectangular image. An HD camera will record an image that is 1920×1080 pixels. Those pixels are used for the entire square/rectangular image.
But, a 360 camera with two lenses takes its resolution and divides that by two — one for each lens. An 8K Insta360 X4 camera is therefore shooting a 4K image out the front lens, and a 4K image out the back.
BUT, instead of shooting straight ahead, it is a wide angle fisheye style image that is actually capturing everything in front, above, below, to the left and right of that lens. The back lens is doing the same.
When you think of it that way, the number of pixels that would be for the “forward” view is a fraction of the pixels you would get with a normal non-fisheye single lens camera.
Here is my quick doodle:
Now, reality is actually much more complex than this simple drawing, but the end result is you an “reframe” 360 footage to be a view in any direction. If you only use those six main directions (forward, backwards, left, right, up and down), you are dividing the pixels of that 8K image in to 6 smaller images. If 8K video is 7680 × 4320, then each view is closer to 1280×720 — which you can see is below “full HD” of 1920×1080.
So even with an 8K 360 camera, what you get in any specific direction is still not going to be as good as a simple HD camera that only records in one direction.
(And yes, I know the reality is much more complex, but this is just greatly simplified to help new users visualize how it works.)
The latest 360 camera from Insta360 has been released today. You can watch their Apple-like presentation here:
I became intrigued with 360 photography quite some time ago. Apple QuickTime VR was the first time I ever saw it, and that software allowed taking a bunch of photos in different directions and splicing them together in to on virtual reality image that let you look in any direction. That started back in 1995 though I did not learn about it until a bit later.
I got my first digital camera in 1996, and experimented with panoramic “stitcher” programs that let me stand in one location and take photos in all directions then stitch them together to make a large panoramic image. This is why you can find odd “panorama” folders in my only photo galleries, like this one from 2002:
This led me to experiment with “one shot 360” systems, such as the SurroundPhoto attachment I owned. It was a half-mirror ball on a stick that mounted to a camera, then you took the photo pointing up, capturing all 360 around you. Software would later de-warp this in to a 360 image that allowed you to look in all directions, including limited up/down.
Here is an example of a 360 photo taken using the SurroundPhoto attachment:
I was excited to later learn of a new 360 camera that had three camera lenses and promised to take these types of images in one shot, without any post-processing or klunky add-ons. I backed the 360cam on Kickstarter, and that was quite the fiasco, taking so long to actually ship that other companies such as Kodak and RICOH came out with their own (and cheaper) units.
Over the years, I have owned:
360Cam
Kodak SP360
RICOH Theta
RICOH Theta S
Insta360 X2
Insta350 X3
…and maybe one or two others I have fogotten about.
In the early years, Insta360’s “ONE X” had inferior quality compared to the RICOH, but it had more “fun” features and effects that could be applied via the app. At the time, I did not want a device that needed an app. I just wanted to take photos and download.
RICOH remained the king of 360, with the best photo quality in their $1000-priced Theta Z model, but I was not interested in spending that kind of money on a better 360 camera.
I ended up with an Insta360 X2 and installed found it the funnest camera I had ever owned. I used it more than all the previous 360 cameras I had owned, combined. When the X3 came out, I upgraded to get improved photo/video quality.
The X4 is a slightly larger and heavier camera, but adds 8K recording, and thus needed a larger battery. With the release of X4, paid ads (er, “review videos”) have popped up all over YouTube telling us how great it is. After the X3 release, I learned many of these “review videos” were misleading – stating facts that were incorrect (either lying, or just uninformed), or mentioning how great a new feature was that — we later found out — did not even work in the beta firmware the “reviewers” were using.
We’ll see if the X4 lives up to the hype.
With the X3 price down for $399, I highly recommend it as a fun camera. For $100 more, the X4 may be worth it — but I’d wait a few months and see what real users think about it.
When you export 360 video to a format that can be uploaded to YouTube, Facebook, or other online service that supports 360 video, you get a wide, warped video file that looks like this:
For the Insta360 ONE X2 and X3 cameras, the front facing camera (the one opposite of the preview screen) will be the focal point of the video. In this case, it’s the entrance of the Whalebone Grill in the Awa (water) realm of the new-for-2022 Lost Island Themepark in Waterloo, Iowa. (This new park is pretty amazing with its backstory and unique themes.)
But, what if you wanted the 360 view to default to a different view when first played? Unfortunately, the Insta360 mobile app and desktop apps do not provide a way to do this (currently; folks have been asking about it for years, so maybe one day…). Often, the advice is to put the video in a video editor like Premier or Final Cut Pro and change it there.
Some quick web searching led me to this REDDIT post with a comment from user glitch007 explaining a way to use the free ffmpeg utility to reprocess 360 video and set the initial view:
ffmpeg has command line options to specify the X/Y adjustments (yaw and pitch) for the 360 video export. You can import the original MP4 file and export it out as a new MP4 with the view changed. If, for example, I wanted my Whalebone Grill video to start with folks facing the seating area, I could change that and it would look like this:
In this example, “yaw=90” tells it to change the X view by 90 degrees. You could pass in 180 to make the video face the opposite direction. The “pitch” controls the looking up and down, and “roll” controls tilt (I believe; I haven’t actually tested it).
e … Equirectangular projection (the type of 360 format the video is in).
yaw / pitch / roll … Set rotation for the output video. Values in degrees.
glitch007 shared a timesaver where you specify a start and end section of the video and can quickly process just a snippet so you can see the results before doing the entire video. Using “-ss” sets the starting section, and adding “-to” lets you specify the ending second:
If you run that, you’d get a 5 second clips covering seconds 3 to 8 of the video, and could look at that and see how the view is. This allows quickly making changes to yaw/pitch/roll to get what you want.
I used the ffmpeg command line utility to do this, but there may be Windows/Mac programs that put a graphical user interface on it, making it easier for folks to use. If you know of a good one, please leave a link in the comments.
Over on REDDIT, the subject of the gaping Insta360 WiFi security hole has come up again. User K1N6P1X3l linked to this recent article that summarizes the issue’s history:
Of course, the majority of users simply will not care. “It’s very unlikely to happen to me,” they say. “And if it does, so what, they get my photos.”
In other words, this is just like any other security issue out there. Some folks treat them seriously and take steps to avoid the problems, and others just don’t care. If it were not for the “don’t care” crowd, we wouldn’t have such great malware, viruses and ransomware :)
The exploit allows anyone within WiFi range the ability to connect to your camera and do “stuff.” According to the PetaPixel article, Insta360 has already plugged some of this:
Currently the list_directory has already been terminated and it is no longer possible to access the camera content through the browser.
– Insta360 response, per PetaPixel article
Unfortunately, this is not true. Using the current available firmware, v1.0.59_build1, on my ONE X2 I see it appear on WiFi as expected:
…and if I select this interface, and then open the URL in a browser, I find all my files are indeed able to be listed:
I can then click on one of the .insv video files and play it (or save off a copy):
“And it’s just that easy!”
With this camera, there is no privacy because the camera is broadcasting itself to any WiFi devices around it, and allowing any of them to connect without authentication and then browse and view/download anything on the microSD card.
What’s worse is you can also telnet in to the device. I tried that to see if it still worked:
You will notice it did not ask for a password here, either.
Both of these screenshots (web browser and telnet) were done on my iPad.
WHILE I was connected to my X2 via the iPad, I then connected a Windows PC. Using the default password of “88888888” I was now connected from two devices (which for some reason folks think isn’t possible). Both my Windows PC and my iPad were connected and able to access the files from a web browser.
At least two firmware updates have come out since this first appeared on REDDIT, and it does not appear anything has changed.
ScrewX2: The proof-of-concept that a script kiddie could have written
Shortly after this exploit was first mentioned, someone could have easily created a script that would look for WiFi hotspots following the name “ONE X2 xxxxx” and connect to them. The script could then issue http GET commands to retrieve files on the memory card, or telnet in to delete things, potentially bricking the camera.
Worse, the script could deliver a payload of malware, and if the user ever mounted that memory card in a computer, the malware could have been ran accidentally. Hopefully most of us will never run some random executable or installer found on a camera memory card, but it would be tempting to try to find out what “360VIEWER.EXE” does, or “Insta360MacConverter.dmg” is.
I will not link to any such “screwx2” script, and will delete any links to such posted in the comments here. The cat is firmly out of the bag, with the default WiFi password known, and NO password on the web interface or telnet, so all we can do is hope that Insta360 addresses this issue eventually.
2022-06-09 – Added link to ExifTool source code that parses these sections. ExifTool command line example. Updated output of parser showing the MakerNotes fields. Adding crappy brute force C test code. Added hex dump screen shots of the sections.
*** WORK-IN-PROGRESS ***
I am posting this now in case it helps someone else who is trying to figure this out. My goal is to be able to modify a video recorded in Bullet Time mode to appear as a normal 360 video file. I just need to figure out what bytes to zap in the file…
It contains a Python script that parses the .insv files to export accelerometer and exposure data. This gave me a good starting point for exploring the .insv file format.
From there, searches led me to the ExifTool by Phil Harvey, which has support for parsing .insv files. Here is the parsing code:
The trailer is a series of (up to seven?) entries containing a 2-byte ID followed by a 4-byte offset. I am unsure if the entries are fixed, or if they can be terminated by 0x0000 / 0x00000000 entries if not all segments appear.
.insv file contents.
Segments defined in the Github Python script include:
Parsing begins at offset -78 by reading the 2-byte ID and 4-byte Size. The data for that ID will be located Size bytes earlier in the file. Data parsers for each segment seek there and begin parsing.
ExifTool
I have now found that ExifTool can be used to display these items. It does not show the Trailer information by default, but here is a command that displays it in .json format:
exiftool -ee -G -s -b -j -a -T filename.insv
Maker Notes – ID 0x0101
WORK-IN-PROGRESS: The “maker notes” section appears to use a byte for the type of data, then a byte for the length of that data segment. Some of the bytes appear to be (QuickTime::INSV_MakerNotes)
Hex Dec Description
--- --- -----------
0x0A 10 Serial Number ("IXSE42xxxxxxxx")
0x12 18 Camera Model ("Insta260 ONE X2")
0x1A 26 Firmware Version ("v1.0.51_build1")
0x2A 42 ? Parameters ?
NOTE: It appears that this section (0x0101) may be hard-coded to only have four entries, and the parser just reads four entries and stops. I was expecting some kind of record size or end of record marker, but looking at the ExifTool source shows it just does a for/next loop of 0-3.
Serial Number
Model
Firmware
Parameters
A simple parser I wrote in C can parse out some of these, then it gets lost at the binary data, so there is more to it than just that:
Magic Phrase: 8db42d694ccc418790edff439fe026bf
Good file.
0x0101 0x0000073a - Maker Notes
-------------------------------------------------------------------------------
Maker Notes - offset -1928
-------------------------------------------------------------------------------
Type: 0x0a (10) - SerialNumber
Length: 0x0e (14)
Data: 49 58 53 45 34 32 xx xx xx xx xx xx xx xx (edited out)
Text: IXSE42xxxxxxxx (edited out)
Type: 0x12 (18) - Model
Length: 0x0f (15)
Data: 49 6e 73 74 61 33 36 30 20 4f 4e 45 20 58 32
Text: Insta360 ONE X2
Type: 0x1a (26) - Firmware
Length: 0x0e (14)
Data: 76 31 2e 30 2e 35 31 5f 62 75 69 6c 64 31
Text: v1.0.51_build12
Type: 0x2a (42) - Parameters
Length: 0x71 (113)
Data: 32 5f 31 34 37 33 2e 36 38 30 5f 31 35 32 32 2e
39 39 30 5f 31 35 34 34 2e 35 36 30 5f 30 2e 30
33 32 5f 2d 31 2e 30 39 33 5f 2d 31 37 38 2e 30
31 30 5f 31 34 37 35 2e 34 35 30 5f 34 35 35 34
2e 30 39 30 5f 31 35 30 33 2e 36 32 30 5f 2d 30
2e 30 32 39 5f 2d 31 2e 32 39 37 5f 2d 30 2e 37
36 38 5f 36 30 38 30 5f 33 30 34 30 5f 33 31 31
33
Text: 2_1473.680_1522.990_1544.560_0.032_-1.093_-178.010_1475.450_4554.090_1503.620_-0.029_-1.297_-0.768_6080_3040_3113
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x000f16f4 - Unknown
More work to be done on this part…
Accelerometer Data – ID 0x0300
TODO
Exposure Data – ID 0x0400
TODO
Timestamps – ID 0x0600
TODO
GPS Data – ID 0x0700
TODO
To be continued…
Crappy Brute-Force C Parsing Test Code
/*--------------------------------------------------------------------------*/
// .insv parser test.
//
// 2022-06-08 0.00 allenh - Initial brute-force version.
// 2022-06-09 0.01 allenh - Code cleanup, more defines.
/*--------------------------------------------------------------------------*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h> // for memset()
#include <stdint.h>
#include <stdbool.h>
#define FILENAME "VID_20220607_102410_00_322.insv"
//#define FILENAME "VID_20220607_104109_00_323.insv"
/*--------------------------------------------------------------------------*/
// Defines / Constants / Enums
/*--------------------------------------------------------------------------*/
#define TRAILER_OFFSET -78
#define TRAILER_SIZE 42
#define MAGIC_PHRASE_OFFSET -32
#define MAGIC_PHRASE_SIZE 32
#define MAGIC_PHRASE_STRING "8db42d694ccc418790edff439fe026bf"
enum
{
HID_MAKER_NOTES = 0x0101,
HID_ACCELEROMETER = 0x0300,
HID_EXPOSURE = 0x0400,
HID_TIMESTAMPS = 0x0600,
HID_GPS = 0x0700
} HidEnum;
enum
{
MAKER_NOTES_SERIALNUMBER = 0x0a,
MAKER_NOTES_MODEL = 0x12,
MAKER_NOTES_FIRMWARE = 0x1a,
MAKER_NOTES_PARAMTERS = 0x2a
} MakeNotesEnum;
/*--------------------------------------------------------------------------*/
// Prototypes
/*--------------------------------------------------------------------------*/
bool checkForMagicPhrase (FILE *fp);
bool parseTrailer (FILE *fp);
bool parseMakerNotes (FILE *fp, long int offset);
const char *getHidString (unsigned int hid);
const char *getMakerNotesString (unsigned int id);
uint32_t freadU32 (FILE *fp);
uint16_t freadU16 (FILE *fp);
uint8_t freadU8 (FILE *fp);
void hexDump (void *ptr, size_t size);
/*--------------------------------------------------------------------------*/
// Main
/*--------------------------------------------------------------------------*/
int main (int argc, char **argv)
{
(void)argc;
(void)argv;
FILE *fp = NULL;
fp = fopen (FILENAME, "rb");
if (fp != NULL)
{
if (checkForMagicPhrase (fp) == true)
{
printf ("Good file.\n");
parseTrailer (fp);
}
}
else
{
perror ("Unable to open");
}
fclose (fp);
return errno;
}
/*--------------------------------------------------------------------------*/
// Functions
/*--------------------------------------------------------------------------*/
/*--------------------------------------------------------------------------*/
// Check for the 32-byte magic phrase at the end of the file.
/*--------------------------------------------------------------------------*/
bool checkForMagicPhrase (FILE *fp)
{
bool status = false;
if (fp != NULL)
{
int retVal = 0;
retVal = fseek (fp, MAGIC_PHRASE_OFFSET, SEEK_END);
if (retVal == 0) // If successful, the function returns zero.
{
size_t bytesRead = 0;
char buffer[MAGIC_PHRASE_SIZE+1];
memset (buffer, 0x0, sizeof(buffer));
bytesRead = fread (buffer, sizeof(buffer[0]), MAGIC_PHRASE_SIZE, fp);
if (bytesRead == MAGIC_PHRASE_SIZE)
{
if (strncmp (buffer, MAGIC_PHRASE_STRING, sizeof(buffer)) == 0)
{
// Match.
printf ("Magic Phrase: %s\n", buffer);
status = true;
}
}
}
}
return status;
}
/*--------------------------------------------------------------------------*/
// Parse Trailer.
/*--------------------------------------------------------------------------*/
bool parseTrailer (FILE *fp)
{
bool status = false;
if (fp != NULL)
{
int retVal = 0;
long int offset = 0;
offset = TRAILER_OFFSET;
while (offset < TRAILER_OFFSET+TRAILER_SIZE)
{
retVal = fseek (fp, offset, SEEK_END);
if (retVal == 0)
{
uint16_t hid = 0;
uint32_t size = 0;
hid = freadU16 (fp);
size = freadU32 (fp);
printf ("0x%04x 0x%08x - %s\n", hid, size, getHidString (hid));
switch (hid)
{
case HID_MAKER_NOTES:
parseMakerNotes (fp, offset-size);
break;
}
offset = offset + sizeof(uint16_t) + sizeof(uint32_t);
}
}
}
return status;
}
/*--------------------------------------------------------------------------*/
// Parse INSV_MakerNotes section.
/*--------------------------------------------------------------------------*/
bool parseMakerNotes (FILE *fp, long int offset)
{
bool status = false;
uint8_t type = 0;
uint8_t length = 0;
size_t bytesRead = 0;
uint8_t buffer[255];
printf ("-------------------------------------------------------------------------------\n");
printf ("Maker Notes - offset %ld\n", offset);
printf ("-------------------------------------------------------------------------------\n");
// There can be only four?
for (int entryNumber=0; entryNumber < 4; entryNumber++)
{
if (offset >= TRAILER_OFFSET) // Hack.
{
break;
}
fseek (fp, offset, SEEK_END);
type = freadU8 (fp);
length = freadU8 (fp);
printf (" Type: 0x%02x (%u) - %s\n", type, type, getMakerNotesString (type));
printf ("Length: 0x%02x (%u)\n", length, length);
bytesRead = fread (buffer, sizeof(uint8_t), length, fp);
if (bytesRead == length)
{
printf (" Data: ");
hexDump (buffer, length);
printf (" Text: %s\n", buffer);
}
offset = offset + length + sizeof(uint8_t) + sizeof(uint8_t);
printf ("\n");
}
return status;
}
/*--------------------------------------------------------------------------*/
// Return pointer to string for Hid.
/*--------------------------------------------------------------------------*/
const char *getHidString (unsigned int hid)
{
const char *ptr = "Unknown";
switch (hid)
{
case HID_MAKER_NOTES:
ptr = "Maker Notes";
break;
case HID_ACCELEROMETER:
ptr = "Accelerometer";
break;
case HID_EXPOSURE:
ptr = "Exposure";
break;
case HID_TIMESTAMPS:
ptr = "Timestamps";
break;
case HID_GPS:
ptr = "GPS";
break;
}
return ptr;
}
/*--------------------------------------------------------------------------*/
// Return pointer to string for MakerNotes ID.
/*--------------------------------------------------------------------------*/
const char *getMakerNotesString (unsigned int id)
{
const char *ptr = "Unknown";
switch (id)
{
case MAKER_NOTES_SERIALNUMBER:
ptr = "SerialNumber";
break;
case MAKER_NOTES_MODEL:
ptr = "Model";
break;
case MAKER_NOTES_FIRMWARE:
ptr = "Firmware";
break;
case MAKER_NOTES_PARAMTERS:
ptr = "Parameters";
break;
}
return ptr;
}
/*--------------------------------------------------------------------------*/
// Read U32, convert and return.
/*--------------------------------------------------------------------------*/
uint32_t freadU32 (FILE *fp)
{
uint32_t val = 0;
uint8_t a,b,c,d;
a = freadU8 (fp);
b = freadU8 (fp);
c = freadU8 (fp);
d = freadU8 (fp);
val = (a) | (b << 8) | (c << 16) | (d << 24);
return val;
}
/*--------------------------------------------------------------------------*/
// Read U16, convert and return.
/*--------------------------------------------------------------------------*/
uint16_t freadU16 (FILE *fp)
{
uint16_t val = 0;
uint8_t msb = 0;
uint8_t lsb = 0;
msb = freadU8 (fp);
lsb = freadU8 (fp);
val = (msb << 8) | (lsb);
return val;
}
/*--------------------------------------------------------------------------*/
// Read U8.
/*--------------------------------------------------------------------------*/
uint8_t freadU8 (FILE *fp)
{
uint8_t val = 0;
val = fgetc (fp);
return val;
}
/*--------------------------------------------------------------------------*/
// Dump bytes as HEX, with a tab at the start of lines after the first.
/*--------------------------------------------------------------------------*/
void hexDump (void *ptr, size_t size)
{
int col = 1;
if (ptr != NULL)
{
for (int idx=0; idx<size; idx++)
{
printf ("%02x ", ((uint8_t*)ptr)[idx]);
if ((col % 16) == 0)
{
printf ("\n\t");
col = 0;
}
col++;
}
printf ("\n");
}
}
// End of main.c
I am posting this in case someone else is doing the same searches I am.
I am trying to find details on the Insta360 ONE X2 file formats for photos (.insp) and videos (.insv). They contain meta-data I’d like to be able and parse to determine what kind of files they are. Going by filename is not enough.Th
This came up again today when someone contacted me with a ONE X2 video that was recorded in Bullet Time mode. It was not meant to be, but because the file is saved that way, the Insta360 Studio program will not allow reframing/editing the video.
Insta360 support (via app chat) has an auto responder if you ask about changing Bullet Time files to normal videos, so they have a way to do it — if you send them the files.
In the case of Bullet Time, is is recorded at 100 fps in 3K mode. It stores both lens videos in the same file. This is the same format used when recording normal 360 video at 3K / 100 fps. It appears only the meta-data is making the file appear one way or the other.
If you have found any bugs, please leave a comment with the version and details and I will add them to this list. As workarounds are discovered, I will update this list.
As a new version of firmware is released, these bugs will be re-tested. When they work for some, and not for others, a note will be added to that effect.
ONE X2
2022-04-26 – v1.0.51
Open WiFi – a poorly implemented WiFi system has the camera broadcast itself as a WiFi hotspot to anyone within range, and allows users that know the default WiFi password all X2 cameras have to access and download any files on the memory card from a web browser… or worse. (Suggested by commenter, yt)
Screen Auto Sleep – 5s timeout regardless of settings. Sometimes “1min” and “Never” appear to work, but screen keeps reverting back to around 5s before going black. (Originally reported in 1.0.41_build1)
USB-c connection to iPad Pro unstable. Currently is not allowing files to be downloaded. Tested with an iPad Pro (11-inch) (3rd generation). (Reported in 1.0.51)
GPS Smart Remote
1.0.8.2
“Camera’s remaining battery” always shows empty, regardless of charge level of camera. Battery indicator for GPS Smart Remote seems to be working.
2023-05-07 – I do plan to document the X3 files. They are slightly different, including a “.insp.gyro” file that I never saw on the X2. They also add an “.lrv” extension (so you have a file that starts with “LRV_” and ends in “.lrv”). If you have found any documentation on the changes, please let me know in the comments.
WORK-IN-PROGRESS
This is a work-in-progress document with much more to be added. There are probably mistakes in it, currently. Please comment with any corrections you may have.
TODO:
Table showing all the various photo and image combinations (HDR, fps settings, PRO/BASIC, etc.)
Example files to download.
Conversion tips for .insp to jpeg and PRO to video files.
.insprj project file info (from Insta360 Studio desktop app)
…and more…
The Insta360 ONE X2 camera can take photos and videos in a variety of formats:
X2 Photo Formats (Standard, HDR, Burst, Interval or Night Shot)
You can see that .dng raw files and .insp image files use the same “00” code for single back lens images and 360 images that use both lenses. Insta360 has suggested using the file size to know if the image contains just one back lens image or both lens images.
360 Image File Examples (.insv)
NOTE: You can preview a .insv file by adding the extension “.mp4” to the end. In this example, I took all my .insv files and renamed them to “filename.insv.mp4” (so I could preserve the original extension in the filename). That allowed me to preview them in GraphicsConverter on the Mac.
You will see there should be an “LRV_yyyymmdd_hhmmss_xx_nnn.insv” file which is a low res preview movie containing both the front and back camera, then two “VID_” files with the same date/time and number, with one having 00 for the back camera and the other having 10 for the front camera:
Insat360 360-Degree .insv video (LRV low-res both cameras, VID back and front cameras).
The LRV_ files are only used by the Insta360 Studio program.
Timelapse 360 Example (.insv)
However, a time-lapse .insv recording will not have a LRV_ version. Here are two .insv time-lapse files for the same recording. 00 for the back camera, and 10 for the front camera:
Insta360 360-Degree .insv video (VID back and front camera).
150-degree Example (.mp4)
The camera will save two files: a low resolution LRV_ file with 01 if it used the back camera or 11 if it used the front, and a full size VID_ file with 00 for the back camera or 10 for the front:
Insta360 150-Degree .mp4 Timelapse video (LRV low-res, and VID full size).
360 Image Example (.insp)
The camera will record one .insp file which contains both the front and back camera images.
Insta360 360-Degree .insp photo.
150-Degree Image Example (.insp)
The camera will record one .insp file which contains either the front camera image (10) or back camera image (00):
How can a popular consumer product have a hard-coded WiFi password that gives access to all your photos and videos? Even worse, how can it have a non-encrypted telnet server (which even Windows and macOS have removed) that lets one log in as the root user without needing a password?
Since this information has been public for at least almost a year, and the problem remains in the most recent firmware update (dated 1/22/2022 as of this writing), either Insta360 is unaware of the problem or doesn’t think it is a problem.
Either way, I think I’m going to change the root password on mine, and a REDDIT reply says you can change the WiFi password if you don’t mind manually connecting WiFi to the camera each time.
Baby steps.
Until next time…
Additional Details
WiFi password is reportedly generated by Bluetooth, and ends up in a temporary file created each time:
/tmp/wpa_supplicant.conf
The script that generates this file is in /usr/local/share/script/
There, I see places where AP_PASSWD is set, overwriting a default of 1234567890 listed in wifi.conf/wifi.ap.conf.
ap_start.sh may be the one (AP = access point).
I will share details on if there is any easy way to alter the password from the default, assuming the Insta360 app allows that. My thought is generating a new file on startup and making it read-only so the app cannot overwrite it.
2/17/2022 – Added some Bullet Time Bundle details.
4/26/2022 – Added the new Power Selfie Stick.
4/18/2024 – Added new sticks.
Why are there so many? What are the differences? Let’s find out…
The first problem is that the official insta360.com online store does not currently give any specifications of these accessories. Only two mention a length in their product name. You can find their full accessory list here:
The following table will contain information as I obtain it.
Summary
Product
Collapsed Length
Extended Length
Weight
Built-In Tripod?
Price
Notes
2-in-1 Invisible Selfie Stick + Tripod
24 cm / 9.4 in
105 cm / 41.3 cm
Yes
$25
70cm Invisible Selfie Stick
15 cm / 6 in
70 cm / 27.5 in
$19.99
85cm Invisible Selfie Stick (2024)
85 cm / 33.5 in
19.4 cm / 7.64 in
119 g / 4.2 oz
$24.99
114cm Invisible Selfie Stick (black)
23.3 cm / 9.2 in
114 cm / 44.9 in
118 g / 4.16 oz
$24.99
114cm Invisible Selfie Stick Gold Edition
23.3 cm / 9.2 in
114 cm / 44.9 in
118 g / 4.16 oz
$24.99
Golden color
120cm Invisible Selfie Stick
23.5 cm / 9.25 in
120 cm / 47.4 in
$16
Action Invisible Selfie Stick
28 cm / 11 in
100 cm / 39.3 in
124.3 g / 4.4 oz
$49.99
Carbon fiber
All-Purpose Tripod
Yes
$34.90
Bullet Time Accessory
See 114cm Selfie Stick
See 114cm Selfie Stick
See 114cm Selfie Stick
Includes Handle (Tripod)
$64.99
Bullet Time Handle (Tripod)
16.9 cm / 6.6 in
N/A
Yes
$40
Extended Edition Selfie Stick (new version)
36 cm / 14 in
3 m / 9.8 ft
365 g / 12.9 oz
$99.99
Extended Edition Selfie Stick (old version)
55.8 cm / 22 in
304.8 cm / 10 ft
Mini 2-in-1 Tripod
97 g / 3.42 oz
$29.99
Power Selfie Stick
33 cm / 13 in
100 cm / 39.3 in
280 g / 9.8 oz
$69.99
4500 mAh battery and power/shutter buttons. Cannot get wet.
120cm Invisible Selfie Stick
Possibly the one included with the special Apple Store X2 kit.
2-in-1 Invisible Selfie Stick + Tripod
Larger selfie stick (in thickness) with a fold-out tripod at the end of the handle.
70cm Invisible Selfie Stick
Possibly the stick being included with the Bullet Time accessory.
All-Purpose Tripod
A tiny tripod base that the selfie sticks can screw in to.
Bullet Time Accessory
Includes a special tripod base with a spinning top. The top can be locked so it will not spin. A selfie stick can be attached at the top to use this as a tripod, or on the side, to use a bullet time accessory. (Kit shipping in 2022 includes a 120cm selfie stick, but the packaging had a spot that was designed to hold a taller collapsed stick — no details on what that one was.)
Contains a 4500 mAh battery to double the shooting time of the camera. (The battery included with the X2, for example, is about 1600 mAh).
Contains buttons to start/stop the camera so you can use it like a remote control.
100 cm extending length. (This makes it a selfie stick with the battery, different than things like the LUME power handle, which is just a handle with a battery).