Mapillary_Tools "Mapillary Capture Speed Too Fast Error" when capturing at freeway speeds via GoPro TimeWarp

Recently I drove across the country, mostly on interstate freeways, so I thought I would take the opportunity to take photos along the way. Camera is GoPro Max and I am uploading via Mapillary Tools.

I was going to simply take video as suggested on the Mapillary GoPro Max page, but I realized the resulting files would be FAR too large to fit on the SD cards I had with me.

I thought that Time Lapse video at an interval of 0.5 seconds would result in too widely spaced photos, so I hit on the idea of instead shooting Time Warp video at the rate of 6 per second (Time Warp creates a 30 fps video file, so a 5X time warp gives 30/5=6 shots per second.)

This reduces file size by a factor of size, seems to give a good-enough distance between photos, and the clarity seems OK. I don’t see any particularly noticeable blurring due to speed, for example. Compare this with the MAX vs the simultaneous capture from my cell phone, for example. The Max is capturing at 6X the rate.

However: When processing the resulting videos with mapillary tools, I get these errors:

2025-07-21 17:36:06,506 - INFO - 4490 image(s) read in total
2025-07-21 17:36:06,513 - ERROR - 4490 image(s) failed due to MapillaryCaptureSpeedTooFastError
2025-07-21 17:36:06,531 - ERROR - MapillaryProcessError: Failed to process 4490 files. To skip these errors, specify --skip_process_errors
. . .
WARNING: Sequence at …\processed\gopro_GH017400 will not be uploaded. No GPS info was found.

Looking at the image description .json file, I see many repetitions of this:

{“error”: {“type”: “MapillaryCaptureSpeedTooFastError”, “message”: “Capture speed too fast (exceeds 111.111 m/s)”}, “filename”: “U:\mapillary\gopro_downloads6\processed\gopro_GH037407\GH037407.mp4\GH037407_0_000001.jpg”, “filetype”: “image”}

So it seems that any time a certain speed is exceeded, this error appears and then those files are not uploaded. On the upload side it says “No GPS info was found.” but in fact all the photos do have GPS info included. The actual problem appears to be the listed “MapillaryCaptureSpeedTooFastError”.

For now my solution is to process the video into photos via mapillary tools, but then to upload via the windows uploader app instead of mapillary_tools upload. This seems to work OK.

Questions:

  • Is there any way to avoid this “MapillaryCaptureSpeedTooFastError” when following a capture procedure such as I outline above? (In general this using Time Warp on the Max seems a useful technique on the Max, resulting in FAR smaller files and thus greater capture potential than Video mode. But it’s difficult if such files will require a different workflow.)

  • Will adding “–skip_process_errors” allow the files to be properly processed and uploaded? My impression was, this would simply SKIP errors and allow processing to continue after skipping over the problem file.

I can keep uploading via the windows uploader, but I have a backlog of many hundreds of thousands of photos now (!) and would rather streamline the process if I can…

1 Like

Answering one of my own questions, I tried running with --skip_processing_errors and there was no change - still the same errors as outlined above, and no upload of those files. (Again I will just use the desktop uploader instead.)

Could you check the GPS info? It looks like there is no difference between the GPS in the files. The error will only occur if the speed is more than 111 m/s (400 km/h). Or you are driving a Bugatti Veyron :wink:

1 Like

Aha, the light dawns. Looking at the time codes for the individual frames, because it was recorded as “Time Warp” at 5X, it is basically coming to the conclusion that I was going 5X as fast as I really was.

It is at 30fps, so according to the time codes in the resulting .jpgs, I’m flying through 30 of them in one second.

>>> Edit/Minor Correction: The actual FPS of the recorded files is 29.97fps rather than 30fps.

I was going say 70mph so it is figuring I’m doing 5X that, or 350mph (roughly 110 km/hr X 5 = 550 km/hr). So …

Probably can be fixed by inserting at some point that the FPS is 6 instead of 30 . . .

And it looks like that can be done with an FFMPEG conversion like this:

*ffmpeg -y -r 6 -i timewarp_vid.mp4 real6fps_vid.mp4*

>>> Edit/Correction:

ffmpeg -y -itsscale 4.995 -i "timewarp_vid.mov" -vcodec copy "slow.mov"

Ths basically forces ffmpeg to view the timewarp_vid.mp4 as having 6fps instead of 29.97. The -itsscale method just copies the whole file over with the new FPS included, and works in just a few seconds.

The -r method “works”, too - in a way. It basically re-encodes the whole file - so for example it came out with a new, much smaller, file size (this could probably be adjusted with ffmpeg options, somehow). But it took literally HOURS to re-encode a video a few minutes long using this method - whereas -itsscale took just a few seconds, and didn’t re-encode or change/lose resolution at all.

(29.97/6 = 4.995 - the footage was recording with time warp factor 5X so perhaps we should use 5.0 instead, but it seems smoother to have the fps be a whole number, 6 - and thus 4.995 instead of 5.0.)

I haven’t tried this yet all the way through the process from conversion to processing to Mapillary_Tools upload, but something like it should work.

Discussion of how to change FPS of a video here: Using ffmpeg to change framerate - Stack Overflow

2 Likes

And it turns out the time lapse videos have the exact same problem. However they seem to be encoded as 15 fps instead of 30, which helps.

But the Time Lapse videos I am recording at 2fps are inserted into the video file as 15fps, so the “apparent” speed is 7.5X real speed.

Since I’ve been recording those on bike only, even if you were to hit 30mph the apparent speed is “only” 30X7.5 or 225mph (about 50km/hr X 7.5 = 375 km/hr). Even that isn’t quite enough to break the Mapillary speed limit, if it is 111 m/s which is about 250mph and 400km/hr.

But 35 mph/55kph would do it!

I don’t know if I have ever gone that fast on my bicycle while filming but obvs it would be very easy in an automobile.

1 Like

:smirking_face: So, you run into GoPro’s stupid design of TimeWarp.

Simply put, you have to properly adjust the video stream’s playback rate of TimeWarp videos to flawlessly work with mapillary_tools. But, you seem to already have figured it out by yourself. :clap: Life could have been so much easier if GoPro had done as I have said. :person_shrugging:

1 Like

Sort of off topic, but related–how fast were you going on the highway, and what mount were you using for the Go Pro? I have the heavy duty double donut mag mount with the selfie stick, but I’ve been nervous to go above 60MPH.

@tao - is it possible there is an issue with time lapse videos and the MapillaryCaptureSpeedTooFastError?

The core issue is that MAX’s firmware is buggy in this case. For the Mapillary use case camera users would need to be able to distinctly set capture and playback fps. In other words, the camera should set playback fps equal to capture fps but it does not. There is basically no way to detect a TimeWarp video for any consumer, unless the MAX writes capture mode metadata in the video file (which I doubt) and you can also interpret much of GoPro’s other obscure metadata.

1 Like

:thinking: There is (even with standard metadata only)! But, it is overly complicated. :person_facepalming:
You have to count the number of timecodes per second and compare it to the playback fps. Fortunately, the MAX writes timecode data. :+1: This is indeed one of MAX’s true pros. Hence, if the timecode stream has fewer timecodes (frame timestamps) per second than the video stream playback fps then one can assume the video file to be a TimeWarp video. Is it great? :face_with_diagonal_mouth: Eh, no. Is it worth to put in the additional effort into mapillary_tools? I am not so sure because it is basically a GoPro only thing, which should have been solved better by GoPro in the first place by enabling camera users to choose a playback fps rate. :person_shrugging:

It does, in the GPMF stream, which of course is proprietary but better than nothing. The RATE FourCC key tells you that it is a TimeWarp video at an x factor. :wink: Happy coding @tao. :face_with_diagonal_mouth: Yeah, I wish they would have enabled setting the playback rate in the camera. It would have made so many things easier. Hence, do you really want to support single vendor specific stuff for just one capture mode? :weary_face:

Simplest might be to create a new option that would simply disable the “Mapillary Capture Speed Too Fast Error” check altogether. Users who run into this issue could use that flag and everyone else can just ignore it.

It would be “better” in some theoretical way to have the actual time code and time stamp or whatever (and maybe Mapillary gets this anyway, from the GPS data or whatever) but for practical purposes the “apparent” 450MPH captures work just fine when they are simply uploaded as-is.

If we could just disable that error message and subsequent failure to upload the images that have the error.

We could simply record regular video when driving, but being able to do it at 2X (15 captures per second) or 5X (6 captures/second) or even 10X (3 captures/second) time warp has a significant advantage - the file sizes are so much smaller.

Smaller file sizes are just easier to deal with at every step - more on the SD card, quicker to download from SD to computer, quicker to process, quicker to upload or transfer over the network (in case you need to do that for whatever reason - right now I do, for example).

I haven’t actually done a head-to-head comparison but my impression is that e.g. 5X time warp will have the exact same quality in the end as a full video capture. But, the file is 1/5 the size (or actually, even smaller than 1/5 by some margin).

It is surely always advantageous to deal with smaller file sizes without loss of quality.

An alternative might have been for GoPro to enable users to set capture rates greater than 2 fps in Video Time Lapse Mode and set the playback rate accordingly. But no, lets better do non‑sense. Time Lapse Mode videos also come out set to base playback rate. :disappointed_face::person_facepalming:

MAX is dead. GoPro is pathetic:

This is unfortunate, and I agree with @flug32 @GITNE that the timestamps are simply not correctly set.

@flug32 There is a workaround: To disable the speed check, set the envvar MAPILLARY_TOOLS_MAX_CAPTURE_SPEED_KMH=inf before you run mapillary_tools process

Make sure you are using the latest mapillary_tools v0.14

1 Like