BlackVue legacy dashcams support

Hi all,

I would like to contribute and am using Blackvue DR650S-1CH dashcam mounted.
I have tried mapillary+tools on my Windows7 machine and got stuck.

  1. As I understand, “send_videos_for_processing” will not work as it was meant for latest DR900 series only. DR650S cameras do not store GPS data in the video file, but in a separate files (with .gps extension)
    The gps file is in NMEA format but with each line prefixed with a timestamp. e.g.


  1. I have tried deprecated “video_process” command and still no luck.
    mapillary_tools video_process --import_path "d:\mapillary\images\" --video_import_path "d:\mapillary\video\" --user_name "gpsmapper" --advanced --geotag_source "blackvue_videos" --geotag_source_path "d:\mapillary\video\" --use_gps_start_time --interpolate_directions --video_sample_interval 0.2 --device_make "Blackvue" --device_model "DR650S-1CH" --overwrite_EXIF_gps_tag

I have tried changing geotag type to “nmea” and removing device_make / device_model options…

Error I am getting:

Traceback (most recent call last):
File “mapillary_tools”, line 76, in
File “mapillary_tools\commands\”, line 144, in run
File “mapillary_tools\”, line 3, in apply_camer
AttributeError: ‘NoneType’ object has no attribute ‘lower’
[xxxx] Failed to execute script mapillary_tools

Could you please advise - where is my problem? What should I try to make it running?


1 Like

I use the later model and have been trial using the .gps files by converting to gpx first. eg;

cat *.gps | cut -c 16- |grep GP| gpsbabel -i nmea -f - -o gpx,gpxver=1.0 -F curr.gpx

This is Linux bash unfortunately, but similar text manipulation tools exist in Windows.

I haven’t checked but would assume that - -geotag_source "blackvue_videos` only works on embedded mp4 data.

I have realized that 1st step would be anyway converting “gps” flies into standard nmea and then to gps (gpsbabel).

I think I have managed to do it.
However, I still need to run ‘sample_video’ and ‘process’ separately, while ‘video_process’ does not work for me for some reason.


  • convert .gps to nmea (using cat/egrep on Unix or Notepad++ regex on Windows)
  • (optional) convert nmea to gpx with gpsbabel. But nmea should work as well
  • mapillary_tools sample_video --import_path “path_to_images_folder” --video_import_path “path_to_video_folder” --video_sample_interval 0.5 --advanced
    this will create images, but still no exif, as legacy dashcams to not support capture time meta
  • mapillary_tools process --advanced --import_path “path_to_images” --user_name “mapillary_username” --geotag_source “gpx” --geotag_source_path “path_to_gpx_file” --use_gps_start_time --interpolate_directions --overwrite_all_EXIF_tags --duplicate_distance 0.1
    *(optional) you can add --offset_time option to get a better sync between video and gps data

To make life easier, it is worth joining video clips and gps file together before processing, otherwise the above steps would be required for every 5 min clip…

Also, legacy web uploader could be used once gps files are converted into gpx.

The tools use ffmpeg to stream process the videos, and it has a concatenate functionality if useful. I advise some caution though as (in the BlackVue device I use) there is a frames/time overlap between movies that would result in a timing (and GPS) error getting worse with each concat. The tools also use ffprobe to extract some data (start time, rate and total frames perhaps), so that’s a concern (ffmpeg can be set to drop frames intentionally though.)

The BlackVue device I use creates a .gps and .mp4 file(name) that are correlated, so I thought I’d try your (failed) video_process method. I took 3 mp4’s against converted gpx for the whole day, but it came back with full geotagging errors. It didnt crash like yours though. I suspect that in this mode it falls back to the EXIF tag “Original Date and Time”, which comes from the file date. I grab my mp4’s over WiFi with wget and this seems to result in a 63 second error. (ie the difference between creation and modified dates) If I continue the experiment I’ll likely force the video start with --video_start_time (epoch seconds)

ok, I think i have managed to get things done.
Now trying to clarify some post-processing aspects with support and here:

Will post detailed instructions for legacy BlackVue dashcams later

as promised, sharing my workflow for the ones who a using legacy Blackvue dashcams (models prior to DR900)

Key complications of the legacy models:

  • gps logged in a separate files, not embedded in the videos
  • videos do NOT store ‘capture time’, so this can’t be extracted from the files during sampling
  • if you are using parking and emergency modes, you have to be careful when geotagging sequences from gps log

Note: maybe current DR590 dashcams (no-cloud) support the above, instructions below assume they don’t

Work flow:

  1. copy video sequence from the dashcam along with respective .gps files. to a temp folder.
    Make sure sequence you will be processing is continuous and does not have breaks (i.e. time-cuts while running in the parking mode)
    If you have a time-cut (i.e. parking mode activated), you should split the processing sequences (when recording was stopped.for a while)
    You could check this using either Blackvue player or filenames.
    Normally you should get multiple files ordered sequentially.

  2. copy corresponding *.gps files to a single file
    copy *.gps track.nmea

  3. run the video sampling, 1 fps for driving appears to be optimal
    mapillary_tools sample_video --import_path "path_to_folder_with_samples" --video_import_path "path_to_folder_with_videos" --video_sample_interval 1 --advanced

  4. copy all videos from mapillary_sampled_video_frames subfolders into one folder for further processing.
    some option how to achieve this are here

  5. IMPORTANT: if your dashcam has ‘emergency’ event recording enabled, it could happen that emergency event will be triggered during one of the recordings in you sequence.
    Every emergency video contains a copy of last 5 seconds from the previous video. (5-6 frames/1fps)
    Before continuing - you will need to clean up duplicate frames in your sequence manually, otherwise geotagging from the gps track will not be accurate (get shifted 5 sec with every emergency video event).
    Check if your video sequence has any emergency recordings (with EF in the name).
    If it does, go to the samples folder and clean the duplicate frames before each emergency (EF) recording.
    Usually you have to delete 5 last frames (assuming you are sampling at 1fps) of the sequence before EF, sometimes it could be 6.
    in this example you have two Emergency events triggered one after another.
    You should check and delete duplicate frames from 20190422_064510_NF samples and from 20190422_064535_EF samples!
    Datestamp on the recording would be very handy here

  6. make sure that timestamp on the first frame in your sequence is matching the EPOCH timestamp of the first line in the track.nmea. Epoch converter.
    If this is not the case, remove all lines BEFORE the lines with correct timestamp First record should be matching the first frame in your processing sequence!
    First line in the track.nmea:
    Epoch timestamp = 1555922039534 = Monday, April 22, 2019 8:33:59.534 - this is the system time of your daschcam and this what you see on the video (timezone is UTC+2)
    GPS timestamp = 063355.00 = 06:33:55.00 (UTC)
    First frame from the sequence:
    As you can see, GPS time is not matching the system time of the camera (system is 4sec ahead of GPS), that’s why it is important to align first frame with gps log using epoch timestamp.
    This is a critical step as we will be using gps-track geodata as a start datetimestamp for geotagging of our whole sequence

  7. Now we are ready to clean the blackvue gps file (created in step 2) from epoch timestamps.
    You could use Notepad++ - ‘Find and Replace’ - regexp - […]
    also you could remove empty lines using ‘Edit>line operations’ in Notepad++

  8. In most cases you will need to remove some frame files from your processing sequence (i.e. duplicates from emergency recordings). Removing any of the sampled images from our sequence results in breaking the continuous increment timestamp applied by mapillary_tools during sampling
    (first frame gets 1970:01:01 00:00:00.000 timestamp and next files are incremented by 1 sec in case if 1fps sampling was applied)
    So, before moving forward we need to restore the sequential order of the datetimestamps in the files.
    Easiest way to that is to use ExifTool
    First set the timestamp for all photos to the start of the sequence
    exiftool -datetimeoriginal="1970:01:01 00:00:00" -overwrite_original --progress:"Processing %p%%" -progress *
    In the next step, you’re going to increase the timestamp with 1 second more for each subsequent photo: exiftool "-datetimeoriginal+<0:0:${filesequence;$_*=1}" -overwrite_original -progress:"Processing %p%%" -progress *

  9. we are finally ready to start processing
    mapillary_tools process --advanced --import_path "path_to_processing_folder" --user_name "your_username" --geotag_source "nmea" --geotag_source_path "path_to_track.nmea" --use_gps_start_time --interpolate_directions --overwrite_all_EXIF_tags --duplicate_distance 3
    I have noticed that duplicate_distance option is not working reliable, leaving a lot of ‘duplicate’ frames (i.e. standing on traffic lights) in the sequence. Increasing this distance further may create a risk of false positives.
    After processing is finished, I’m searching for ‘duplicate’ files in the logs folder (using search command), make a not of the frames where duplicates were reported, and doing an additional cleanup of the frames manually.

  10. It could happen that gps log from dashcam will miss some positions.
    It happened to me several times when the fix was lost for 3-15 minutes.
    This results in the incorrect placement of the frames on the road.
    You may want to check the placement of the processed files PRIOR to upload using Geosetter
    If you will notice any anomalies - just remove ‘buggy’ frames from your processing folder prior to running upload.
    You could snap these frames back to the road in Geosetter, but effectively, doing this manually for 1000k frames is nightmare.
    I was trying to find out any tools to semi-automate this - but failed.See discussion here.

  11. We are ready to upload :slight_smile:
    mapillary_tools upload --import_path "path_to_folder_with_samples"

1 Like
F:\BlackVue\20190429-kyiv\01>D:\mapicam\tools\mapillary\mapillary_tools-050.exe video_process_and_upload --advanced --version --verbose --import_path "F:\BlackVue\20190429-kyiv\01\Record\30fps" --video_import_path "F:\BlackVue\20190429-kyiv\01\Record" --user_name velmyshanovnyi --skip_subfolders --geotag_source "blackvue_videos" --geotag_source_path "F:\BlackVue\20190429-kyiv\01\Record" --offset_angle 0 --use_gps_start_time --interpolate_directions --duplicate_distance 0.5 --move_duplicates --move_uploaded --video_sample_interval 0.033  --device_make "Blackvue" --device_model "DR900S-1CH" --overwrite_all_EXIF_tags --overwrite_EXIF_time_tag --overwrite_EXIF_gps_tag --overwrite_EXIF_direction_tag --overwrite_EXIF_orientation_tag --number_threads 1 --max_attempts 100  1>>F:\BlackVue\20190429-kyiv\01\mapicam-LOG.txt

Traceback (most recent call last):
  File "mapillary_tools", line 76, in <module>
  File "mapillary_tools\commands\", line 179, in run
  File "mapillary_tools\", line 161, in post_process
  File "mapillary_tools\", line 680, in get_duplicate_file_list
NameError: global name 'root_dir' is not defined
[6204] Failed to execute script mapillary_tools

Hmm, video_process_and_upload is intended for DR900S dashcams. Other dashcams are not supported.
Anyway, if you are having DR900 - I can’t really advise why it’s not working (I do not have DR900S).
This thread is dedicated to ‘legacy’ models where you have to do everything manually.

There’re some topics related to DR900S, maybe it’s better to ask questions there…