fxstein / GoProX

The missing GoPro data and workflow manager for macOS
MIT License
23 stars 3 forks source link

Feature: Timeshift #5

Closed fxstein closed 1 year ago

fxstein commented 1 year ago

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

fxstein commented 1 year ago

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.

exiftool provides a simple solution to timeshifting files and it should be able to incorporate that timeshift into the --process option without the need for an additional pass over the data.

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 exiftool to perform the timeshift:

exiftool -AllDates+=7 -quicktime:time:all+=7 -verbose -o P_20221004110648_GoPro_Hero10_2442_GX010328.mp4

As per this example, it will probably be a good idea to expand the file prefix from P_ for processed to PT_ for processed and timeshifted. Keeping the filename as is to preserve the local time the file was recorded in. This allows us to still find the originating imported file without additional logic at the library level.

fxstein commented 1 year ago

Calculating the timeshift difference dynamically based on rounded hours between CreateDate and GPSDateTime:

exiftool -ee -d '%s' -p '${GPSDateTime;$_=int(($_-$self->GetValue("CreateDate"))/3600+0.5)}' P_20221004110648_GoPro_Hero10_2442_GX010328.mp4
fxstein commented 1 year ago

The integrated version that calculates time shift and assigns it to all QuickTime dates that exist (but no more)

exiftool -wm w -ee -d '%s' '-quicktime:time:all<${GPSDateTime;$_=$self->GetValue("CreateDate")+int(($_-$self->GetValue("CreateDate"))/3600+0.5)*3600}' -o PT_20221004110648_GoPro_Hero10_2442_GX010328.mp4 P_20221004110648_GoPro_Hero10_2442_GX010328.mp4 -api TimeZone=GMT

The only thing left: replace rounding logic with one that works for negative offsets as well.

fxstein commented 1 year ago

And this is the final exif logic with the expanded rounding logic that works for positive and negative offsets:

exiftool -wm w -ee -d '%s' '-quicktime:time:all<${GPSDateTime;$_=$self->GetValue("CreateDate")+int((($_-$self->GetValue("CreateDate"))/3600)+(($_-$self->GetValue("CreateDate"))/3600)/abs((($_-$self->GetValue("CreateDate"))/3600)*2 || 1))*3600}' -o PT_20221004110648_GoPro_Hero10_2442_GX010328.mp4 P_20221004110648_GoPro_Hero10_2442_GX010328.mp4 -api TimeZone=GMT

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 -wm w this cannot be combined with the current processing pass, but has to be executed as an additional pass over the data.

fxstein commented 1 year ago

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.

fxstein commented 1 year ago

Need to investigate why the embedded timeshift within the process flow does not find matching files in some cases.

fxstein commented 1 year ago

Turns out the default time format set via -d '%d' leads to a broken TimeFmt logic in the -if4 clause of the exiftool statement.

-if4 '${FileModifyDate;DateFmt("%s")} gt 1666957443'

breaks when combined into

-d '%s' -if4 '${FileModifyDate;DateFmt("%s")} gt 1666957443'

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 #

-d '%s' -if4 '${FileModifyDate#;DateFmt("%s")} gt 1666957443'