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?
Looks to me like mapillary_tools is doing everything just right in this case because it is the smart and correct thing to do to read the video stream creation_time tag, instead of the MOV/MP4 container creation_time tag. MOV/MP4 containers may get modified, which is also when its creation_time tag should usually be updated. Hence, it is naive to rely on the MOV/MP4 container creation_time tag for stream content timestamping. Generally speaking, there is not much mapillary_tools can do about broken video producers or deviating clocks etc. Even if it would examine the container versus the video stream creation_time tags there is no way to tell deterministically which timestamp is correct or to trust one more over the other. In other words, your dashcam’s firmware is buggy (I guess this is the price you pay for cheap). And, imho mapillary_tools cannot and should not work around every buggy video producer. The best thing it could do is print a warning message that the container and stream creation_time tags differ. But again, creation_time tags can and sometimes should differ by design, which renders this notion of a warning message mute.
Anyhow, please check your dashcam’s real time clock because this year 2002 timestamp looks really strange and it must come from somewhere. Please also check whether the sort of correct container creation_time timestamp is in indeed in UTC.
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.
I see your dilemma/need. My recommendation would be to quit fiddling with that cheap dashcam and rather get a used GoPro HERO instead. There are plenty on the market. However, I would not go any older than the GoPro HERO5 Black because this is the first model to feature a built‑in GPS receiver. The GoPro HERO5 Black works just fine for mapping to this very day. I would also stay away from the HERO8 Black because you cannot easily replace the lens on this model. I am mentioning GoPro here for no particular reason other than the fact that they are known to work reliably and frictionless enough for mapping. Of course, you can go with other brands as well that have a built-in GPS receiver and at least a 4K video sensor. Give the used market a chance. It is quite rich by now and you can get good deals.
(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.
The dashcam may need some more time to pick up the GPS signal than other devices. See if you can find a GPS signal quality/strength indicator on the dashcam. The GPS signal is extremely weak and it can also bounce off outdoor structures or the inside of the car body, which can lead to offset GPS positions. Perhaps positioning the dashcam in such a way that it has a greater unobstructed view of the sky may help.
@tao Maybe the exiftool_runtime backend needs just a few additional or other parameters to extract the GPS data in this case?
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!
