I open new topic because i’m not sure to be clear in previous one (Page not found).
For my christmas, i bought Blackvue DR900S-1CH because seems to be very easy, in particular : Direct Upload (Recommended)
“* Upload videos located in path/to/videos directly to Mapillary. Videos are moved to path/to/videos/uploaded folder after upload. Videos that do not contain valid imagery are not uploaded to minimize bandwidth usage. Sampling is performed in the cloud so no extra disk space is required. This command supports the front camera video from the Blackvue DR900s (1-channel and 2-channel) models.”
it’s recommended but it’s not realy working, there’s an lag, an offset, a time lapse (i don’t know the right term).
Example :
Mapillary)
and the good picture is 9 pictures before (Mapillary)
So do you think i continue to upload video (as recommended) or i try to find an other process ?
I use the (deprecated) local mode. If you wish to debug this error I would suggest running this on the movie with the lag error, but not upload. The georeferenced output images can then be compared with those on the web site.
I have seen GPS lag on some of my earlier BlackVue files.
There are some recommended settings for standard BlackVue’s that may need checking. eg Sync with GPS time on, 4K UHD Extreme 30FPS, H264 AVC, Normal Record On, Event and Voice record off
If you need command syntax assistance please ask.
1 Like
hi, today i uploaded others files and i saved them. So if i have same lag offset, i will test local mode.
Recommended process : Mapillary
locally → video_process then upload with webapp : Mapillary
So lapse-lag is due to mapillary servers.
Next time i will try video_process_and_upload process.
I stop using recommended process for blackvue (https://github.com/mapillary/mapillary_tools#command-specifications)
Yes that looks troubling. Can I suggest this is important enough to message support@mapillary.com with?
I don’t know how the server code works, but the local processing ffprobe’s the mp4 for a start date/time to get the individual image timestamps, then does a calculation on the gps data to match. I do notice though that your sequences above are at different framerates or differing duplicate distance.
I also found some time ago when the BlackVue standard 30FPS firmware was used and the tools processed down to 2FPS, the key or index frame was never selected. That is a function of the ffmpeg command line and use of framerate filter.
in january, i began with a message to support, then i came here and yesterday i add an issue : Lag-Lapse due to mapillary servers · Issue #367 · mapillary/mapillary_tools · GitHub
In january, answer : "
“the GPS to video lag is an issue we are aware of and are working on. There is no config change you can currently make to fix it. The only fix at the moment is installing the BlackVue consumer firmware, not the Mapillary firmware”
Interesting. That kind of suggests the mp4 start date/time header has a 2 second error when the Mapillary firmware is used, but ONLY when server side processed. I can see some code/processing workaround might work if the error was constant.
Which of your methods produces the correct result? Based on the map it seems that “locally” is the closest.
Are you using the standard 5 frames per second config? I am running 2.
yes, it’s “locally”.
this is what i used (so i suppose it’s 5 frame per second).
mapillary_tools video_process --import_path “import_path” --video_import_path “import_path” --user_name “numetlib” --advanced --geotag_source “blackvue_videos” --geotag_source_path ““import_path”” --use_gps_start_time --interpolate_directions --video_sample_interval 0.2 --device_make “Blackvue” --device_model “DR900S-2CH” --overwrite_EXIF_gps_tag
then i upload by Mapillary
next try will be video_process and upload in the same command line
Do you think 2 frame per second give a better precision ?
If you are using the Mapillary firmware it is already running at 5 frames per second. The configuration can be changed to a lower rate though. I chose 2 frames per second because most of my capture is on long country roads and Internet access in Australia is relatively expensive.
5 frames per second gives more useful images in an urban area. The geotag accuracy should not be any different as each frame has its date/time calculated and then compared to the gps/gpx data. The position is interpolated by the tools as needed from adjacent gps data points.
Your video process command line is the same as mine except for --overwrite_EXIF_gps_tag --duplicate_distance 1.0 --video_sample_interval 0.5. I have however modified the tools slightly to get better image quality.
I suspect that an upload from the command line will yield the same results as via the app. At that stage all the geo data has been written to the image EXIF so the server wont alter it.
Also be aware that the BlackVue gps fix can be a little slow with inaccuracies even with the blue led on. I sometimes see 5 second errors against another unit in the first captures of the day. Easiest way to check that is to compare the gpx data output from the Blackview processing against another navigation unit.