Discrepancy in video frame and GPS data

[bphilli7]

Exploring this a bit more and I am not sure what causes the synchronization issues, but here is where my debugging has taken me:

Video clips: 4k timewarp video with auto timescale ("timewarp.mp4") and 1080p 30fps video ("normal.mp4")
Camera: gopro hero 10

Both videos have multiple segments, but for debugging I am only looking at a single segment from each video (not using the joined video).

The timestamps from timewarp.mp4 are "jittery". I used exiftool to extract the GPS timestamps, and then did some processing in excel. I converted the timestamps to a ms count subtracted each element n from n-1 to get a diff(vector).

In the class GPS5EntryConverter point_count is always 1 for the entire timewarp video. For the normal video it is usually 10 (though sometimes 9 and sometimes 11). I believe earlier gopros collect GPS data at 18Hz, but the GPMF github readme appears to note that the GoPro11 is collecting at 10 Hz. I wonder if a firmware update (my gopro 10 is on the most recent firmware) also changed the gopro 10 to a 10Hz collection rate? The timewarp also appears to be trying to collect at 10Hz, but the jitter is very pronounced.

In any case, I have commented out the _short_packet_count error messages from the function.
https://github.com/gopro/gpmf-parser/blob/main/README.md

I would like to investigate how the code is processing these "jittery" gps timestamps in the timewarp video, to see if that is the cause of the video/overlay synchronization issues I have. I believe I read some messages about the interpolation function (to convert 18Hz GPS data to 10Hz overlay frame metadata), and wonder if that is being challenged by 1 point_count GPS data that is also jittery.

For the normal video, if the gopro is sampling GPS data at 10 Hz, it means that little/no interpolation is necessary to create the 10 fps overlay video. Just a thought.

[bphilli7]

interpolation is never called when rendering the timewarp video... so I am doubtful it has to do with interpolation.

This looks like it could be the cause:

If the timelapse correction algorithm assumed a constant framerate instead of the jittery timestamps, it could be miscalculating the overlay data for a given frame of video, perhaps?

Update: non-issue... this factor is the total duration of metadata/timestamps divided by the total length of the video.