Extracting GPS data from MP4 video file

Started by fakej, December 31, 2017, 11:58:10 AM

Previous topic - Next topic

Manfred Prechtl

#60
I have a Redtiger F7N dashcam and I have got the folloing output from
exiftool.exe -ee -gps* [MP4-File]

GPS Date/Time                  : 0022:12:23 10:30:17Z
GPS Latitude                    : 13726 deg 17' 9.95" N
GPS Longitude                  : 10626 deg 11' 58.35" E
GPS Speed                      : 0.104
GPS Track                      : 180
GPS Date/Time                  : 0022:12:23 10:30:18Z
GPS Latitude                    : 13726 deg 17' 9.95" N
GPS Longitude                  : 10626 deg 11' 58.35" E
GPS Speed                      : 0.159
GPS Track                      : 180
GPS Date/Time                  : 0022:12:23 10:30:19Z
GPS Latitude                    : 15203 deg 46' 23.57" N
GPS Longitude                  : 10626 deg 11' 58.35" E
GPS Speed                      : 0.423
GPS Track                      : 180

and so on.

From exiftool.exe -v3 [MP4-File] I got the warning
"Warning = GPSLatitude/Longitude encryption is not yet known, so these will be wrong"
OK, they are really wrong.

Type='gps ', Sample 1 of 60 (16384 bytes)
  2e110c: 00 00 40 00 66 72 65 65 47 50 53 20 f0 01 00 00 [..@.freeGPS ....]
  2e111c: 59 4f 55 51 49 4e 47 47 50 53 00 00 20 07 5f 01 [YOUQINGGPS.. ._.]
  2e112c: 00 00 00 00 00 00 00 00 a8 e7 99 45 24 10 97 44 [...........E$..D]
  2e113c: 0a 00 00 00 1e 00 00 00 11 00 00 00 16 00 00 00 [................]
  2e114c: 0c 00 00 00 17 00 00 00 41 4e 45 00 00 00 00 00 [........ANE.....]
    [snip 16304 bytes]
Warning = GPSLatitude/Longitude encryption is not yet known, so these will be wrong
GPSDateTime = 0022:12:23 10:30:17Z
GPSLatitude = 13726.286096
GPSLongitude = 10626.199541
GPSSpeed = 0.104000002145767
GPSTrack = 180
Type='gps ', Sample 2 of 60 (16384 bytes)
  5d8224: 00 00 40 00 66 72 65 65 47 50 53 20 f0 01 00 00 [..@.freeGPS ....]
  5d8234: 59 4f 55 51 49 4e 47 47 50 53 00 00 20 07 5f 01 [YOUQINGGPS.. ._.]
  5d8244: 00 00 00 00 00 00 00 00 a8 e7 99 45 24 10 97 44 [...........E$..D]
  5d8254: 0a 00 00 00 1e 00 00 00 12 00 00 00 16 00 00 00 [................]
  5d8264: 0c 00 00 00 17 00 00 00 41 4e 45 00 00 00 00 00 [........ANE.....]
    [snip 16304 bytes]
GPSDateTime = 0022:12:23 10:30:18Z
GPSLatitude = 13726.286096
GPSLongitude = 10626.199541
GPSSpeed = 0.158999994397163
GPSTrack = 180

Can you help me to got the real values.
Must be somthing like: N:49.4160..  E:12.1417..

Thank you,
Manfred


StarGeek

As the warning says, the encryption isn't known, so there's no way to get correct values.

There are a lot of cameras that are obfuscating there data like this for no practical except they want you to only use their software.  Nothing can be done until either someone figures out the encoding or someone talks some sense into the camera's manufacturer. 
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Manfred Prechtl

Thank you, for your quick resonse.

Is is possible with exiftool, to get only the complete gps chuncks buffers (16384 bytes) out of the mp4 files ?
Maybe I can try to interpret it by my own.

Thank you
Manfred


StarGeek

No.  The best exiftool can offer would be to use -v5 (-verbose5) option which will give a hex dump of each of the blocks.
exiftool -G1 -a -s -ee3 -v5 file.mp4

Note that this will result in a lot of output.  My test on a short file gave nearly 232,000 lines of output.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

jollino

Quote from: Manfred Prechtl on January 25, 2023, 04:22:50 AMIs is possible with exiftool, to get only the complete gps chuncks buffers (16384 bytes) out of the mp4 files ?
Maybe I can try to interpret it by my own.

Hi Manfred, it's been a while but I was wondering if you've had any luck with this? I just got the same dashcam and I've encountered the same issue.

What I found is that once the gps locks onto a signal, the recorded speed does seem to be proportional to the actual speed but definitely not in km/h. The ratio appears to be around 1.8 (it's an approximation as the video feed doesn't record any decimals), which surprisingly seems to match knots (1 kn = 1.852 km/h).

Heading also seems to be consistent: going west I get around 455, going south I get around 360, going east(-ish, slightly towards south) I get around 275. Those should be 270, 180 and 90, so it looks like it adds 180 or so.

I'm not sure if the 1.8 and 180 are related, but I wonder?

I noticed a few interesting things about latitude and longitude:
1) The recorded longitude varies by small amount every second, with a much bigger change every minute, exactly on the minute (e.g. 9:21:59 - 9:22:00).
2) The recorded latitude varies wildly every second, but the minute-by-minute change on that second is small. At 00 seconds on the minute, it's always around 7252; at 01 seconds, it's always around 28356, and so on. Different hours do not seem to make much of a difference.
3) Minutes and seconds clearly affect the recorded longitude and latitude respectively, but not in the same way when they are the same. As an example 10:36:36 does NOT return similar numbers for both values (in my specific case that would be 33852.510500 and 11104.837580, for actual values of 42.3656 and 14.1552).

Here is the recorded latitude for each second, with an actual latitude being around 42.35:
xx:yy:00 => 7254.442400 N
xx:yy:01 => 28364.554650 N
xx:yy:02 => 16120.666400 N
xx:yy:03 => 25409.079780 N
xx:yy:04 => 11898.622700 N
xx:yy:05 => 6410.005020 N
xx:yy:06 => 6410.000340 N
xx:yy:07 => 11476.394250 N
xx:yy:08 => 14009.583120 N
xx:yy:09 => 18231.565610 N
xx:yy:10 => 9787.574900 N
xx:yy:11 => 24986.715350 N
xx:yy:12 => 8098.766720 N
xx:yy:13 => 19498.098560 N
xx:yy:14 => 20764.672040 N
xx:yy:15 => 11898.517660 N
xx:yy:16 => 18653.651420 N
xx:yy:17 => 11898.497380 N
xx:yy:18 => 11898.488280 N
xx:yy:19 => 13165.066340 N
xx:yy:20 => 28364.084050 N
xx:yy:21 => 11898.465140 N
xx:yy:22 => 5987.733560 N
xx:yy:23 => 41452.063280 N
xx:yy:24 => 24564.277120 N
xx:yy:25 => 11054.058080 N
xx:yy:26 => 25830.851080 N
xx:yy:27 => 11476.250250 N
xx:yy:28 => 23719.876160 N
xx:yy:29 => 11898.441740 N
xx:yy:30 => 37652.269910 N
xx:yy:31 => 5987.724560 N
xx:yy:32 => 28786.191440 N
xx:yy:33 => 33852.516740 N
xx:yy:34 => 24142.058100 N
xx:yy:35 => 20764.506130 N
xx:yy:36 => 33852.510500 N
xx:yy:37 => 14431.596720 N
xx:yy:38 => 15275.983460 N
xx:yy:39 => 16120.371560 N
xx:yy:40 => 37230.062220 N
xx:yy:41 => 24142.061950 N
xx:yy:42 => 11898.443560 N
xx:yy:43 => 16964.780640 N
xx:yy:44 => 12320.650040 N
xx:yy:45 => 19497.968320 N
xx:yy:46 => 14853.833660 N
xx:yy:47 => 24564.332560 N
xx:yy:48 => 12742.872000 N
xx:yy:49 => 24986.555750 N
xx:yy:50 => 10631.905770 N
xx:yy:51 => 11898.498420 N
xx:yy:52 => 25408.780500 N
xx:yy:53 => 23719.997120 N
xx:yy:54 => 28786.353800 N
xx:yy:55 => 33852.711740 N
xx:yy:56 => 8098.735780 N
xx:yy:57 => 26675.375960 N
xx:yy:58 => 19075.842770 N
xx:yy:59 => 35541.502800 N

And this is the same for the recorded longitude, taken from multiple trips, with the actual value always being within 14.15 and 14.20 N. There's a slightly larger variation over different hours, but that is most likely due to the broader trips:
xx:00:yy => 2228.018900 E
xx:01:yy => 9279.498350 E
xx:02:yy => 5189.209280 E
xx:03:yy => 8291.455100 E
xx:04:yy => 3778.762460 E
xx:05:yy => 1944.291510 E
xx:06:yy => 1945.293420 E
xx:07:yy => 3637.714500 E
xx:08:yy => 4485.220110 E
xx:09:yy => 5896.013350 E
xx:10:yy => 3074.451890 E
xx:11:yy => 8151.189470 E
xx:12:yy => 2509.570380 E
xx:13:yy => 6316.998600 E
xx:14:yy => 6739.654210 E
xx:15:yy => 3779.042740 E
xx:16:yy => 6035.481920 E
xx:17:yy => 3780.002400 E
xx:18:yy => 3779.200300 E
xx:19:yy => 4201.382100 E
xx:20:yy => 9275.981850 E
xx:21:yy => 3777.131740 E
xx:22:yy => 1803.575480 E
xx:23:yy => 13639.316600 E
xx:24:yy => 8009.851800 E
xx:25:yy => 3496.919240 E
xx:26:yy => 8433.524390 E
xx:27:yy => 3637.389000 E
xx:28:yy => 7727.217020 E
xx:29:yy => 3779.226040 E
xx:30:yy => 12384.185660 E
xx:31:yy => 1805.276600 E
xx:32:yy => 9422.959700 E
xx:33:yy => 11112.859880 E
xx:34:yy => 7864.990100 E
xx:35:yy => 6736.091610 E
xx:36:yy => 11104.704200 E
xx:37:yy => 4621.853240 E
xx:38:yy => 4904.382140 E
xx:39:yy => 5186.261960 E
xx:40:yy => 12233.555820 E
xx:41:yy => 7863.925300 E
xx:42:yy => 3776.607060 E
xx:43:yy => 5469.271640 E
xx:44:yy => 3918.873230 E
xx:45:yy => 6315.358280 E
xx:46:yy => 4764.283370 E
xx:47:yy => 8007.604520 E
xx:48:yy => 4061.514400 E
xx:49:yy => 8154.889340 E
xx:50:yy => 3358.330490 E
xx:51:yy => 3782.987980 E
xx:52:yy => 8304.266720 E
xx:53:yy => 7722.227960 E
xx:54:yy => 9413.346140 E
xx:55:yy => 11104.559900 E
xx:56:yy => 2508.083560 E
xx:57:yy => 8712.321010 E
xx:58:yy => 6177.753590 E
xx:59:yy => 11679.675480 E

Note that in both cases it seems like the precision never goes beyond 5 decimal digits, though the video feed records 4. It shows 6 here because I used `exiftool -ee -c '%.6f'`.

Here is some slightly annotated output:

GPS Date/Time                  : 0023:12:09 11:04:58Z
GPS Latitude                    : 19072 deg 10' 55.85" N / 19072.182180 N (actual: 42.3519)
GPS Longitude                  : 3778 deg 45' 47.66" E / 3778.763240 E (actual: 14.1702)
GPS Speed                      : 2.888
GPS Track                      : 200.06

GPS Date/Time                  : 0023:12:09 11:04:59Z
GPS Latitude                    : 35534 deg 30' 53.14" N / 35534.514760 N (actual: 42.3519)
GPS Longitude                  : 3778 deg 45' 49.54" E / 3778.763760 (actual: 14.1702)
GPS Speed                      : 2.278
GPS Track                      : 368.92

GPS Date/Time                  : 0023:12:09 11:05:00Z
GPS Latitude                    : 7253 deg 3' 53.82" N / 7253.064950 N (actual: 42.3519)
GPS Longitude                  : 1945 deg 29' 17.84" E / 1945.488290 E (actual: 14.1702)
GPS Speed                      : 1.481
GPS Track                      : 366.1

GPS Date/Time                  : 0023:12:09 11:05:01Z
GPS Latitude                    : 28358 deg 37' 12.54" N / 28358.620150 N (actual: 42.3519)
GPS Longitude                  : 1945 deg 29' 17.84" E / 1945.488290 E (actual: 14.1702)
GPS Speed                      : 0

...

GPS Date/Time                  : 0023:12:09 11:06:59Z
GPS Latitude                    : 35532 deg 4' 22.08" N / 35532.072800 N (actual: 42.3470)
GPS Longitude                  : 1945 deg 20' 4.20" E / 1945.411070 E (actual: 14.1678)
GPS Speed                      : 20.999
GPS Track                      : 272.9

GPS Date/Time                  : 0023:12:09 11:07:00Z
GPS Latitude                    : 7252 deg 37' 7.86" N / 7252.618850 N (actual: 42.3470)
GPS Longitude                  : 3637 deg 28' 2.10" E / 3637.467250 E (actual: 14.1684)
GPS Speed                      : 21.387
GPS Track                      : 273.9

GPS Date/Time                  : 0023:12:09 11:07:01Z
GPS Latitude                    : 28356 deg 41' 11.04" N / 28356.686400 N (actual: 42.3469)
GPS Longitude                  : 3637 deg 29' 14.10" E / 3637.487250 E (actual: 14.1684)
GPS Speed                      : 22.214
GPS Track                      : 274.54

GPS Date/Time                  : 0023:12:09 11:07:24Z
GPS Latitude                    : 24557 deg 47' 6.14" N / (actual: 42.3464)
GPS Longitude                  : 3637 deg 59' 45.60" E / (actual: 14.1713)
GPS Speed                      : 25.646
GPS Track                      : 279.34

GPS Date/Time                  : 0023:12:09 11:07:25Z
GPS Latitude                    : 11051 deg 16' 30.14" N / 24557.785040 N (actual: 42.3464)
GPS Longitude                  : 3638 deg 1' 11.10" E / 3637.996000 E (actual: 14.1713; note that this is less than a 2' shift)
GPS Speed                      : 25.348
GPS Track                      : 280.18

...

GPS Date/Time                  : 0023:12:09 11:07:59Z
GPS Latitude                    : 35531 deg 14' 16.94" N / 35531.238040 N (actual: 42.3452)
GPS Longitude                  : 3637 deg 56' 56.40" E / 3637.949000 E (actual: 14.1716)
GPS Speed                      : 0
GPS Track                      : 410.79

GPS Date/Time                  : 0023:12:09 11:08:00Z
GPS Latitude                    : 7252 deg 27' 58.14" N / 7252.466150 N (actual: 42.3452)
GPS Longitude                  : 4484 deg 7' 34.03" E / 4484.126120 E (actual: 14.1716)
GPS Speed                      : 0
GPS Track                      : 410.79

GPS Date/Time                  : 0023:12:09 11:08:01Z
GPS Latitude                    : 28356 deg 1' 35.94" N / 28356.026650 N (actual: 42.3452)
GPS Longitude                  : 4484 deg 7' 34.03" E / 4484.126120 E (actual: 14.1716)
GPS Speed                      : 0
GPS Track                      : 410.79

Finally, I tried DVPlayer's trial and it seems to be able to read the files. Indeed, it provides even more precision than the dashcam records on the video frames (e.g. 42.366098 vs. 42.3661, or 14.154375 vs. 14.1544.)
It only seems to show data for the very first frame, however, but I'm not sure if that's an issue with the files or a limitation on the program's trial version.

I can't seem to find any pattern myself, but maybe someone with a sharper mind than mine can spot something.

StarGeek

Quote from: jollino on December 17, 2023, 08:09:25 AMHi Manfred, it's been a while but I was wondering if you've had any luck with this? I just got the same dashcam and I've encountered the same issue.

Manfred never posted anything beyond these two posts, so it's quite unlikely they ever came up with anything.

If you are using a current version (12.70) of exiftool and it still isn't decoded, then it's probably pretty unlikely that this will change.  It's rare that anyone other than Phil will work on complicated stuff like this.

You can post a sample vid and Phil might look at it and verify it's still unknown. But it's unlikely to go beyond that as Phil has already put in a lot of time on this.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

I have many sample videos of this type (although others are welcome to improve my coverage of different points on earth -- you can send them to philharvey66 at gmail.com).  I did notice that the GPS values were encrypted somehow using the time (and maybe date?) to obfuscate the coordinates.  The algorithm may turn out to be really simple, but I think it may help to look at how the values change over widely separated GPS coordinates.  Toward this end I'm collecting samples in anticipation of the next time I'll have a try at figuring this out.  Alternatively, it may help to see how the values change over time for a static GPS position.  But I think you should also be looking at the raw binary data that is stored (using the exiftool -v3 option) because it is possibly some sort of bit manipulation that is being used.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

jollino

Unfortunately I'm not in a position (pun intended) to travel any considerable distance to see how it changes, but I had some time to kill today and I wound up trying to reverse-engineer GPSPlayer.

I found an interesting function that seems to call some webassembly code, which in turn apparently calls some exported function based on the "productno" derived from the video file, e.g. parseMstarTS(), parseNovatekJHTTS(), parseCYSDGPS() and others. I suppose that's where the magic happens, but I can't find anything else in the package that seems to have any reference to those — perhaps it exists in some binary, compressed file that eludes grep?

The only other reference to WebAssembly in renderer.js that has nested objects such as js_get_secret and js_get_token, and events such as mp4ToNMEA_get_key and mp4ToNMEA_get_secret. The former seems to read some chunks of data and concatenate it, but I'm not familiar with the video format and none of the names seem to match what exiftool -v3 returns (".xxxx", ".NMEA", etc.).

I posted two videos — front and rear — from today's random drive here. Never mind the dirt on the windshield, I ran out of wiper fluid so that made it worse...

Thank you very much for your patience, and let me know if I can help in any way. I don't have much time lately (or experience with this sort of data obfuscation) but I'm happy to do my best to contribute!

Phil Harvey

I got the sample, thanks.

For what it's worth, someone has figured out the JavaScript calls and written an interface to the libsungps.so library that does the decoding.  (see here)  Maybe the best route to figuring out the encryption is to reverse-engineer this library, but it would likely have to be done at assembly-language level.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).