Add interpolation to overlay_speed.py example

[Seangottarun]

I modified the previous GPX data and uploaded it as a new GPX file was added so that the total time duration of the GPX data matched the duration of the input video.

Interpolation was achieved using scipy.interp1d. There's a few options for types of interpolation (ex. linear, cubic). I haven't really figured out what type of interpolation is commonly used, but I ended up choosing cubic interpolation because it's smoother and it takes very little extra time to run.

I will measure the actual total run time tomorrow, but it should be more or less comparable to the previous run times without interpolation. The "30 times" extra run time in #4 (comment) is wrong because I forgot that the GPX data I had before was significantly longer than the actual input video. I think I purposefully used a GPX file that was 30x longer to simulate the actual run time when I later got interpolation working.

Anyways, the long story short is that interpolation should work now and it shouldn't take a significantly longer time to run.

TODO

• Use scipy.interp1d for interpolating velocity data
• Compare performance with and without interpolation
  • On my 7 year old quad-core desktop cpu, the whole overlay_speed.py file runs in about the same time with interpolation
  • Previous code (with parallelization but no interpolation): 213 seconds
  • New code (with parallelization and interpolation): 155 seconds
• Test with a different GPX and video file

[Seangottarun]

I just ran the new code with interpolation and it does run in about the same speed as before. It ends up being a bit shorter because the GPX file from before was over 30x longer than the length of the video (i.e. the time range covered by the GPX file is much longer than the time range covered by the video).

If you use your own video and GPX file, then you will notice the 30x longer processing time with this new code compared to the older overlay_speed.py.

[Seangottarun]

I also tested the interpolation code with another GPX file and input video and it works okay. There's a few other changes that I will make later, but this should be good enough for now if you want a basic overlay of speed data. For best results, you should ensure that the GPX and input video are roughly the same length.

This is what I had in mind for future pull requests:

1. Change trkseg = root[1][2] to finding XML tags by name instead of by position as mentioned in Add creation of updated_speed.html and temp folder if missing #1 (comment)
2. Fix elevation example
3. Make it easier for users to specify their own HTML templates
4. Allow for generic GPS data overlays (both text-based and graphical-based)
5. Deal with GPS data and video of different length
   • If GPS data and video are recorded separately, the length of the 2 files may not match
   • We should give options on how to merge them together (ex. only choosing the overlap areas)
   • Note: in normal usage, the GPS and camera are may not be in "time-sync" (may be off by a few seconds to a few minutes)
6. Give intermediate progress and expected time left when generating overlay frames
7. Add testing and documentation

[exadeci]

Tested it, it took about 50mins to get the images generated and about 20 for the ffmpeg part (the audio is missing though) on a 12mins video

Thank you for the great progress !

[Seangottarun]

Hi @exadeci, thanks again for helping me with the review! I wouldn't have gotten this far if you didn't make that first pull request 😅.

I checked my previous output videos and noticed the missing audio as well. So I've opened a new issue and will try to fix it sometime in the following week.

It would be nice if the processing could be sped up, but for now I think I'll work on making a progress bar or something in the terminal to notify the user of the estimated time remaining.