Skip to content
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

Closed
fxstein opened this issue Aug 19, 2022 · 7 comments
Closed

Feature: Timeshift #5

fxstein opened this issue Aug 19, 2022 · 7 comments
Assignees
Labels
enhancement New feature or request further investigation Needs further investigation

Comments

@fxstein
Copy link
Owner

fxstein commented Aug 19, 2022

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 fxstein added the enhancement New feature or request label Oct 19, 2022
@fxstein
Copy link
Owner Author

fxstein commented Oct 26, 2022

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 fxstein self-assigned this Oct 26, 2022
@fxstein fxstein added the further investigation Needs further investigation label Oct 26, 2022
@fxstein
Copy link
Owner Author

fxstein commented Oct 26, 2022

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
Copy link
Owner Author

fxstein commented Oct 27, 2022

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
Copy link
Owner Author

fxstein commented Oct 28, 2022

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
Copy link
Owner Author

fxstein commented Oct 28, 2022

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
Copy link
Owner Author

fxstein commented Oct 29, 2022

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

@fxstein
Copy link
Owner Author

fxstein commented Oct 29, 2022

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'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request further investigation Needs further investigation
Projects
None yet
Development

No branches or pull requests

1 participant