Repository navigation
Conversation
…file A GPX track that misses a file lets the later geotag sources take their turn. When none of them geotagged the file, the error reported was that of the last one to fail, which hid the miss. A video whose own GPS is too noisy, given a GPX of another day, failed as "GPS is too noisy": the very problem the GPX was given to work around. The Desktop Uploader, whose chain runs two GPX sources, exiftool_xml, native and exiftool_runtime, shows only that error. Report the miss instead: "The GPX track in X (...) misses the video Y (...) by 105.1 days. Check that the GPX file belongs to this video, ...". An error that ends the chain, such as "Stationary video", is still reported, as it says something about the file itself, and a file that a later source geotags still only gets the warning it gets now.
A video's GPS clock places a GPX track along it, and tells whether the track is of the same recording. Two things kept it from doing so: - A GoPro stamps a placeholder date until its GPS has the time, and a GPS rejected as noise may never get past it. Such a clock was told apart by the creation time of the video, which comes from the camera's own clock and can be anything. A noisy GPS whose clock disagreed with the creation time got any GPX synced from the start of the video, even one recorded months before (mapillary#858). - Only a leap of more than a day was taken for the GPS acquiring the time. Judge the timestamps alone. Leave out those before 2016 (the placeholder dates are 2000-01-01 and dates in October 2015) or more than a day in the future, and keep only those after the last leap of more than a minute ahead of the video. What is left is the GPS time, whether or not the positions were too noisy to publish, so it places the GPX, and a GPX of another time misses the video. The creation time is no longer read for that. When the clock has no timestamps, sampling looked for a start time in the GPS timestamps by rules of its own, which leave out only those before 2010. Now that the clock leaves out placeholder dates, that would bring them back, so it reads the same clock.
…rning A video without GPS timestamps of its own has nothing better than its creation time to say when it was recorded. That comes from the camera's clock, which can be off, and marks the start or the end of the recording depending on the camera. Without --video_start_time, a GPX track was placed along such a video: - in process, as if it started with the video, with a warning when it ran on for longer than the video; - in distance sampling the same way, but refused, asking for --video_start_time, when it ran on for more than twice the length of the video. Interval sampling with --video_geotag_source refused it alike, leaving every sample without a location; - in interval sampling with --geotag_source, by the creation time, whether or not the track covered the video there, and not at all without one: "Unable to extract video start time". Now all of them place the track by the creation time if the track covers some of the video there, with a warning that the camera's clock can be off and how to correct it. Where nothing tells whether the creation time marks the start or the end of the recording, the one that the track covers is taken. Otherwise the track is assumed to start with the video, with a warning that the creation time puts the video elsewhere. A track is no longer refused for want of a start time: it is taken to be right. Only --interpolation_use_gpx_start_time still refuses a track too long to end with the video. In process, a track placed by the creation time is clipped to the video, as one placed by a GPS clock is. The reading of the creation time moves from sample_video to geotag/video_start_time.py, so that GPX sync can use it. It reads the mvhd box, so process does not need ffprobe for it.
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 #939; review the last commit.
A video without GPS timestamps of its own has nothing better than its creation time to say when it was recorded. That comes from the camera's clock, which can be off, and marks the start or the end of the recording depending on the camera. Without
--video_start_time, a GPX track was placed along such a video:process, as if it started with the video, with a warning when it ran on for longer than the video;--video_start_time, when it ran on for more than twice the length of the video. Interval sampling with--video_geotag_source gpxrefused it alike, leaving every sample without a location;--geotag_source gpx, by the creation time, whether or not the track covered the video there, and not at all without one: "Unable to extract video start time".Now all of them place the track by the creation time if the track covers some of the video there, with a warning that the camera's clock can be off and how to correct it. Where nothing tells whether the creation time marks the start or the end of the recording, the one that the track covers is taken. Otherwise the track is assumed to start with the video, with a warning that the creation time puts the video elsewhere. A track is no longer refused for want of a start time: it is taken to be right. Only
--interpolation_use_gpx_start_timestill refuses a track too long to end with the video. Inprocess, a track placed by the creation time is clipped to the video, as one placed by a GPS clock is.--video_start_timeprocess, GPX covers the creation timeprocess, GPX misses the creation timevideo_process, distance, GPX more than twice the videoMapillaryGPXVideoStartUnknownErrorprocess, with a warningvideo_process, interval,--geotag_source gpxprocessvideo_process, interval,--video_geotag_source gpx, GPX more than twice the videoprocess, with a warningprocess--geotag_source gpx--video_start_timeor--interpolation_use_gpx_start_timegivenThe warnings:
The GPX track in track.gpx is placed along the video clip.mp4 by the creation time of the video, read as the start of the recording, which puts its start at 2025-03-14T07:00:30+00:00. That comes from the camera's clock, which can be off: if the frames are not where they were taken, sample the video with video_process and --video_start_time, or trim the GPX to the videoThe GPX track in track.gpx (2025-03-17T07:00:00+00:00 to 2025-03-17T07:01:00+00:00) misses the video clip.mp4 placed by its creation time, which puts its start at 2025-03-14T07:00:30+00:00 by the camera's clock, so the track is assumed to start with the video. If it does not, specify the time the video started as --video_start_timeThe reading of the creation time moves from
sample_videotogeotag/video_start_time.py, so that GPX sync can use it. It reads themvhdbox, soprocessdoes not need ffprobe for it.Tests: unit tests for each placement in
process, distance and interval sampling, and for a creation time that marks the end of the recording; the refusal tests now expect the warnings. One integration test, which expected distance sampling to refuse a long GPX, now checks, for distance and interval sampling, that the frames are placed by the creation time, or from the start of the GPX when the GPX misses the creation time or there is none. Unit and integration tests pass, with and without ExifTool. Also checked by hand throughprocesswith the Desktop Uploader's arguments and throughvideo_process, on a video without GPS with GPX files of the recording, of another day and of several days.