-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Timeshift #5
Comments
Ok, after plenty of research and testing I have landed on the most common timeshifting problem and a partial solution for it. GoPro cameras save video files with local times, while the QuickTime standard defined video time information in UTC. While staying within the GoPro camera itself and the Quik mobile app, that does not represent an issue as both treat it the same way. Unfortunately, all other platforms including GoPro Cloud, Apple Photos, and Google Photos treat the date/time information as UTC resulting in all videos being timeshifted once they leave the GoPro ecosystem.
For this to work we need the DST offset to be applied to the video date/time data of all the videos (not photos as they are correct). That offset could either come from the geonames lookup we perform after import (not perfect as we only do one lookup per day) or from the delta of the QuickTime Create Date and the first GPS Date of the file, since the GPS Date/Time is always in UTC. Alternatively, we could even consider using the first GPS Date/Time as is. Here is an example of how to use
|
Calculating the timeshift difference dynamically based on rounded hours between
|
The integrated version that calculates time shift and assigns it to all QuickTime dates that exist (but no more)
The only thing left: replace rounding logic with one that works for negative offsets as well. |
And this is the final exif logic with the expanded rounding logic that works for positive and negative offsets:
Next up is workflow integration. Will perform this time shift every time we process media for video files. Unfortunately due to the nature of the logic especially due to |
After extensive testing and repeat usage of the logic, it has become obvious that renaming time-shifted video media is not a good idea as repeat runs would hang themselves as exiftool cannot overwrite existing target files. The new implementation keeps the original processed filename and simply shifts all Quicktime tags to UTC while preserving the filesystem modification date&time as well as the filename. |
Need to investigate why the embedded timeshift within the |
Turns out the default time format set via
breaks when combined into
as a double conversion would take place. To fix any prior output of print format needs to be eliminated for this tag by adding a
|
Implement time shift feature to modify the time when a media file has been created.
This could be implemented based on GPS time and timezone see
geonames
feature or by time offset.Need to determine how to best select the media files that should be shifted and how to persist that time shift across multiple
goprox
runs.References
The text was updated successfully, but these errors were encountered: