Thanks to everyone who tried to help!
I found solution myself, for my scenario I had to add –desc_path parameter
video_process does the same as sample_video? Maybe this happens when you pass a video file explicitly. Try to pass a folder with that video file in it or pass --filetypes video with a video file. Generally speaking, you should not need to sample frames for Mapillary uploads because the backend can also process video files directly once you process a valid GPX track locally. You can sample frames from video and then upload images but this is no longer necessary. Usually, it is easiest and most efficient to let Mapillary servers handle this step.
Ah, one last note: Always check timestamps after upload for timezone and DST shenanigans! If the capture location observes DST it usually happens at least twice a year. 
I was able to batch process my dashcam video from older 70mai A800 cam that has different format of GPSData000001.txt I called it “v1” since it’s older. Here are some samples from cam in comparison with GoPro Hero7 shot at same time and conditions. Also I uploaded back cam videos that have lower resolution:
- GoPro Hero7
- 70mai A800 front cam
- 70mai A800 back cam
Some details on GPSData000001.txt I had not only GPSData000001.txt, but also GPSData000002.txt and GPSData000003.txt, largest file size was 80Mb
Format comparison:
v1 (A800)
2025-08-20 07:17:54,B,A,022km/h,56.945194,24.003354,0,20250820-101658-006000B.MP4
v2 (T800)
1786143473,A,56.974796,24.245983,18200,27,88,-4,46,NO20260808-095750-009519F.MP44,0,0,0
Summary on both.
I used videos from “Normal” folder, that’s normal driving videos.
There also Parking, Lapse, Event folders.
“Normal” videos have “NO” as first 2 letters in filename. “Lapse” have “LA” and so on.
v1 difference
- GPSData000001.txt “NO” is not added to filename as prefix.
- Normal date/time pattern is used instead of timestamp, but. Time section of filename has probably some other time zone (07:17:54 vs 101658).
- Speed is written with “km/h”
At the end of file name there is usually F suffix that sands for “Front”. On A800 I had B for “Back” cam, but in T800 they use R for “Rear”. My T800 also has “Cabin” cam videos that have “C”. These are also subfolders of “Normal” Folder.
in GPSData000001.txt however if both Front and Rear videos were recorded only one of them is written, sometimes F, sometimes B/R
In my T800 version there is probably some bug in firmware as sometimes filenames have “.MP4” as they should, but sometimes “.MP44” and “.MP444”
Now I want to upload some T800 video, but I encountered some mapillary_tools issue.
Older A800 were 3 minutes videos, but now I have 1 minute videos from T800 and I believe this might be the issue as extracted .gpx file stores shorter driving path and I always? (haven’t checked all the videos from T800) get MapillaryStationaryVideoError error
There is no detailed description in help files on the error, in source code I found
max_radius_for_stationary_check=10.0
AI explained that first and last point of .gpx should be more than 10 meters? away.
In my file I had 380m, but still get error.
NO20260812-173202-010811
Is this the recording time 17:32:02? And here you go - 2026-08-12T06:32:05.000.000Z in .gpx
I also thought it is connected and was changing time in my gpx with different offset, but that didn’t help.
Than I tried to use some .gpx file extracted from GoPro video recorder in 2025 and “process” command didn’t gave any errors, I was able to produce desc json
My guess is that previously I was using 3 minutes videos and gpx tracks were longer
Hey, this looks really good and much better than the dashcam! 
Hence, I would not bother with the dashcam for Mapillary at all because it basically adds no value over the GoPro. Instead, I would rather invest in a large SD card, perhaps more batteries or a long high quality USB cable for power on the roof, good car mount, and a case to put the GoPro on the roof. Besides, the GoPro HERO7 Black can capture in 4K (4:3, 3,840×2,880) at 25 fps and record GPS in a GPMF stream too, if you really want to go with video. This is plenty fine for Mapillary and offers the smoothest workflow. Alternatively, you can go with the 0.5 s Photo Time Lapse mode at 4,000×3,000, which is also plenty fine for driving at urban speeds. 
Hence, I am not sure it is worth chasing for data from a mediocre and cumbersome dashcam.
Thanks for reply, however:
I use and prefer GoPro for Mapillary capturing, and for me it remains the best option. But I don’t think GoPro should be considered a requirement for contributing imagery.
Not everyone has a GoPro, and not everyone can or wants to buy one specifically for Mapillary. I certainly don’t expect some random person to spend money on a GoPro just to contribute. If they already have a dashcam, they can use what they have and still add useful imagery to Mapillary.
I’ve actually been pleasantly surprised by the quality of images extracted from the 70mai A800. I expected video-frame extraction to produce much worse results, but the imagery is surprisingly good and quite usable.
There is also a practical reliability aspect. This summer my GoPro failed me multiple times: once it simply hung, and on other occasions it overheated and stopped working. So having another camera option isn’t just about image quality — sometimes having something capturing is better than having nothing.
The same applies to rear imagery. With a T800 4K rear camera, I expect the resulting images to be noticeably better than having no rear coverage at all when using a single GoPro.
So my point isn’t that a dashcam is better than a GoPro. I still prefer GoPro. My point is that we shouldn’t discourage people from contributing just because they don’t have the “ideal” camera. If a dashcam can produce useful imagery, that’s still valuable Mapillary coverage.
2 Likes
I was able to solve the issue myself. Turned out that generated .gpx (AI script issue) had wrong date format:
2026-08-12T06:32:05.000.000Z
instead of:
2026-08-12T06:32:05.000Z
But MapillaryStationaryVideoError is also misleading in this case, there should be some .gpx validation that would say that .gpx has wrong timestamps.
This is why you always have to verify every LLM output and must never trust it blindly because it is nothing more than a probability machine. It is like with auto-pilot; it can make your life easier or help you be more productive but you always have to be ready at the helm to intervene anytime.
Right, subjecting GPX files to a GPX XML schema would really help here for more concise debug and error messages because you immediately get the exact location where something is off. CC @tao
1 Like
cc: @caglarpmeta