Extracting GPS data from MP4 video file

[fakej]

Dear exiftool users,

Could you please advice how to extract GPS data from the MP4 video file like: http://206.142.243.145/test_drive/test_drive.MP4 to some well known format like kml or gpx?
If this can't be done with the exiftool would it be possible with some other tool/library?

A two examples of software that can read GPS data from such file are dashcam viewer https://dashcamviewer.com/ or nexbtase replay 3 https://www.nextbase.co.uk/wp-content/uploads/2017/09/Nextbase-Replay-3-Playback-Software.html (first one is MAC/Windows and the second Windows only tool if I'm correct)

[Phil Harvey]

I'll move this to the top of my to-do list and have another attempt at implementing this in ExifTool.  Check back in a couple of weeks.

- Phil

[fakej]

That's fantastic news. I appreciate that.

[Phil Harvey]

I'm making real headway here, but unfortunately have no solution yet.

The good news:

  - I can now parse AVC video stream data in MP4 videos

The bad news:

  - The GPS doesn't seem to be stored in the AVC video stream in MP4 videos like it is in M2TS files.

More good news:

  - One of my MP4 samples stores telemetry information in a text track that I can now parse.

More bad news:

  - It seems that different cameras store GPS differently in MP4 videos.

So if you could send me a small sample video containing GPS information I will try to extract it for your particular camera model.  Upload a raw MP4 to a file sharing service and email me the link (philharvey66 at gmail.com).

Thanks.

- Phil

[StarGeek]

I was looking around the net for info a few days ago and it seems that the places gps info gets stored varies wildly.  For example, this script indicates that some GoPros save it in a separate stream.  Another site (can't re-locate) says that another camera saved it in the subtitle stream, so you could see them just by turning a videos subtitles on.

But it's awesome that you're making some progress at least.

[Phil Harvey]

Hi StarGeek,

Yes, exactly.

I am fairly confident I can extract this metadata from these various locations, but each will take some time, and I need sample videos of each (and it would help if I had approximate GPS coordinates to make sure I'm extracting these properly).

I did find one sample that stored telemetry in a text track, and am extracting that now.

- Phil

[fakej]

Just for the reference I would like to make readers aware that on dashcamtalk forum exists related thread:
https://dashcamtalk.com/forum/threads/gps-track-missing.32440/ So the camera model which produced my particular video is Viofo A119S and their support is quite active on community forum, so I asked them for help with regards to the file format. Lets see if they could share this knowledge.

[fakej]

Hi Phil, StarGeek,

I don't know if you are following the thread above but it turned out that there is a python script (made by Sergei Franco) that can extract GPS data from my video file:
http://sergei.nz/files/nvtk_mp42gpx.py
I'm guessing it should work for all videos produced by cameras with Novatek NT96660 but I'm not 100% sure about that.

[StarGeek]

I actually must have hit that link at some point, as it shows up as an already viewed link.  I just didn't keep track of it.

[Phil Harvey]

I'm making good progress on extracting GPS from the sample you provided.

I'll be working to output the information in GPX format if possible.

- Phil

[Phil Harvey]

I now have ExifTool to the point where this command will produce the attached GPX file (using the gpx.fmt file included with the full distribution).

exiftool -p fmt_files/gpx.fmt -ee test_drive.MP4 > out.gpx

Does this look OK for you?

- Phil

[fakej]

Hi Phil,

I think that looks good very promising. Just a two minor questions:

• is there any exiftool version available where I could test this functionality? I can see the latest version on the homepage is 10.71 from 2nd of Jan
• is there any exiftool syntax that could generate gpx files from all mp4 files in the directory, possibly to some other directory? If there is not, that's not a problem I'm far from requesting features that do something that exiftool is not intended to do. I can simply wrap it with the shell script but if it is possible would be also great not to have such script )

[fakej]

oh, sorry I think I misinterpreted your question. If you are asking if the format of GPX file is OK, then - yes, it works well with my favorite dashcam player Registrator Viewer.

[Phil Harvey]

Great.  I've just released 10.72 with this new feature.

You can create gpx files for all videos in a directory like this:

exiftool -p gpx.fmt -ee -ext mp4 -w OUTDIR/%f.gpx DIR

You will need the gpx.fmt file from the fmt_files directory of the full .tar.gz distribution.  The command will generate lots of warnings about missing GPSLongitude from some embedded documents, but with any luck it should work OK.

Let me know how it goes.  This feature may need some tuning, and currently supports only 3 different formats of embedded GPS data.

- Phil

[StarGeek]

This is just so very cool.  I just wish I had something that would actually create files I could use this with.

[fakej]

Hi Phil,

This is really cool, thank you!
I've just noticed that GPX file contains only basic GPS coordinates (latitude, longtitude). I'm assuming the video file does not have any other data like altitude or speed, correct?

[fakej]

Phil,
Actually one more comment. I noticed it takes for the exiftool on my laptop around 5s to produce GPX file from ~700MB MP4 video file, while for the python script it takes around 0.5s. I'm guessing exiftool may read the whole file while the nvtk_mp42gpx.py may possibly know where to look for the GPS data. Do you think there is a chance for optimization?

[Phil Harvey]

I'm glad it works.  ExifTool shouldn't be reading the whole file, but I will look into this.

There is no altitude information, but there is speed and direction as well as lat/lon and time.  But you will have to modify the format file if you want the speed/direction added to the output gpx file.

- Phil

Edit:  But I don't ever expect ExifTool to be as fast as the dedicated script because it does parse all the rest of the metadata in the file.  However, I will check to see if it is loading any of the movie data that it shouldn't be.

[fakej]

Phil,

I understand that reading file with a known structure (what python script does) must be faster than discovering structure and reading afterwards (what exiftool does). Anyway thank you for looking into this problem.

Could you possibly advise regarding the gpx.fmt modification?

I tried the following command

root@GB3TO01TR123401:~/Image-ExifTool-10.73# ./exiftool -p /var/www/html/test_drive/gpxext.fmt -ee -ext mp4 -w "$f".gpx /var/www/html/test_drive/test_drive.MP4

trying couple of different versions of gpxext.fmt, where one of them is http://206.142.243.145/test_drive/gpxext.fmt to get speed and direction information but with no success. I must be doing some stupid mistake.

Also is there any chance to ask exiftool what kind of GPS information is available if I don't know that?

[Phil Harvey]

FAQ 2 explains how to determine the tag names in a file.  In your case you should add -ee to the command.

- Phil

[fakej]

oh, so it should have been using gpsspeed instead of speed and gspstrack instead of direction. Got it thanks
By the way is there an option to multilply gpsspeed by some constant value to get kilometers/miles per hour instead of knots?

I have seen the thread https://exiftool.org/forum/index.php?topic=1780.0 (8 years old already so maybe something has changed in the meantime) so I'm assuming it may not be possible in exiftool and I should use some external tool like sed or awk which is OK.

[Phil Harvey]

You can do arbitrary math on GPS speed like this in the fmt file:

${gpsspeed;$_*=1.852}

The above multiplies by 1.852 to convert knots to km/h.

This feature is described in the Advanced formatting section of the application documentation.  I doubt this feature existed 8 years ago, but back then this could have been accomplished though user-defined tags.

- Phil

[fakej]

That's perfect, I really appreciate your support. I promise to spend more time on documentation before asking next question.

[Phil Harvey]

I realized that I forgot to mention that the date needs to be reformatted for GPX.  The "Usage" example in the fmt file shows how this is done using the -d option.  But I have just come up with a better way to do this using a DateFmt function in the fmt file, like this:

Code Select Expand

#[BODY]  <time>${gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%SZ")}</time>

With this method, the -d option isn't necessary.  I've update the example on the geotagging page with this new technique, and the next ExifTool release will have updated fmt files.

- Phil

[gmc]

Hi Phil,

Hope you can help, I've got some files from a Garmin dash cam and this method isn't working for me, I'd appreciate it if you can have a look into this for me. I can start a new topic if preferred and send an example of the error I'm getting and an MP4 file.

Thanks!

[StarGeek]

Unfortunately, Phil, the author, is away on vacation right now until late September.  If you hit the "Notify" button in the upper right corner of this thread, you'll get an email when there's a response.  But definitely check back by October. 

[Phil Harvey]

Right.  The Garmin doesn't store GPSDateTime.  This will require a user-defined tag to generate this from CreateDate and the SampleTime from each fix.  The actual logic depends on whether CreateDate represents the start or end of the video.  There is a sample config file for DJI that does this, assuming the CreateDate is the end of the video.  For Garmin, a similar config file would be:

Code Select Expand

%Image::ExifTool::UserDefined = (
    'Image::ExifTool::Composite' => {
        GPSDateTime => {
            Description => 'GPS Date/Time',
            Groups => { 2 => 'Time' },
            SubDoc => 1,
            Require => {
                0 => 'SampleTime',
                1 => 'Main:CreateDate',
                2 => 'Main:Duration',
            },
            # (assuming CreateDate is the end time of the video, we subtract
            #  Duration because a SampleTime of zero is at the start of the video)
            ValueConv => q{
                my $diff = $val[0] - $val[2];
                my $sign = $diff =~ s/^-// ? '-' : '';
                my $time = $val[1] . '.000';
                ShiftTime($time, "${sign}0:0:$diff");
                return $time;
            },
            PrintConv => '$self->ConvertDateTime($val)',
        },
    },
);

Then use "-config my.config" as the first option in your command.

- Phil

[gmc]

Thanks Phil, I'll give this a try.

[gmc]

Hi Phil,

Unfortunately it's not working, not sure what I could be doing wrong.

Here's the output:

C:\Users\XXXXXXXX\Videos\Dashcam\>"C:\Program Files (x86)\GeoSetter\tools\exiftool.exe" -config my.config -p gpx.fmt -ee -ext mp4 -w OUTDIR/f.gpx 20190908
Error creating 20190908/GRMN0007OUTDIR/f.gpx
Error creating 20190908/GRMN0008OUTDIR/f.gpx
Error creating 20190908/GRMN0009OUTDIR/f.gpx
Error creating 20190908/GRMN0010OUTDIR/f.gpx
Error creating 20190908/GRMN0011OUTDIR/f.gpx
Error creating 20190908/GRMN0012OUTDIR/f.gpx
Error creating 20190908/GRMN0013OUTDIR/f.gpx
Error creating 20190908/GRMN0014OUTDIR/f.gpx
Error creating 20190908/GRMN0015OUTDIR/f.gpx
Error creating 20190908/GRMN0016OUTDIR/f.gpx
Error creating 20190908/GRMN0017OUTDIR/f.gpx
    1 directories scanned
    0 image files read
   11 files could not be read
    0 output files created

I've put the code from your last post in a file named my.config and put this in the same folder as ExifTool, is this right?

Thanks again

[Phil Harvey]

It looks like you don't have write permission for the output directory.

- Phil

[gmc]

Thanks again Phil. Looks like I'm getting closer but now all the output files contain is:

"gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
gpx.fmt
"

When ExifTool ran here's the output:

""C:\Program Files (x86)\GeoSetter\tools\exiftool.exe" -config my.config -p gpx.fmt -ee -ext mp4 -w OUTDIR/%f.gpx 20190908
    1 directories scanned
    1 directories created
   11 image files read
   11 output files created"

[gmc]

Moved gpx.fmt and my.config but getting output without any GPS info:

"<?xml version="1.0" encoding="utf-8"?>
<gpx version="1.0"
creator="ExifTool 10.96"
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>
</trkseg>
</trk>
</gpx>
"

[Phil Harvey]

can you confirm that this output shows GPSLatitude and GPSLongitude for the files?

"C:\Program Files (x86)\GeoSetter\tools\exiftool.exe" -ee "-gps*" 20190908

- Phil

[gmc]

Hi Phil,

I'm only getting the following output from that:

"C:\Program Files (x86)\GeoSetter\tools\exiftool.exe" -ee "-gps*" 20190908
======== 20190908/GRMN0007.MP4
======== 20190908/GRMN0008.MP4
======== 20190908/GRMN0009.MP4
======== 20190908/GRMN0010.MP4
======== 20190908/GRMN0011.MP4
======== 20190908/GRMN0012.MP4
======== 20190908/GRMN0013.MP4
======== 20190908/GRMN0014.MP4
======== 20190908/GRMN0015.MP4
======== 20190908/GRMN0016.MP4
======== 20190908/GRMN0017.MP4
    1 directories scanned
   11 image files read

[Phil Harvey]

That would explain why there are no coordinates in your gpx file.  ExifTool isn't extracting GPS from these files.

If you believe that they do contain GPS, send me a sample and I'll see what I can do to add the ability for ExifTool to extract it.  My email is philharvey66 at gmail.com

- Phil

[gmc]

OK, I've sent a sample file over to you using WeTransfer.com

Thanks

[Phil Harvey]

I got the sample.  The commands work for me with Exiftool 11.65.  Try updating to the most recent version of Exiftool.

- Phil

[call-151]

Hi, I am trying to create a .gpx from an .mp4 generated with a Viofo A119v3 dashcam.
I run this command in the folder with my mp4 files:

exiftool -ee "-gps*" 20190928*

and the output is:

======== 20190928080711_004253.MP4
======== 20190928081009_004254.MP4
======== 20190928081443_004257.MP4
======== 20190928081743_004258.MP4
======== 20190928082043_004259.MP4
======== 20190928082343_004260.MP4
======== 20190928082643_004261.MP4
======== 20190928082943_004262.MP4
======== 20190928083243_004263.MP4
======== 20190928121041_004265.MP4
======== 20190928121342_004266.MP4
======== 20190928121642_004267.MP4
======== 20190928121942_004268.MP4
======== 20190928122242_004269.MP4
======== 20190928122542_004270.MP4
======== 20190928130716_004273.MP4
   16 image files read

Do I need a special my.config file like gmc needed for his Garmin?
Running on Windows with exiftool version 11.67.
Thanks.

[Phil Harvey]

Can you send me a (hopefully small) video sample?  My email is philharvey66 at gmail.com

- Phil

[call-151]

Thanks for taking a look, Phil. I've also sent a file using wetransfer.com. Sorry the file is a bit big but I wanted one with actual driving vs. just parked.
Cheers

[Phil Harvey]

I got the sample, thanks.

I can see the GPS in the file, but it is in a different format than recognized by ExifTool.  I'll see what I can do about adding support for this format, and post back here if I need anything else from you.

If I am successful, there will then be 32 different formats of streaming GPS recognized by ExifTool.

- Phil

[Phil Harvey]

Success!  And ExifTool 11.68 has just been released to support this new format.

- Phil

[call-151]

Yes!! Thank you Phil!  Works like a hot damn!
I had to get rid of the <course> and <speed> elements out of the .gpx file so it would load into my old Mapsource software but now I can see where I have driven.
For those following along, I put the gpx.fmt file into the same folder as exiftool.exe and ran the command like this:

exiftool -p gpx.fmt -ee -ext mp4 -w OUTDIR/%f.gpx d:\Carvids_Trips\misc\20190928080711_004253.mp4

[Phil Harvey]

Great!

[gmc]

Thanks again Phil, I can confirm that it's also working for me with version 11.65

[off]

How about Ambarella Chinese cams that out MP4 with embedded data? ExifTool produce empty .gpx file

can share or send sample file (what e-mail should I enter if send via WeTransfer?)

[StarGeek]

The author is currently away until sometime next week.  If you hit the "Notify" button in the upper right corner of this thread you can get an email when he would be able to look at the file for you.

[Phil Harvey]

Send me a sample file and I'll take a look (my email is philharvey66 at gmail.com)

- Phil

[Phil Harvey]

I got the samples, thanks.

I can decode the GPS from the Ambarella A12 MP4 video.  ExifTool 11.77 will support this format.

I can't see any GPS in the A7 MOV video.

- Phil

[off]

I can't see any GPS in the A7 MOV video.

Thank you. I'll try to find power cable

[off]

Uploaded another pair of MOV-files from Ambarella A5 & A7, not sure about A5-file (without speed), pretty sure about A7-file (with GPS-coordinates and speed)

[GPSmapper]

Hi Phil,

Hi Phil,
Hope this message finds you well!

I have came across this topic and wondering if you could add support for one more format from dashcam (Blueskysea B4K, Novatek NT96670 )
https://dashcamtalk.com/blueskysea-b4k/

It uses H.265 HEV codec  and TS container.
Latest Exiftool does not seem to be able to recognize the gps exif data.

Sample file was sent by e-mail.

Thank you very much in advance!

[Phil Harvey]

I've looked at the .ts file you sent.  Unfortunately there is no trailer with GPS like some other .ts files I have.  This file contains only 3 programs: 1. clock reference, 2. HEVC video, and 3. AAC audio.  If timed GPS exists in this file, then it is in the HEVC video stream.  ExifTool doesn't yet have the ability to decode H.265, and it would be a LOT of work to do this (if I could find the specification at all).

I'll add this to my to-do list, but it won't be a feature that will be added in the near future.

- Phil

[GPSmapper]

Thanks Phil, I will try to get more details from the manufacturer, will let you know once I'll get something.

[GPSmapper]

ExifTool doesn't yet have the ability to decode H.265, and it would be a LOT of work to do this (if I could find the specification at all).

Hi Phil,
hopefully this will not be required (decode), I have sent you the specs I've got from manufacturer by e-mail.
Storage logic for MP4 and TS is different and explained in specs.
MP4 - you already support this since 11.68 (Viofo A119 V3) - using same chipset

Thanks

[Phil Harvey]

I got the documentation, thanks.  This was very useful.

The documentation says the GPS is in program ID 0x300, but there is no such program in the program map table of the file.

However, this program does exist in the file you sent.  I think this is an oversight on the part of the device manufacturer, and it will unfortunately mean that ExifTool would need to scan the entire video to see if this information exists.  This would mean a huge performance penalty for all TS videos.  I'm not sure how to deal with this.  Maybe you could suggest that they add this program to the TS Program Map Table.

- Phil

[GPSmapper]

Maybe you could suggest that they add this program to the TS Program Map Table.

I could give it a try, but considering the GPS data extraction possibility is not in their focus, I doubt they will be motivated to implement any changes in that regards.

Maybe you could try the other sample? Is it the same (missing program map)?

Both sample recordings  are coming from B4K dashcam, I do not have any Viofo A119 V3 TS samples to share, I will have this cam probably next week so we could check if it is he same issue.

[GPSmapper]

Also looking at p.4:

If the GPS recording function is enabled, the generated TS file will use a specific pid to insert GPS data every second. Unlike the MP4 format, which has an index table, the TS format must search each TS packet from the beginning to filter out the GPS data.

I read this as 'there's NO index available in TS'

This 'specific' pid is 0x47 0x43 0x00

anyway, will try to clarify what was meant in 4.1.2

[GPSmapper]

Hi Phil, while waiting for feedback from the B4K vendor, I have managed to 'decode' the gps blocks pattern, gps data is split between 2 packets.
It is not the same as described in the datasheet

it seems that this is quite common among Chinese manufacturers to 'alter' the default specs making resulting formats incompatible with competitor products (dashcam viewers).
B4K seems to be no exception.

Coordinates : packet 0x47 0x03 0x00: bytes 157 - 176: (green block)
active: string (1 byte) # satelite lock "A"=active, everything else (eg " ") lost reception
latitude hemisphere: string (1 byte) # "N"=North or "S"=South
longitude hemisphere: string (1 byte) # "E"=East or "W"=West
unknown: string (1 byte) always "0"
latitude: little-endian float (4 bytes) # unusual format of DDDmm.mmmm D=degrees m=minutes
longitude: little-endian float (4 bytes) # unusual format of DDDmm.mmmm D=degrees m=minutes

Datetime data: packet 0x47 0x43 0x00, bytes 175-188 + packet 0x47 0x03 0x00 bytes 147-156 (orange block)
hour: unsigned little-endian int (4 bytes)
minute: unsigned little-endian int (4 bytes)
second: unsigned little-endian int (4 bytes)
year: unsigned little-endian int (4 bytes) - bytes 187,188 AND 147,148 of the next packet
month: unsigned little-endian int (4 bytes)
day: unsigned little-endian int (4 bytes)

[Phil Harvey]

I read this as 'there's NO index available in TS'

There is a Program Map Table as I mentioned (run exiftool -v3 on the file).

Thanks for the information about the decoding, but this isn't the problem (at least not now -- I haven't tried to decode this yet).  Without an indication that the private program exists, ExifTool can not know how much of the file it needs to parse.  I have to think about this.

- Phil

[Manfred Prechtl]

I have a Redtiger F7N dashcam and I have got the folloing output from

Code Select Expand

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

Code Select Expand

"Warning = GPSLatitude/Longitude encryption is not yet known, so these will be wrong"
OK, they are really wrong.

Code Select Expand

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. 

[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.

[jollino]

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.

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:

Code Select Expand

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]

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.

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.

[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

[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