[caglarpir]

Problem

A timelapse compresses time: each second of video spans several seconds of GPS time. A GPX is synced to the video at 1x, so on a timelapse it lands at the wrong video times, most of it past the end of the video.

The GoPro MAX2 clip reported in #831 is 1.24 s of 12.5x timelapse covering 15.5 s of GPS time. Since #831 its GPX is accepted, but lands at 0 to 12 s. Its GPS is rejected as noise, so there is not even a clock to read the rate from: the GPX is synced from the start of the video.

Changes

• The GPS clock of the video is read as (video time, Unix time) pairs, anchored at the first pair at its own video time, as in Sync a GPX track to video time 0, not to the first video GPS point #847. Its rate is the least-squares slope of the pairs. It is used when both it and the median step between neighbouring pairs are over 1.5x, so that one timestamp far off cannot make a normal video a timelapse, and is 1x otherwise. A GPS5 block, which stamps ~1 s of points with one timestamp, counts once.
• When the video's GPS is rejected as noise, the clock is read from the unfiltered points. They are never published, and this also keeps the make, model and filetype of the video. A GoPro stamps a placeholder date (2015-10-22 and similar) until it acquires GPS time, so a noisy clock that puts the GPX more than a day away from the video is ignored with a warning, and the GPX is synced from the start of the video, as on main.

Verification

• The reported clip: its GPX lands at 0.16 to 1.13 s, where its GPS clock places it (0.16 to 1.12 s), with make and model GoPro / MAX2.

• The tracks of 17 sample videos (GoPro MAX, MAX2, HERO7, HERO8, BlackVue, Labpano, Insta360) exported as GPX and synced back to their videos. Median error:

  Video	main	this PR
  GoPro MAX timelapse, 1 fps	74.5 s	0.10 s
  GoPro MAX timelapse, 2 fps	89.5 s	0.20 s
  GoPro MAX timelapse	612.4 s	0.002 s
  GoPro MAX timelapse	59.8 s	0.14 s
  GoPro MAX2 timelapse, 10x	35.5 s	0.02 s
  GoPro MAX2, 2x	20.3 s	0.007 s
  GoPro MAX2, 2x	6.7 s	0.16 s
  the 10 others	unchanged	unchanged

• Across 519 sample files with a GPS clock (GoPro, BlackVue, CAMM cameras), only those seven are detected as timelapses (two of them stored twice).

• Across 168 runs over sample files from over 20 cameras, this PR changes no output. The one timelapse with a GPX among them, from an Insta360 ONE X, has no GPS clock to read a rate from.

• Unit: 750 passed, 18 skipped, 1 xfailed. Integration: 57 passed. Doctests pass. mypy, ruff check and ruff format --check are clean.

Interactions with other open PRs

Whichever lands second needs these by hand:

• Reject GPX tracks that miss the video, as placed on its timeline #848 checks the GPX against the video at 1x, so it rejects the reported timelapse ("misses the video by 0.76 seconds"). The video's start and end must come from the clock, clock.to_unix_time(0) and clock.to_unix_time(...) of its end. test_good_clock_days_away_is_still_used then expects MapillaryOutsideGPXTrackError.
• Honour --geotag_source in distance-based sampling #841: where no GPS clock is used, call _place_without_video_gps() instead of _rebase_times(), or --video_start_time is ignored there.
• Decide the CAMM GPS epoch by the creation time, then the make #846 edits _gpx_offset(), which this PR replaces. _read_video_clock() already anchors on the first point with a timestamp.