[caglarpir]

Problem

When a video's GPS is rejected as noise, GPXVideoExtractor still syncs the GPX by the clock of the unfiltered points (#849). GoPro stamps a placeholder date (2015-10-22 and similar) until it acquires GPS time, so a noisy clock more than a day from the GPX was discarded, and the GPX was placed from the start of the video.

The clock was judged against the GPX, though, so a GPX that does not belong to the video was blamed on the clock. A GoPro HERO8 clip with noisy GPS but a real clock, given a GPX recorded on another day, exited 0 with a warning that the clock was 1.3 days away, and that day's track was placed from frame 0. The same GPX on a video with good GPS is rejected with MapillaryOutsideGPXTrackError (#848).

Change

• A noisy clock that starts within a day of the video's mvhd creation time is taken as real. It places the GPX as for any video with GPS, so a GPX that misses the video raises MapillaryOutsideGPXTrackError. A day absorbs a creation time written in local time (GoPro) and whether it marks the start or the end of the recording.
• A clock is still a placeholder only when it is also more than a day from the GPX. Some cameras write a meaningless creation time next to a real GPS clock: a GoPro HERO10 recorded in 2022 reports 2016-01-01. A GPX that agrees with such a clock keeps it, as before.
• If the creation time can't be read, nothing changes.
• The creation time is read by the camm_parser function that decides the CAMM GPS epoch (Decide the CAMM GPS epoch by the creation time, then the make #846).

Verification

On sample videos, with process <video> --geotag_source gpx --geotag_source_path <gpx> and with video_process … --video_sample_distance 3:

Video + GPX	Before	After
GoPro HERO8 (noisy, real clock) + GPX from another day	exit 0, GPX placed from frame 0	MapillaryOutsideGPXTrackError (exit 6 / 7)
same + GPX ten years off	exit 0, GPX placed from frame 0	MapillaryOutsideGPXTrackError (exit 6 / 7)
same + its own GPX	synced by the clock, t = 1.35..12.36 s	unchanged
same + GPX ending before the video	MapillaryOutsideGPXTrackError	unchanged
GoPro MAX (noisy, placeholder clock 2015-10-19, created 2023-11-20) + its GPX	synced from the start	unchanged
GoPro MAX2 timelapse (noisy) + its GPX	synced at the clock rate, GPX at 0.16..1.13 s	unchanged

• With no flags, process and video_process still reject the HERO8 clip with MapillaryGPSNoiseError.
• A GoPro HERO10 clip with noisy GPS, a 2022 clock and a 2016-01-01 creation time, with a GPX built from its own points that starts 60 s early, is still synced by its clock, both as process and as video_process place it.
• A GPX written from a video's own track and synced back gives the same result as main on 17 sample videos from GoPro, BlackVue, Labpano and Insta360 cameras.
• New unit tests:
  • A noisy clock that agrees with the creation time rejects a GPX from another day, both as process and as video_process place it. This test fails on main.
  • A placeholder clock is ignored when the creation time is readable.
  • A real clock with a meaningless creation time is kept.
• Unit tests (917 passed) and integration tests (69 passed), mypy (Python 3.9), ruff check, ruff format --check and usort.