It creates date/time exif back in 2002. If I run ffprobe on the video I see “creation_time” appears twice. The “wrong one” being selected. I vaguely remember this coming up in this forum previously but don’t remember if there was a resolution?
Mmm okay thanks for that. Thought something was mentioned about a workaround or fix. Maybe not? Whatever the case extracting just the index frames (ffmpeg) yields 3FPS from the 30FPS stream of acceptable 2K only quality. I often only do one capture direction down a country road so an additional rear view would be handy. The upshot is that it is worth figuring out a process for, if just to reduce the upload filesize. (200MByte/min vs 100) Easy to parse the metadata to get/rename/timestamp the first frame of each file. So far exiftool also does a dummy spit creating a gpx file with a bad date, but worse case I can use my main GPS unit.
Would then just use the tools to process and upload the resultant EXIF populated jpgs.
The camera has a manual date/time entry which is set to 2025 somewhere, so no idea where the 2002 (RTC?) comes from. I recall it had a timezone choice which I made UTC. The ffprobe times though don’t seem to be either valid UTC or local. Still working on it.
(ffprobe dump as before)
17:13:55.757 - INFO - Extracting video metdata
Extracting videos: 100%|███████████████████████████████████████████| 1/1 [00:00<00:00, 13.06videos/s]
17:13:55.839 - WARNING - No GPS data found from the video
17:13:55.839 - WARNING - Force the option “filetypes” to be “image” to avoid processing and uploading both the video samples and the videos themselves
17:13:55.847 - INFO - ==> Processing 0 files with source exiftool_runtime…
17:13:55.852 - INFO - ==> Processing sequences…
17:13:55.858 - INFO - ==> Validating 0 metadatas…
17:13:55.861 - INFO - Check the description file for details: SAMPLES/mapillary_image_description.json
17:13:55.862 - INFO - ==> Process summary
So I guess that although the GPS data can be extracted with exiftool it still faults on the bad metadata.
Well.. There are 10x 3 minute sequential recordings, so the GPS would seem to be locked in that period! There is also no skewing of the track that might suggest settling. It is faithfully offset 2.94 degrees south and 0.10 degrees west throughout the track. There is no facility to see sigqual. I guess it could be a faulty GPS module, but I more lean towards bad calcs in the firmware. (The latitude error is 10%) I have a viable workaround, so I’ll pursue that.
Perhaps it is optionally worth ignoring the video metadata altogether, just using the first GPS Date/Time, Source Image Width, Source Image Height & Video Frame Rate in the ee3 dump. Not for my sake though!
