Repository navigation
Say in the too-far-apart error that a GPS timestamp is probably wrong - #931
Merged
caglarpir merged 2 commits intoOct 26, 2026
Merged
Conversation
The ExifTool video reader times every point by its GPS timestamp, relative to the first point. A receiver at cold start, or a wrong date, can write a first timestamp far from the others: a dashcam video whose first GPS timestamp was 22 hours older than the next one had every other point 22 hours into the video. Where that overflows the sample duration of the uploaded video, mapillary#929 fails the whole video for one wrong point; below that limit (19.9 hours at a timescale of 60000, 49.7 days at a timescale of 1000), the video was processed and uploaded with its track that far past its end. Before making the times relative to the first point, split the track where two consecutive GPS timestamps are more than MAPILLARY_TOOLS_MAX_GPX_GAP_SECONDS (1 hour) apart, keep the segment with the most points (the earliest of them on a tie), and make the times relative to its first point. The extractor warns once of the points left out. Only the tracks timed by their GPS timestamps are split, the QuickTime, Insta360 and LIGO records; the GoPro tracks that ExifTool reads are timed by their samples and do not change.
mapillary#928 and mapillary#929 fail a video with "Points at 0.000 s and 79739.000 s of the video are 79739.000 s apart, more than the 71582.788 s that can be stored between two points in the uploaded video": accurate, but it gives the user nothing to act on. Say instead what is wrong, in hours: "The GPS timestamps of the video jump by 22.1 hours between 0.000 s and 79739.000 s, more than the uploaded video can store (19.9 hours); a GPS timestamp of the video is probably wrong". process and the upload give the same message, the upload after the name of the video as before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #930; review the last commit.
#928 and #929 fail a video with "Points at 0.000 s and 79739.000 s of the video are 79739.000 s apart, more than the 71582.788 s that can be stored between two points in the uploaded video": accurate, but it gives the user nothing to act on.
Say instead what is wrong, in hours: "The GPS timestamps of the video jump by 22.1 hours between 0.000 s and 79739.000 s, more than the uploaded video can store (19.9 hours); a GPS timestamp of the video is probably wrong".
processand the upload give the same message, the upload after the name of the video as before. Nothing else changes.Unit and integration tests, doctests,
mypy --python-version 3.9,ruff check,ruff format --checkandusort diffare clean.