Repository navigation
Conversation
process ignored --interpolation_offset_time and --interpolation_use_gpx_start_time for videos. They reached the image geotaggers through SourceOption.interpolation, but the GPX video geotagger read them only from VideoSyncOption, which only distance sampling sets. The track uploaded with a video stayed where the GPS clock of the video, or the start of the video, put it, whatever the options said. GPXVideoExtractor now reads them from SourceOption.interpolation, which process sets on every source. Sampling sets it too, unless a source has options of its own, as process does. VideoSyncOption keeps only the start time, and with it the start-time check, which stays out of process: process has no --video_start_time to offer. The offset moves the track along the video. The absolute times of its points stay those of the GPX, just as an image geotagged with the offset takes the time of its position along the GPX. Only sampling shifts them as well, for the geotagging stage to add the offset back. Without the options, process gives the same tracks as before, and video_process the same frames and descriptions, with or without them. Fixes mapillary#827
caglarpir
force-pushed
the
process-video-interpolation-options
branch
from
October 20, 2026 12:18
268fe1f to
add6d99
Compare
This was referenced Oct 20, 2026
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.
Fixes #827
Problem
processignored--interpolation_offset_timeand--interpolation_use_gpx_start_timefor videos. They reach the image geotaggers throughSourceOption.interpolation, but the GPX video geotagger read them only fromVideoSyncOption, which only distance sampling sets (#841). The track uploaded with a video stayed where the GPS clock of the video, or the start of the video, put it, whatever the options said.Fix
GPXVideoExtractorreads both options fromSourceOption.interpolation, whichprocesssets on every source. Sampling sets it too, unless a source has options of its own, asprocess_geotag_properties()does.VideoSyncOptionkeeps only the start time, and with it the check that a GPX can start with the video. That check stays out ofprocess, whose users can't pass the--video_start_timeit asks for.--video_geotag_source.Verification
First point of
MAPGPSTrack(ms) for the GoPro MAX test video, with a GPX that starts 2.59 s before its GPS clock:--interpolation_use_gpx_start_time--interpolation_offset_time 2--interpolation_use_gpx_start_time --interpolation_offset_time 2.5The timestamp of that point is 2019-11-18T23:44:40Z in every case, the time the GPX recorded it.
Without the options,
processgives the same descriptions asmainfor the test data.video_processgives byte-identical frames and descriptions, with and without them.