[caglarpir]

Fixes #827

Problem

process ignored --interpolation_offset_time and --interpolation_use_gpx_start_time for videos. They reach the image geotaggers through SourceOption.interpolation, but the GPX video geotagger read them only from VideoSyncOption, 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

• GPXVideoExtractor reads both options from SourceOption.interpolation, which process sets on every source. Sampling sets it too, unless a source has options of its own, as process_geotag_properties() does. VideoSyncOption keeps the start time and --video_duration_ratio, and with them the check that a GPX can start with the video. That check stays out of process, whose users can't pass the --video_start_time it asks for. Interval sampling checks a GPX that --interpolation_use_gpx_start_time starts with a video without a GPS clock (Sync a GPX to a video without a GPS clock at --video_duration_ratio #856) by each GPX source's own options.
• The offset moves the track along the video. The timestamps 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.
• The README no longer says that offsets can't be applied with --video_geotag_source, and warns that in a directory mixing images and videos, an offset meant for the images now moves the videos too.
• The coverage check from Reject GPX tracks that miss the video, as placed on its timeline #848 judges the track where the options place it. An offset that moves the track off the video fails it, however the track was placed: by the GPS clock of the video, by --video_start_time, or at the start of the video (assumed, or with --interpolation_use_gpx_start_time), where only the offset can have moved it off. With an offset, the error names it and gives the times it looks the video up at along the track, so that they agree with the gap it reports.

Verification

The GoPro MAX test video with a GPX that starts 3.613 s before its GPS clock. Video time (ms) in MAPGPSTrack of the point the GPX recorded at 23:44:50, 10 s into the track (the track is clipped to the video since #860, so its first point is always at 0):

options	before	after
none	6387	6387
--interpolation_use_gpx_start_time	6387	10000
--interpolation_offset_time 2	6387	4387
--interpolation_use_gpx_start_time --interpolation_offset_time 2.5	6387	7500

That point keeps the time the GPX recorded it in every case.

• On a 30x GoPro MAX timelapse with its own GPX, --interpolation_offset_time 2 moves the track by 67 ms of video: the offset is in GPS seconds, of which the video's GPS clock packs 30 into each second (Sync a GPX to the GPS clock of a timelapse, even one too noisy to publish #849). With --interpolation_use_gpx_start_time, the track starts with the video at that rate, and is clipped to the video (Keep a timelapse's clock rate when the GPX starts with the video #853, Clip a GPX track to the video it geotags when a clock paces it #860).
• Without the options, process and video_process give the same descriptions as main on sample videos from 10 cameras.
• Unit: 971 passed, 18 skipped, 1 xfailed. Integration: 73 passed. Doctests, mypy, ruff check, ruff format --check and usort diff are clean.

Merge notes

Rebased onto main after #852-#862. Besides the conflicts, the tests changed: #855's clock anchor moves the GPS clock of the test video by about 1 s (-2.59 s becomes -3.613 s), and the integration test looks a point up by its GPX time rather than reading the first point, which #860 clips to the start of the video.

#861 warns in process of a long track assumed to start with a video without a GPS clock. It warns with an offset too; naming the offset there is left for a follow-up.

Release notes

process now applies --interpolation_offset_time and --interpolation_use_gpx_start_time to videos geotagged from a GPX, as it does to images. In a directory that mixes images and videos, an offset meant to correct the camera clock of the images now also moves the track of each video, and a video that the moved track misses fails with MapillaryOutsideGPXTrackError. Process the images on their own with --file_types image to leave the videos as before.