Repository navigation
Read videos by the --video_geotag_source names the README documents - #891
Merged
Merged
Conversation
Since mapillary#888, GPX sync places a track, and sampling stamps frames, through every GPS timestamp of the video. The cameras whose timestamps leave a straight line record in real time, so video time maps to GPS time along a straight line, and their timestamps jitter about it. A GoPro stamps each block of 1.001 seconds of video up to 1.7 seconds off the line through the rest: on a GoPro MAX, the accelerometer timestamps of those blocks advance 0.996 to 1.006 seconds each, while their GPS timestamps advance 0 to 3.8 seconds. A PANOX V2 stamps some fixes up to 6 seconds late. mapillary#888 followed that jitter. It placed a GPX up to 1.4 s off the line on a GoPro HERO7, 1.6 to 2.9 s on GoPro MAX videos with poor GPS, and 5.9 s on a PANOX V2. It stamped interval samples 5 s apart from 3.7 to 6.3 s apart (HERO7), and 10 s apart from 7.2 to 12.8 s apart (PANOX V2). Its message put the move of a GPX on a GoPro MAX at up to 56 ms, and that of GoPro interval stamps at up to 1.5 s; on these videos, both moved by up to 2.9 s. The LabPano Pilot One and Era, which mapillary#888 was written for, need no more than a straight clock. Their timestamps fit one at 1.143 GPS seconds per second of video, within 0.3 s over 14 minutes (0.7 s on the Era). The clock was read at 1x only because any rate below the timelapse rate of 1.5 was rounded to 1. Read the clock as the least-squares line through the timestamps, at the rate it fits, anchored at their median as before, and use it everywhere: GPX sync places the track by it, interval samples and distance samples of the video's own track are stamped by it, and the geotagging stage times the video's track at its rate. The fit leaves out the timestamps that mapillary#888 showed to be wrong: those out of order, those before a jump of more than a day, and stale first ones. The rate is 1x when it is within 5% of 1x, or when it departs from 1x by less than 2 seconds over the timestamps. On sample videos, cameras that record in real time measure within 0.4% of 1x over 20 seconds or more, or 1.6% for a GoPro MAX whose GPS glitches. Clips of a few seconds measure up to 14% off 1x, a drift of at most 0.3 s. The LabPanos measure 1.093 to 1.143, a drift of at least 15 s. A rate above 1.5 must still show in the median step between timestamps, so one timestamp far off makes no timelapse. Timelapses get a straight clock too. Once their stale first timestamps are left out, those of GoPro MAX, MAX 2 and Rove timelapses lie within 0.33 GPS seconds of the line, but for one GoPro MAX timelapse within 0.82 (55 ms of video), less than the jitter of a normal video. On sample videos from 9 cameras: - Without a GPX, process writes the same tracks for all of them. - A GPX made from a video's own track moves onto the straight line: by up to 1.4 s on the HERO7, 2.9 s and 1.6 s on GoPro MAX videos with poor GPS, 0.65 s on a GoPro MAX 2, 5.9 s on a PANOX V2, and up to 0.06 s on other GoPros. Interval samples are stamped evenly, 5.000 s or 10.000 s apart, and those of a LabPano 11.426 s apart for 10 s of video. Distance samples of the video's own track are stamped by the clock, and their positions do not change. - A GPX made from a LabPano's own track lands within 0.26 s of its timestamps over 14 minutes, and within 0.61 s on the Era. GPX distance samples of the 2 fps Era are no longer dropped: mapillary#888 timed its frames alternately fast and slow, so half of them fell under the sample distance. One LabPano video is the exception: its GPS drops out for 6 seconds of video, its positions jump 64 m, and its GPS time advances 2 s over 8 seconds of video. A GPX of its own track is placed up to 3.8 s off its timestamps, and interval samples geotagged from it up to 65 m off its own positions. - GoPro MAX timelapses keep mapillary#852's results: their placements move by up to 0.05 s, and all their distance samples are described. - A GPX that ends exactly at a video's own first or last timestamp, as one made from its track does, can now miss a sample at the very start or end of the video, which is stamped just past it and reported as outside the track: 1 to 4 samples on 4 of these videos. A logger track that covers the video does not. - BlackVue, Viofo and Ricoh outputs do not change, but for 1 ms rounding of BlackVue GPX track times.
Two ways a file given to process could be left out of the results, as if it had not been there, with exit 0: mapillary#875 left a video out when --filetypes named types of video (gopro, blackvue, camm) and none of the geotag sources given could read videos: the type of a video is known only once it is read, so it might not be of any of them. That brought back the silent drop that mapillary#868 fixed. On a GoPro video, `process VIDEO --filetypes gopro --geotag_source exif` exited 0 with an empty description. A file could also be given to no source at all, when the filetypes of every source leave it out. `--geotag_source '{"source": "native", "filetypes": ["image"]}'` gave the videos of a folder to no source, and a source limited to GoPro videos its images. --filetypes limits the filetypes of every source further: `--filetypes gopro --video_geotag_source '{"source": "native", "filetypes": ["blackvue"]}'` gave a GoPro video to no source. Fail such a file, as mapillary#868 fails a video that no source can read: "No geotag source is given for this video: the geotag source native is limited to other file types", or "--filetypes gopro leaves no geotag source for this video: the geotag sources native, exiftool_runtime are limited to other file types". A file of a type that --filetypes leaves out is still left out. For a video, which --filetypes names by the type of its GPS, that is told as the native reader does while geotagging: given the types asked for, it recognizes one of them in the video, or none. A video of none of them is left out, as mapillary#875 leaves out the videos that a source found to be of other types, and any other is failed. No video is read for it without --filetypes or with --filetypes video. Checked process on a folder of a GoPro, a CAMM, a BlackVue and an unrecognized video and an image, and on the GoPro video alone: with no --filetypes, and with gopro, camm, blackvue, video, image, image,gopro, gopro,camm,blackvue and camm,video; each with the default sources, exif, native, gpx, --video_geotag_source native, exif and --video_geotag_source native, --video_geotag_source gpx, and exif and a native source limited to camm (144 runs). Only the 13 runs in which exif was the only source given videos change: the videos of the types asked for are failed, and the others are still left out. Nor do the flows whose sources are limited by design change: process with the default sources, with exif, with --video_geotag_source native, gpx or exiftool_runtime alone, with exiftool_runtime, exiftool_xml, gpx or NMEA, with the image-only gopro, camm and blackvue sources on sampled frames, alone or beside their videos, and video_process with the default sources, exif, --video_geotag_source native, gpx, exiftool_xml and the gopro source. video_process with only a gpx source limited to videos, whose frames no source geotagged, now fails them rather than exit 0 with an empty description.
The README documents video, camm, gopro and blackvue as values of --video_geotag_source, and its first video example is `process --video_geotag_source video VIDEO_DIR/`. From v0.11 to v0.13 they read the video's own GPS: video in any format, the others in one format each. Since v0.14, video is not a source name, and the others are the legacy sources that geotag images from videos, which cannot read a video. In v0.14.7 the example failed with a ValueError traceback, and the others left the videos out of the description without a word; now video is rejected as an unknown source (exit 2), and the others fail every video (exit 6). As a --video_geotag_source, video is now the native source, and camm, gopro and blackvue (and the gopro_videos and blackvue_videos aliases) the native source limited to the videos of their type, as before v0.14. A video of another type is reported as having no GPS, as v0.13 reported it. video_process samples by them too, where it fell back to the video's own GPS of any type without a word. --geotag_source keeps these names as they are: video is not one of them, and the others geotag images from videos. An unknown --video_geotag_source lists video among the aliases. On a GoPro, a CAMM and a BlackVue video, video gives the descriptions of native, and each of camm, gopro and blackvue gives them for the videos of its type. The README lists native, which it did not, with video as its other name.
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 #890; review the last commit.
The README documents video, camm, gopro and blackvue as values of
--video_geotag_source, and its first video example is
process --video_geotag_source video VIDEO_DIR/. From v0.11 to v0.13they read the video's own GPS: video in any format, the others in one
format each. Since v0.14, video is not a source name, and the others are
the legacy sources that geotag images from videos, which cannot read a
video. In v0.14.7 the example failed with a ValueError traceback, and
the others left the videos out of the description without a word; now
video is rejected as an unknown source (exit 2), and the others fail
every video (exit 6).
As a --video_geotag_source, video is now the native source, and camm,
gopro and blackvue (and the gopro_videos and blackvue_videos aliases)
the native source limited to the videos of their type, as before v0.14.
A video of another type is reported as having no GPS, as v0.13 reported
it. video_process samples by them too, where it fell back to the video's
own GPS of any type without a word. --geotag_source keeps these names as
they are: video is not one of them, and the others geotag images from
videos. An unknown --video_geotag_source lists video among the aliases.
On a GoPro, a CAMM and a BlackVue video, video gives the descriptions of
native, and each of camm, gopro and blackvue gives them for the videos
of its type. The README lists native, which it did not, with video as
its other name.
Unit and integration tests, doctests,
mypy --python-version 3.9,ruff check,ruff format --checkandusort diffare clean.