Hello, I just bought a DR900X-2CH, but to my surprise, the upload tool does not find GPS tracks in the videos.
Also using mapillary_tools won’t work.
I am pretty sure there are embedded GPS tracks because I can see them with the blackvue viewer (there are no files other than the .mp4), and also with dashcam viewer.
Do you have any suggestion about how to elaborate the videos for upload?
Also, would it be possible to modify the firmware of Blackvue?
Thanks!
Have you tried the desktop uploader? I think that takes the mp4 files straight from the device BUT the device I have came from mapillary so may have different firmware.
Yep thanks, I tried that one as well. It just moves all the file in a folder named “no_gps_data”.
I am experimenting with exiftool now, I confirm there is GPS data inside, I assume I can extract it and recombine later.
You might also contact support@mapilary.com and see if they can provide "mapillary firmware’ for the device
I tried that, but other than being for the 900S (I own a 900X), which I could not find for sale, they wrote me it is buggy and not worth to use, better use the 900S as standard video recorder and upload the video.
I am actually able to do firmware, I am not sure how I could accomplish that, though.
It is really hard to extract tagged images from the .mp4 via exiftool and mapillary tools.
mapillary tools cannot extract the timestamp from the video, and the GPS timestamps are all wrong (which seems really weird, as the GPS chip usually gives the perfect timestamp!).
So I have no way to match timestamps / frames / coordinates 
I invested some money in the Blackvue cam because I read posts about being “officially supported” and the best way to shoot imagery.
There used to be a custom firmware for the DR900S that did geotagged photos.
The matter is, DR900S is discontinued, the firmware doesn’t work on the DR900X and anyway it was discouraged by Mapillary guys directly.
Save your strength, Mapillary tools currently does not support GPS data in videos
In both in mapillary_tools and desktop uploader there is a special function to upload Blackvue videos.
It doesn’t work with the DR900X videos, though.
I am trying to go the split /.gpx / tag way, but the .gpx and the video have some non-sense time offset, which is not just timezone, which is hard to figure out.
I know photos work best, I have a VIRB 360 which I used, but I feel the resolution was not enough to resolve all the details. That is 4K over 360° while the Blackvue is 4k over 160°
DR900X only has timelapse mode while parking
I am considering building my own, RPI zero W 10€ + hi res cam 12MP + 60€ + wide eye 30€ + GPS module 15€, about 120€ for a camera that is also able to upload by itself as soon as it gets wifi…
I am using the DR900S with Mapillary firmware, for over 7 million images. Initially I used the tools to create images locally. Now I use the tools to upload the mp4’s. I have never used the desktop uploader.
When the tools are used a gpx file is created for each mp4. It’s also worth noting that the unit creates pseudo nmea sentence files for each mp4. This can be downloaded with wget/curl via its WiFi port. AFAIK it doesn’t end up on the SD card. I use these as a source for OSM traces by parsing/concatenating to a single gpx file per day. The great thing about the converted nmea file over the tools created one is that it has heading, speed etc data.
I’d suggest that if you want to process the mp4’s as a standard non BlackVue type, grab the pseudo nmea files and make a local gpx file. I am sure I have posted the script on this previously but shout if it is needed again.
Also be wary of invoking anything timelapse/parking as it basically creates a variable framerate mp4 that may mess conversion to images.
Also a fallback to gps vs frames is that the filename is the date/time of the first extracted (keyframe) image. This has a possible +/- 0.5 second error.
Thank you @bob3bob3.
900X seems working in a complete different way.
I could extract the gpx track from the mp4 and even see the NMEA data with exiftool, but the timestamp was off of an odd amount (not multiple of hours). None of the mapillary tools and utilities work with the mp4 files of the 900x.
I ended up sending it back and buying a a 4K Aukey DRS1 with external GPS, it has wide eye, 1s time-lapse mode and wifi, for about 120€. Let’s see how it works…
OK, but how I know that the first keyframe matches the first gps position? I have no gps time/video time matching value
@vitom academic comments since you have already changed.
The GPS start mismatch may in fact be invalid data. It takes my unit 1-2 minutes to lock up when stationary, and something like 5-8 minutes if I am moving. Generally I don’t start moving until the lock LED has been on for 10 secs. If you see a 1-8 minute variable delay in your nmea data that may be the reason.
The unit also has to get it’s time and zone from somewhere. The Mapillary recommendation is to get it from the GPS itself, but it is possible to set manually or get from an NTP server. The filename (date/time) is also generated for the timezone that has been defined.
Its important to use the H264 not H265 codec, mainly because the higher compression leads to lower quality still images. It also takes ffmpeg (that runs under the tools) 10-20x longer to decode the 265. That’s a huge factor if the standard 30FPS movies are being generated. (200MB file for every minute)
Unrelated. Using the BlackVue WiFi connection concurrent to capture causes dropped frames. ie variable frame rate. The tools expect a fixed frame rate for movies. It is probably worse when using H265 as its likely a CPU limit/usage thing.
Cheers!
This is an extract of the EXIF data (GPS section) I can retrieve from the .mp4 via exiftools:
[1611723852888]$GNGGA,155023.00,4542.48364,N,00854.66337,E,1,12,0.66,296.0,M,47.2,M,,*49
[1611723852888]$GNRMC,155024.00,A,4542.48446,N,00854.66496,E,4.754,52.29,270121,,,A*41[1611723853890
[1611723853890]$GNGGA,155024.00,4542.48446,N,00854.66496,E,1,12,0.66,296.0,M,47.2,M,,*45
[1611723853890]$GNRMC,155025.00,A,4542.48491,N,00854.66628,E,2.793,58.34,270121,,,A*46[1611723854888]
It looks clearly [timestamp before][GPS data with time][timestamp after].
It might look like this is the solution to the problem. However the timestamps there do not match the other video timestamps, not the real time when the video was shot, so I still don’t have a clear correspondence between all the timestamps.
When I shoot this video, video time was not set to be synced via GPS. After I set it, the time was closer to the right time, but still not on spot.
Blackvue video player reconstructs everything correctly, so there must be some rule. I asked the support, but it doesn’t seem they want to go down in details.
I just received the Aukey cam and I will have a ride with it for test. Anyway, just for the sake of it, I want to try to extract frames from these videos I shot.
Maybe I will upload one file on google drive for later, maybe someone of you guys wants to play some sudoku 
Interest only
This is a dump of the related mp4 “gps” file from the DR900S - downloaded via the units WiFi.
[1612007636223]
[1612007636223]$GPGGA,005352.00,3535.19603,S,14625.13554,E,2,12,0.65,157.5,M,7.4,M,000079
[1612007636223]$GPGSA,A,3,05,02,12,26,23,29,20,18,25,15,50,13,1.12,0.65,0.910E
[1612007636223]$GPGSV,4,1,13,02,10,118,18,05,48,119,36,12,24,017,26,13,05,071,1876
[1612007636223]$GPGSV,4,2,13,15,10,036,30,18,41,276,39,20,17,333,41,23,14,338,387E
[1612007636223]$GPGSV,4,3,13,25,57,338,38,26,15,222,38,29,65,189,33,31,10,264,417D
[1612007636223]$GPGSV,4,4,13,50,44,329,3742
[1612007636223]$GPGLL,3535.19603,S,14625.13554,E,005352.00,A,D7F
[1612007636223]$GPRMC,005353.00,A,3535.19400,S,14625.11987,E,46.653,278.85,300121,D4B
[1612007636223]$GPVTG,278.85,T,M,46.653,N,86.402,K,D32[1612007637230]
[1612007637230]$GPGGA,005353.00,3535.19400,S,14625.11987,E,2,12,0.67,157.7,M,7.4,M,000079
[1612007637230]$GPGSA,A,3,05,02,12,26,23,29,20,18,25,15,50,13,1.13,0.67,0.910D
[1612007637230]$GPGSV,4,1,13,02,10,118,16,05,48,119,36,12,24,017,24,13,05,071,1775
[1612007637230]$GPGSV,4,2,13,15,10,036,30,18,41,276,39,20,17,333,40,23,14,338,397E
[1612007637230]$GPGSV,4,3,13,25,57,338,38,26,15,222,39,29,65,189,32,31,10,264,407C
[1612007637230]$GPGSV,4,4,13,50,44,329,3742
[1612007637230]$GPGLL,3535.19400,S,14625.11987,E,005353.00,A,D7F
[1612007637230]$GPRMC,005354.00,A,3535.19200,S,14625.10418,E,46.665,278.75,300121,D4A
[1612007637230]$GPVTG,278.75,T,M,46.665,N,86.423,K,D3B[1612007638226]
Yes the number in is epoch time. I was hoping it was G sensor data! At one stage I downloaded the entire data packet from the unit but didn’t try to analyse.
I just strip the timestamp(s) and convert to gpx with gpsbabel to create my OSM traces. I also use it to do some geo-encoding of 1FPS derived jpg’s for manual mapping updates. This is a script process using ffmpeg (extracting only index frames), touching/timestamping/incrementing each jpg file based on filename, jhead (initialize exif header) and then gpscorrelate. I then add speed and track with exiv2. This only works for 1 second resolution, but could be used as tools input.
Since Blackvue seems to need a vendor specific player to get GPS in videos to work correctly, can’t you simply export the video from the player (that automagically puts everything together) into a .mp4 file? .mp4 has a well defined standard for GPS in/with video streams
I do have an .mp4 already with embedded GPS, straight from the memory card. The GPS track time is not synced with the video time. The Blackvue video player can sync them, but it does not output any file, just viewing. I extracted the .gpx and tried all the tricks, no luck yet to make them marry again.
Mapillary tools does not recognize the .mp4 as a valid blackvue video.
@bob3bob3 your data looks very similar to mine.
If you take e.g. this line
[1612007636223]$GPGGA,005352.00,3535.19603,S,14625.13554,E,2,12,0.65,157.5,M,7.4,M,000079
You have epoch timestamp 1612007636.223 → Saturday 30 January 2021 11:53:56.223 UTC
and GPS timestamp 00:53:52. So if you consider an assumed timezone of +13 / -11, also your video/GPS time seems off by 4 seconds…
In the example I posted above I had:
Epoch 1611723852.888 → Wednesday 27 January 2021 05:04:12.888
GPS timestamp 15:50:23
I extract that data by issuing exiftools -b
You can actually extract also the accelerometer data by issuing exiftools -ee, you will find something like (yet another time signature):
Time Code : 0
Accelerometer : 13.2 -2.7 -2.1
Time Code : 0.1
Accelerometer : 10.6 -2 -2.8
Time Code : 0.2
Accelerometer : 14.5 -2.7 -2.1
Time Code : 0.3
...
This is the information I retrieve from one of the files, it is hard to understand which time I should use for syncing. Mapillary tools complains that the GPS time does not lie within the video time, and that the video has no timestamp so it is supposed to start at 0 
Track Create Date : 2021:01:27 16:06:09
Start Time : 2021:01:27 05:05:08.234
Original File Name : 20210127_050508_EFS.mp4
First GPS data:
[1611723616805]$GNGGA,154627.00,,,,,0,04,10.70,,,,,,*79
Epoch: 27 January 2021 05:00:16.805, GPS:14:46:27
I dont think the GPS NMEA stream is synchronous with the video. It just has to cover the time that the video has been recorded over. I have noticed duplicate NMEA data from one mp4/gps file to the next (that I just remove with uniq) Each mp4 also has a variable length that can yield 60 or 61 index frames at 1FPS.
I am using the Mapillary firmware config/set to 2FPS.
The GPS device granularity is 1 second.
The positional data for each frame has to be interpolated from the NMEA steps. The date/time of the first frame then is the important thing. I remember wandering through the tools code some time ago and found that it wasn’t getting that from the metadata, but at some buried offset. Since my mp4 uploads were working okay I didn’t pursue.
I do remember however that there was a post some time later that mentioned “standard” mp4’s and a gpx file no longer worked and that the epoch time had to be entered on the tools command line. Sorry for being vague at this. It wasn’t really an issue for me…
Don’t worry, all precious information, I will keep playing with this and let you know if I can get any decent result.
So are key frames better, do they have a better definition?
A big portion of my struggle happens because mapillary_tools “process” command is flawed
I am trying to merge .gpx data with timestamped photos.
Warning, time t not in scope of gpx file by 31622367.0 seconds, interpolation of latitude and longitude failed for image C:\mapillary\aukey images\mapillary_sampled_video_frames\20200201084056_000041\20200201084056_000041_000001.jpg
Pretty sure the .gpx track time matches the photo timestamp…
That’s one year…Note the filename is out by one year as well.
The DR900S produces filenames of the current date. ie one of mine today was;
20210202_113141_NF.mp4
When processing the mp4, the tools use its filename as part of the final (jpg) image name. ie the tools has a gpx file for only a day or two ago, but it thinks the movie was made a year ago.
Key (or I) frames have fewer artefacts as they only have single frame compression like a jpg. The others are change derived from an I frame and/or others and degrade accordingly. How much depends on the processed bit rate and compression method used.The DR900S standard firmware creates only one keyframe per second at 30 frames per second
Oh gosh, really, 1 year!!! I spent a whole night on it :D:D:D That’s from the Aukey camera