Misalignment between video and data when using gpx

[MauroGentile]

Hi, with reference to the screenshots below, I noticed that when feeding the overlay script with gpx data in --use-gpx-only mode, as output there is a misalignment of a few seconds between the frames and the overlayed data.

The image shows a bike that has just started moving from the traffic light. Its actual speed is now slightly above 0. However, the overlay data already shows 17 mph. Take note of the timestamp, which will be useful in a moment. The timestamp is almost, but not yet, 19:45:57. Now look at the GPX data I used to feed the overlay. Look at the velocity when the timestamp is 17:45:57 (so milliseconds after the frozen moment in the image). The speed is 1.76 m/s, or about 4 mph. The motorcycle is exiting the traffic light, so its speed is increasing. This means that at 17:45:59 the speed should be less than 4 mph. But the displayed value is 17 mph, a value reached by the motorcycle 2/3 seconds later.

Do you know what this be casued to?

Thanks for helping

Best

[time4tea]

hiya - thanks for your interest in this software. Yes - this is interesting! - Are you able to share the gpx file with me so that I can take a look at this exact file? If you can, please email to gopro-overlay [at] time4tea.net. Diagnosing issues on real data where people have seen issues is much easier! I'll just use the data to diagnose the issue, then delete. Thanks - James

[MauroGentile]

Hello James, mail sent. Thanks for helping Mauro

[time4tea]

Thanks for sending the file - The first thing that I notice about the file is how many points it has! - It doesn't look like a file generated from a garmin - garmin files usually have 1 gpx point per second. this file has many (30) points per second... how was the gpx file generated? was there a reason to use a gpx file rather than use the gopro file directly as input into gopro-dashboard? if so, it would be useful for me to understand a little more about the workflow... thanks!

[MauroGentile]

Hello James, We would like to feed the software with a GPX file both because we have an external GPS that gathers data at much better precision than GoPro sensors which and also to extend the usage of the software to cases where the videos are recorded through camera other than GoPro.

I tried to sample the GPX file at 1 point per sec but the issue is exactly the same. Thanks for helping

Best

Mauro

[time4tea]

The gpx generation process you used also appears to have some issues - there are lots of points with lat/on 0.0/0.0 - this makes me think that when GPS isn't locked you're using 0/0, and this is why you're zooming to and from https://en.wikipedia.org/wiki/Null_Island :-) - Generating multiple points per second will definitely not work right, as the time format in GPS simply doesn't allow for multiple points per second, it only has second accuracy - e.g. 2022-05-26T17:30:33Z When rendering the file directly from gopro, gopro-dashboard does render the speeds pretty much exactly as you'd expect, and also does "the right thing" when the GPS drops out. That's not to say that the GPX file handling doesn't have an issue, and that's what I'll look at next. However, I would definitely suggest considering what to do with the GPX file generation process on your side, as right now it also has some issues. Cheers!

[MauroGentile]

Yes, sorry I didn't mention it: the lat/on 0.0/0.0 pointsare due to me filling NaNs due to lack of sufficient accuracy. These points are concentrated at the beginning of the first part of teh first chunk of a video, when the GPS is not yet locked on. I have already included in my to-do list the task of handling these cases. The 0/0 is for now just a placeholder. In any case, I should also mention that the out-of-sync problems also appear in the second or third chunks of the video, where there are no 0/0 points. It seems more likely to me that the source of the problem could be in the GPX generation. I have the data in a csv file. I import this script as a pandas dataframe in python and then I convert it to GPX format. It is possible that the problem is in this step. I will look for another conversion tool to see if this is the problem. Do you have a converter to recommend?

[time4tea]

What is the GPS device that you are using? I only really have experience in using cycling devices - like garmin or hammerhead for instance - and these I usually go via strava (as most willl auto-upload to strava) - and so the download files are just either .fit or GPX files - and these can be loaded directly into gopro-dashboard. The import process for both gpx and fit files in gopro-dashboard will assume that all gps points are "locked" - so filtering of points that are not locked should happen before using in this program. GPX does support pdop - but we don't use it at the moment.

[MauroGentile]

Hello James, I made a further test: I removed the NA points and I also sampled the series at 1 frame per second. The results are exactly the same as before. I also tried to use a chunk where there were no missing value. I noticed the same problem. There must be something else.

[time4tea]

Hi - Looking at the gpx file you sent, there are 30 entries with a time of 17:45:57, and a number of different speeds. The first and last are here:

<trkpt lat ="47.33528695997221" lon ="8.519083040052644">
        <ele>481.61</ele>
        <time>2022-05-26T17:45:57Z</time>
        <extensions>
          <gpxtpx:TrackPointExtension>
            <gpxtpx:speed>1.76</gpxtpx:speed>
          </gpxtpx:TrackPointExtension>
        </extensions>
      </trkpt>

      <trkpt lat ="47.33525237582319" lon ="8.519117624201154">
        <ele>481.64</ele>
        <time>2022-05-26T17:45:57Z</time>
        <extensions>
          <gpxtpx:TrackPointExtension>
            <gpxtpx:speed>8.33</gpxtpx:speed>
          </gpxtpx:TrackPointExtension>
        </extensions>
      </trkpt>

When parsing a GPX file, if there are duplicates at exactly the same time, only the last one will be considered.

8.33mps is 18mph.... so when you account for a little bit of smoothing it seems in the right ballpark.

You said you had created a different file with only 1 point per second, can you try that again, and let me know the results - and if you feel there is an error, please send me the gpx file.

Thanks!

[time4tea]

Sorry - just with a bit of math we can show its almost exactly right (with respect to the gpx file)

The time on the clock is 17:45:56.0 (UTC).

There are two relevant points:

2022-05-26T17:45:56Z 1.61 2022-05-26T17:45:57Z 8.33

8.63 - 1.61 = 6.72 (delta v) 6.72 / 10 = 0.672 (delta v per 1/10 second) 0.672 * 9 = 6.048 (delta v for 0.9 seconds) 1.61 + 6.048 = 7.758 ( v at ...56.9 seconds)

7.75mps = 17.1mph.

[time4tea]

Sorry - with my previous comment - I'm not saying that there isn't a problem... its just that I don't really know what the problem is. As far as I can see, the data lines up with what I would expect. If you are still seeing a problem, I'd definitely appreciate it you could explain it again. Sorry for missing your point.

[MauroGentile]

Hello James, sorry for the delay in my response, I've just read your messages. In the next few days, I will take tests, reducing the number of points in the dataset and making sure to have 1 single sample every second. And of course, I will be more than happy to share all the information/files with you so that, working together, we can isolate where the problem is. Thank you James, have a nice week end

[mishuha]

Hello,

I have a similar situation with GoPro 8. I just got used to shifting the 1st segment of continuous recording exactly by 1.2 sec every time. Moreover, subsequent segments of the same recording have GPS clock are already perfectly synchronized with the OSD clock.

It seems to me that this is a problem with the camera itself. That is, for each new press of the record button there is a data lag. How constant it is between different cameras, I do not know. Not a big problem, but yes, this must be taken into account. And therefore I try to record continuously for hours to reduce the number of synchronizations.

My external track is written via a combination of BN-880 and Arduino to a CSV file, then converted with filtering to GPX. I also extract GPS data from video files (if the camera deigned to record this data) in the same way to get the start and end time of the recording. Thus, having time on OSD I have the ability to synchronize the OSD during videoediting to the millisecond.

...\GX010374.MP4.csv
    start:  2024-08-31 21:42:32.025556 - (Have to shift overlay by adding here 1.2 sec to match OSD timestamp)
    end:    2024-08-31 21:48:02.894735 - (Perfectly matches with OSD timestamp)
...\GX020374.MP4.csv
    start:  - (No GPS data at all)
    end:    
...\GX010375.MP4.csv
    start:  2024-08-31 22:32:51.799556 - (Have to shift overlay by adding here 1.2 sec to match OSD timestamp)
    end:    2024-08-31 22:41:57.463992 - (Perfectly matches with OSD timestamp)
...\GX020375.MP4.csv
    start:  2024-08-31 22:41:57.561632 - (Perfectly matches with OSD timestamp)
    end:    2024-08-31 22:51:20.005000 - (Perfectly matches with OSD timestamp)