Extracting GPS data from INSV file

[g_gantic]

Hello.

First of all, I would like to express my thanks to Phil Harvey for this great tool. It has helped me many times. Especially in terms of extracting insta360 data.

Because of that, maybe I can add some additional information...

Hi Phil,  the insta360 One X support record GPS from mobile phone, or from a remote controller. The file I send you last time is recoreded by mobile phone, and yesterday I bought a remote controller, I find that the data is changing in one second, so you may still promote the time accuracy and gps accuracy(to 0.001'').

The data quality in the insv file of an OneX/R/X2 depends on the GPS signal quality provided by phone / GPS smart remote / Apple or Garmin watch. All three cameras can add GPS data at 10Hz which includes to have 10 different GPS coords per second. But that strongly depends on the device used to get the data and its GPS lock / signal quality. I've done some tests with different devices => https://www.facebook.com/groups/Insta360OneCommunity/permalink/3246276772128895/

Unfortunately for most mobile devices you have to live with having doubled data points in the 10/s.
The best way to deal with it is to use additional tools to to even out the data / to optimize the data to an average...
Like GPSbabel (https://software.frankingermann.de/gpxtrackmap/gtm-documentation/9-joomla-plugins/gpxtrackmap/22-gtm-filtering-gpx-tracks-with-gpsbabel) ...
That's nothing I would see ExifTool in charge.

Coming to "gps accuracy", GPX does not provide a tag for that kind of "accuracy".
There is an element for "extensions" where you could place some own format.
(http://www.topografix.com/GPX/1/1/#type_extensionsType)

There are tags for "Dilution Of Precision" ( https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation)  )  for every data point => http://www.topografix.com/GPX/1/1/#type_wptType
but that's not what you have in mind. Those only specify how reliable the data is. So the usage would be, the greater the number of doubles in the 10 data points /s, the greater the DUP value would be.

The only tag that I can imagine having that sort of data would be

[Main]          Parameters                      : 1 2576.934 2014.997 1506.038 0.291 -0.115 89.496 4056 3040 1058

Are those parameters known?

Those are a kind of helper data for the stitcher, calibration / lens related data.

- The accel data is "timecode" based. The timecode is in seconds but it does not start at zero. I have tried assuming the first samples correspond to the first frame, but there seems to be a slight offset (the data seems a bit delayed, so maybe some data samples before the first video frame are retained). Does anyone know what that timecode is relative to? The video track timecode does start at zero, and I cannot find any tag that resembles that value, to use as a base offset

That time code, as well as the timecode for exposure data, is uptime based.
You wont find an anchor point in the video data to hook up. You have to assume that the first appearance of an accelerator time code is at / near the starting point of the video. Guess you already connected the video tracks time code zero with the first accelerator time code.

Unfortunately due to the way the data is acquired and saved you will face a delay.

Phil.

I have been looking at the gyroscope data to provide a different way to stabilize the video other than insta360 own flowstate. When opening insta360 Studio, it seems to be able to sync the video and gyroscope data right away despite the offset varying in the multiple the sample videos I looked at . Looking at the data, we seem to have a longer track of gyroscope/exposure data than video itself (1-2s more of gyroscope data than video). While the metadata are timestamped with uptime, the video/audio tracks are not and they start at timestamp 0 as you were saying so we can't sync them.

I am convinced there must be a way to map this side data to the video store somewhere in the file but I can't find where. It could be hidden in some of the documents that exiftool can't decode yet: 0x200, 0x400, 0x900 or 0xa00.

I'd be curious to understand Phil Harvey's approach on how he was able to decode this data from scratch. And I do join you, other Phil, in thanking Phil Harvey for this incredible tool!

[Phil_K]

Hello.

I have been looking at the gyroscope data to provide a different way to stabilize the video other than insta360 own flowstate. When opening insta360 Studio, it seems to be able to sync the video and gyroscope data right away despite the offset varying in the multiple the sample videos I looked at . Looking at the data, we seem to have a longer track of gyroscope/exposure data than video itself (1-2s more of gyroscope data than video). While the metadata are timestamped with uptime, the video/audio tracks are not and they start at timestamp 0 as you were saying so we can't sync them.

There is, but currently not in plain sight for us.
And you are right, that gyro data starts before the actual first frame of the video is saved. If you look at the time code of the Accelerator and the time code for the ExposureTime - coming between gyro and GPS data - they have a small offset, too.

For example in one of my videos the first time codes for both read like
TimeCode                        : 562.873
Accelerometer                   : -0.993896484375 0.120849609375 -0.077392578125

TimeCode                        : 562.881
ExposureTime                    : 1/353

But I haven't found a reference in the rest for that .008 difference yet.

I am convinced there must be a way to map this side data to the video store somewhere in the file but I can't find where. It could be hidden in some of the documents that exiftool can't decode yet: 0x200, 0x400, 0x900 or 0xa00.

I'd be curious to understand Phil Harvey's approach on how he was able to decode this data from scratch. And I do join you, other Phil, in thanking Phil Harvey for this incredible tool!

I'm sure it's somewhere, and I'm also curious.
Well, what has escaped my attention a bit is the fact that Insta360 has been releasing some material on github over the last few months.... So far I haven't had the time to look into it in detail => https://github.com/Insta360Develop

The part around the "Player" might be interesting...

Öhm... I'm hopping that's not too offtopic for this forum at all...

Phil.

[Phil Harvey]

I am convinced there must be a way to map this side data to the video store somewhere in the file but I can't find where. It could be hidden in some of the documents that exiftool can't decode yet: 0x200, 0x400, 0x900 or 0xa00.

0x200 contains a lot of unknown information.  I think ExifTool decodes most useful information from 0x400.  I don't have any samples with 0x900 or 0xa00.

I'd be curious to understand Phil Harvey's approach on how he was able to decode this data from scratch.

After staring at binary data for long enough, sometimes you can see patterns that look familiar.  "You get used to it, I don't even see the code, All I see is blond, brunette, redhead"

- Phil

[Phil_K]

Hi all.

I've looked again on all the data we already have and I compared a few of my recordings, in 5.7k and 4k. Every time I could match the time code of the first ExposureTime to a time code of the Accelerometer or it was between two time codes.

The number of ExposureTime values fit the number of calculated frames for those video.
By that the first ExposureTime can be taken to represent the very first frame in the video.

Now connect that with the comparing time code of the Accelerometer or the next one if that Acc-TimeCode is between two.

Btw, the "Unknown2" in the 0x700 GPS part looks like a millisecond counter, which also represents the n-th parameter per second. It does not always start with "0 0" and not all videos have GPS data coverage right from the start. But the GPS start, can be synced with the "TrackCreateDate" down to the second.

For one of my videos the first 7 seconds are without GPS data, that would also mean that GPS starts at frame number 210. Now get the 210th ExposureTime time code and you can sync GPS to Accelerometer.
And based on the Unkown2 counter you can sync that down to millisecond related to the time code.

It needs a little data management and calculations, but it's worth a try I guess....
... if you want to do that based on the extracted data, I wouldn't see that task by exifTool.

Phil.

[Kajuna]

I've looked again on all the data we already have and I compared a few of my recordings, in 5.7k and 4k. Every time I could match the time code of the first ExposureTime to a time code of the Accelerometer or it was between two time codes.

Great job, Phil. I wanted to try exactly that, but haven't been able to read the ExposureTime values you are seeing. What command are you using?

Thanks.

[Phil_K]

Hi Kajuna.

Great job, Phil. I wanted to try exactly that, but haven't been able to read the ExposureTime values you are seeing. What command are you using?

I'm using version 12.12 of the 64Bit ExifTool package for Windows.
The command options I use are

Code Select Expand

-api largefilesupport -ee -G
with a pipe to a file for a quick look which also gets me Exif, File, XMP & QuickTime tags.

At the later I used

Code Select Expand

-api largefilesupport -m -ee -u -QuickTime:all -Trailer:Insta360:all
-m makes sure to get all Accelerometer data
-u shows all unknown tags but without binary ones as they are not needed

The rest are filter for the Tags I need, which is QuickTime and all Insta360 related ones.
With that you get all data to connect the different streams and define the virtual zero for
the time code and the virtual millisecond of Unknown2 allows to connect the GPS data to that
two, even if the GPS data starts a few seconds later then the video.

[Kajuna]

I'm using version 12.12 of the 64Bit ExifTool package for Windows.

Thanks Phil_k. I was using an older version of Exiftool that did not label the Exposure Times. Some thoughts and additional information on your findings:

- The Track Create Date does not seem to be based on the same source as the GPS Date/Time, and therefore does not seem viable for determining when the GPS started recording samples (relative to the video start). I suppose the former is based on an internal camera clock and the latter comes from the GPS signal. For example, I just shot a file where the GPS was acquired about 125 seconds after the recording started. The Track Create Date is 2021:01:22 16:41:54 but the first GPS sample has a GPS Date/Time of 2021:01:22 15:44:31Z. So the gap is about 157 seconds (after subtracting the time zone). Close-ish but not enough for a visually correct sync.

- As you suggested, the unknown GPS values seem like the missing milliseconds of the GPS Date/Time (although they do not have the precision one would expect from GPS timestamps. They're more like deciseconds). Maybe this could be parsed by ExifTool, as otherwise multiple GPS samples have the exact same date. I know this ALSO happens when you record the data with a phone and there are 10 exact copies of each sample (1Hz multiplied to mimic 10Hz), but when using the GPS remote the 10 samples are actually different (in position, speed). For example (summarised for visibility):

Code Select Expand

GPS Date/Time                   : 2020:12:10 17:33:12Z
GPS Latitude                    : 41 deg 35' 3.67" N
Unknown 02                      : 0 700
GPS Date/Time                   : 2020:12:10 17:33:12Z
GPS Latitude                    : 41 deg 35' 3.60" N
Unknown 02                      : 0 800
GPS Date/Time                   : 2020:12:10 17:33:12Z
GPS Latitude                    : 41 deg 35' 3.54" N
Unknown 02                      : 0 900
GPS Date/Time                   : 2020:12:10 17:33:13Z
GPS Latitude                    : 41 deg 35' 3.47" N
Unknown 02                      : 0 0
GPS Date/Time                   : 2020:12:10 17:33:13Z
GPS Latitude                    : 41 deg 35' 3.41" N
Unknown 02                      : 0 100
GPS Date/Time                   : 2020:12:10 17:33:13Z
GPS Latitude                    : 41 deg 35' 3.34" N
Unknown 02                      : 0 200

I think it's safe to assume, as both the Unknown values and the number of samples suggest, that the correct Date/Times are

Code Select Expand

: 2020:12:10 17:33:12.700Z
: 2020:12:10 17:33:12.800Z
: 2020:12:10 17:33:12.900Z
: 2020:12:10 17:33:13.000Z
: 2020:12:10 17:33:13.100Z
: 2020:12:10 17:33:13.200Z

But it's just a suggestion. I can parse this on my end.

Edit: I just checked with a video that has iPhone GPS data and, indeed, the Unkown value is the same between samples, which would make the previous assumptions correct. It also shows more decimals than the GPS remote value (Unknown 02 : 0 998), so that would indicate that the GPS remote records times with a precision of deciseconds at 10Hz, while the phone has a precision of milliseconds, but at just 1Hz.

- Ok. Now to the initial time code of the accelerometer. The Exposure times look promising, but here are my results in practice. I shot videos where I could clearly check the accel sync. The results are consistent between videos, for example for one video:

Visually checked offset: 1.150 seconds
First exposure time: 15.811
First accelerometer: 15.288
Difference: 0.523

The offset between accel time code and exposure time code is generally much smaller than the visually checked offset. So let's see if for any reason exposures are aligned to the end of the video:

Last exposure time: 33.171
Last accelerometer: 33.138
Difference: -0.033 (Accel ends before exposures)

Seems not. So let's see if the exposure samples match the number of frames. It's generally close, but not exact (there are more exposure samples than frames):

Frames in video 412
Exposure samples 432
Difference: 20 frames

This was at 25fps, so the excess of 20 frames would span 0.8 seconds.

I've tested this with other videos, including long ones, and the excess of samples seems to be always there and around that number (have not tried other frame rates or formats).

This is pure speculation, but we could try assuming these excessive samples are at the beginning of the video, and then add the time to the "exposure vs. accel" offset (that would leave us with an offset of 1.323) or we could split them between the beginning and the end of the video, predicting that that's what happens on average (the final offset would be of 0.923). Both results look slightly off visually, but if all the assumptions are correct (which is a long shot), all videos should look close to sync.

I'll try to keep testing.

[Phil_K]

Hello.

Sorry for the delay...

Let me start, from my point of view this is all speculation and the best approach at this time to merge the data.

- The Track Create Date does not seem to be based on the same source as the GPS Date/Time, and therefore does not seem viable for determining when the GPS started recording samples (relative to the video start). I suppose the former is based on an internal camera clock and the latter comes from the GPS signal. For example, I just shot a file where the GPS was acquired about 125 seconds after the recording started. The Track Create Date is 2021:01:22 16:41:54 but the first GPS sample has a GPS Date/Time of 2021:01:22 15:44:31Z. So the gap is about 157 seconds (after subtracting the time zone). Close-ish but not enough for a visually correct sync.

Agree. I would say it (TrackCreateDate) comes from the cameras internal clock.

- As you suggested, the unknown GPS values seem like the missing milliseconds of the GPS Date/Time (although they do not have the precision one would expect from GPS timestamps. They're more like deciseconds).

Jip, deciseconds.. I git distracted by its number of digits.

But it is not accurate or usable in all instances.
I did some reviews with my recordings across different versions of apps (OneX, OneR and Insta360app)
and also with different devices providing the GPS data.

What I see is that the GPS smart remote is the most reliable source to provide those deziseconds.
On an OneR app recorded video with GPS provided by Garmin Glo2 on an iPad ini5 wifi, there are values doubled and repeated even the GPS coords are individual. I have no idea why that is so.

This is pure speculation, but we could try assuming these excessive samples are at the beginning of the video, and then add the time to the "exposure vs. accel" offset (that would leave us with an offset of 1.323) or we could split them between the beginning and the end of the video, predicting that that's what happens on average (the final offset would be of 0.923). Both results look slightly off visually, but if all the assumptions are correct (which is a long shot), all videos should look close to sync.

I'll try to keep testing.

Good work.
In summary it sounds like a good approach to get near a minimized off-sync and also minimize manual interaction to shift data in sync with the video.... by the way... depending on the tool you are creating...
Wouldn't it be an additional feature to give the user an adjustment slider to adjust that "sync" / offset to his favor? Like "manual/auto" mode.

Greetings
Phil.

[paluan01]

     
I have just read all the threads but I was not able to identify a clear procedure to extract a GPX trace from.INSV file I own an insta360 one R with its remote GPS control.
May some of you so kind to summarize step by step the procedure to be followed?
Many thanks
l

[Phil Harvey]

This is the command:

exiftool -p gpx.fmt -ee3 FILE > out.gpx

Where you need this gpx.fmt file in the current directory when running the command.

- Phil

[paluan01]

Thanks first of all for the answer.

I tried with "prova.insv"
and this was the result was:

Warning: [Minor] Tag 'Doc33211:ss' not defined - prova.INSV

Opening .GPX file this is the syntax of one section

<?xml version="1.0" encoding="utf-8"?>\
<gpx version="1.0"\
creator="ExifTool 12.25"\
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\
xmlns="http://www.topografix.com/GPX/1/0"\
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">\
<trk>\
<number>1</number>\
<trkseg>\
{\rtf1\ansi\ansicpg1252\cocoartf1671\cocoasubrtf600
{\fonttbl\f0\fmodern\fcharset0 Courier;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0;}
\paperw11900\paperh16840\margl1440\margr1440\vieww21140\viewh17780\viewkind0
\deftab720
\pard\pardeftab720\sl280\partightenfactor0

\f0\fs24 \cf2 \expnd0\expndtw0\kerning0
\outl0\strokewidth0 \strokec2 #------------------------------------------------------------------------------\
<trkpt lat="45.0924981666667" lon="7.63498883333333">\
  <ele>260.1</ele>\
</trkpt>\
\pard\pardeftab720\sl280\partightenfactor0
\cf2 \outl0\strokewidth0 \
\
}{\rtf1\ansi\ansicpg1252\cocoartf1671\cocoasubrtf600
{\fonttbl\f0\fmodern\fcharset0 Courier;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0;}
\paperw11900\paperh16840\margl1440\margr1440\vieww21140\viewh17780\viewkind0
\deftab720
\pard\pardeftab720\sl280\partightenfactor0

.
.
.
.

How to fix it?

[Phil_K]

Good morning.

I have just read all the threads but I was not able to identify a clear procedure to extract a GPX trace from.INSV file I own an insta360 one R with its remote GPS control.
May some of you so kind to summarize step by step the procedure to be followed?
Many thanks

Besides the info an fmt file Phil has already given to you, allow me to direct your attention also to
https://www.facebook.com/groups/insta360onexusers/permalink/454627628467347/
as a kind of cross reference.

Even we go a bit offtopic, the steps are equal for OneX/R/X2 regarding 360° video.
For the OneR it might depend which lens module you used.
Personally I can only speed about videos done in 360° because I hadn't the chance to look at videos done with the 4k or 1" module in regards to GPS data.

Also - because of the size of the data - i found it a good idea to use the 64bit version of exifTool provided via the "alternate ExifTool Windows installer" linked on the download page.

For your video files, if you did a 5.7k 360° recording make sure to let exifTool work on the file with _00_ in the name. The second lens video (_10_ part) does not contain GPS data.

In your special case it seems the line

Code Select Expand

#[BODY]  <time>${gpsdatetime#;my ($ss)=/\.\d+/g;DateFmt("%Y-%m-%dT%H:%M:%SZ");s/Z/${ss}Z/ if $ss}</time>
in the gpx.fmt file seems to make problems because the regex substitution can not be done.
You may replace it with

Code Select Expand

#[BODY]   <time>${gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%SZ")}</time>
which is simpler but works with OneX/R/X2 GPS data in the files.

[paluan01]

Good morning to you!
Let me thank you again for the support.

Some info:
- I am working with MacBook
- I am using Insta360 one R and _00_file
- The GPS data are from Its Remote Controller

I modified the .fmt file according to your indication but, unfortunately, was not good (yet :-))

these the warnings
Warning: Truncated '\x00\x02\x00\x00' data - prova.insv
Warning: [Minor] Insta360 accelerometer data is huge. Processing only the first 20000 records - prova.insv

______________________________
this the content of out.GPX file
______________________________

<?xml version="1.0" encoding="utf-8"?>\
<gpx version="1.0"\
creator="ExifTool 12.25"\
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\
xmlns="http://www.topografix.com/GPX/1/0"\
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">\
<trk>\
<number>1</number>\
<trkseg>\
{\rtf1\ansi\ansicpg1252\cocoartf1671\cocoasubrtf600
{\fonttbl\f0\fmodern\fcharset0 Courier;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;\red234\green233\blue255;\red115\green0\blue2;
}
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0;\cssrgb\c93333\c93333\c100000;\cssrgb\c53333\c0\c0;
}
\paperw11900\paperh16840\margl1440\margr1440\vieww21140\viewh17780\viewkind0
\deftab720
\pard\pardeftab720\sl280\partightenfactor0

\f0\fs24 \cf2 \expnd0\expndtw0\kerning0
<trkpt lat="45.0924981666667" lon="7.63498883333333">\
  <ele>260.1</ele>\
\pard\pardeftab720\sl240\partightenfactor0
\cf2 \cb3 \outl0\strokewidth0 \strokec4 #[BODY]\'a0 \'a0<time>$\{gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%SZ")\}</time>\cf2 \cb1 \outl0\strokewidth0 \
\pard\pardeftab720\sl280\partightenfactor0
\cf2 #[BODY]</trkpt>\
\
\
_____________________________________

My goal is to have a GPX file to be managed with Google Earth


I appreciate if you can follow me to fix all the problems!
Many thanks again

[Phil_K]

Good morning to you!
Let me thank you again for the support.

Some info:
- I am working with MacBook
- I am using Insta360 one R and _00_file
- The GPS data are from Its Remote Controller

I modified the .fmt file according to your indication but, unfortunately, was not good (yet :-))

these the warnings
Warning: Truncated '\x00\x02\x00\x00' data - prova.insv
Warning: [Minor] Insta360 accelerometer data is huge. Processing only the first 20000 records - prova.insv

The first warning - I guess - is related to how the data is saved / finalized in the file but can be ignored.
The second warning is because that data is really huge and you don't need that, but if you want to see it all "-m" option is your friend.

Phil may correct me, but that your command does not give you any further gps to gpx output seems to me because the command line has a typo.

Besides the fmt file option I use "-ee -G3" so you would use something like

Code Select Expand


exiftool -p gpx.fmt -ee -G3 FILE > out.gpx

But you don't really need the "-G3" option for only extracting, it's more helpful for debugging.

Oh btw, please, if you quote the output use the code tags around it. Or select and hit the button with # over the editor window. That helps reading it.

[Phil Harvey]

There is something wrong with the fmt.gpx file that you are using.  Maybe you cut and pasted it into a file and the linefeeds got messed up?

The "Truncated" warning probably indicates that there is some type of non-standard trailer at the end of the file that ExifTool doesn't recognize.

- Phil