Exiftool: Set QuickTimeUTC flag for fixing time zone of videos

[zaharcelac]

When I import video files (mp4) from my phone they got assigned wrong time. Photos made at the same moment are treated properly.

Example:

A photo and a video were shot at 14:51 EDT. Imported photo has correct 14:51 EDT timestamp. Imported video got 18:51 EDT.
If I check source video file with mediainfo tool, it shows 18:51 UTC.

It looks like import ignores timezone metadata from video.

[lastzero]

Cab you provide us with example files for testing?

Time zones are not really standardized in metadata. We calculate it based on the GPS data if any.

[zaharcelac]

Here is the full output of video metadata. These discrepancies happen with both my Samsung phones.

# mediainfo 20210623_145059.mp4
General
Complete name                            : 20210623_145059.mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (isom/mp42)
File size                                : 75.9 MiB
Duration                                 : 36 s 890 ms
Overall bit rate                         : 17.3 Mb/s
Encoded date                             : UTC 2021-06-23 18:51:37
Tagged date                              : UTC 2021-06-23 18:51:37
xyz                                      : +00.0000+000.0000/
com.android.version                      : 11

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4
Format settings                          : CABAC / 1 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 1 frame
Format settings, GOP                     : M=1, N=30
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 36 s 890 ms
Source duration                          : 36 s 866 ms
Bit rate                                 : 17.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Rotation                                 : 90°
Frame rate mode                          : Variable
Frame rate                               : 30.000 FPS
Minimum frame rate                       : 29.950 FPS
Maximum frame rate                       : 30.060 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.273
Stream size                              : 74.8 MiB (98%)
Source stream size                       : 74.8 MiB (98%)
Title                                    : VideoHandle
Language                                 : English
Encoded date                             : UTC 2021-06-23 18:51:37
Tagged date                              : UTC 2021-06-23 18:51:37
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.601
Matrix coefficients                      : BT.709
mdhd_Duration                            : 36890
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 36 s 864 ms
Bit rate mode                            : Constant
Bit rate                                 : 256 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 1.13 MiB (1%)
Title                                    : SoundHandle
Language                                 : English
Encoded date                             : UTC 2021-06-23 18:51:37
Tagged date                              : UTC 2021-06-23 18:51:37

[dror3go]

I can confirm the same issue with videos I took with my OnePlus device. I think I noticed this issue also with videos I took with an older Canon camera.
I'd be happy to provide you with a video & photo which I took with the same device on - where should I sent those to?

[graciousgrey]

@dror3go Testfiles can be send to hello@photoprism.app :)

@zahaecelac we will have a closer look next week

[lastzero]

Thanks for providing those samples!

While the file names show about the same create time (15:33 vs 15:40), the CreateDate fields have a few hours difference:

# exiftool -n -j IMG_20210528_153341.jpg | grep Create
  "CreateDate": "2021:05:28 15:33:42",
# exiftool -n -j VID_20210528_154038.mp4 | grep Create
  "CreateDate": "2021:05:28 12:40:43",

When there is no time zone, this typically means it's the local time since there is no convention (which is a shortcoming of the standard). This makes sense as not all photos / videos have GPS data. If it would be UTC by default, you wouldn't know the local time later.

The JPEG additionally contains a GPSDateStamp, which should always be UTC. The file with the "wrong" time is the video however, so this doesn't help.

[lastzero]

I'll go ahead and close this as we've received no more feedback.

[zaharcelac]

Hi! Should we expect a fix for videos where dates contain explicit timezone?

[lastzero]

It's something that should be fixed in your phone or camera as its use of the created date field seems inconsistent, see above. Probably best we can do is release the batch edit feature so that you can manually fix it - or have the money to manually maintain a list of problematic devices to fix their metadata. You may also look into existing Exif tools to update your video metadata and then reindex.

[dror3go]

@lastzero I've checked with iPhone X, Samsung S7, Samsung A5, and OnePlus 7T - all with the same timezone issue. So it's not an obscured bug.

What about using exiftool's QuickTimeUTC flag?

# exiftool -n -j -api QuickTimeUTC VID_20210528_154038.mp4 | grep Create
  "CreateDate": "2021:05:28 15:40:43+03:00",

See here for the documentation.

[lastzero]

Interesting, does this add a timezone automatically? Need to be careful, can't change the behavior with every release or depending on the Exiftool version.

[lastzero]

From what I know, it's an Android specialty and may also depends on the OS version.

[dror3go]

I'm not an exiftool expert, but I've checked also with a video taken with iPhone X iOS 14.6:

# exiftool -n -j IMG_3554.mp4 | grep Create
  "CreateDate": "2021:07:06 16:20:38",
# exiftool -n -j -api QuickTimeUTC IMG_3554.mp4 | grep Create
  "CreateDate": "2021:07:06 19:20:38+03:00",

Same with Samsung A5 Android 8.0.

I came across some old forum threads about this topic:
https://exiftool.org/forum/index.php?topic=3416.msg15390#msg15390
https://exiftool.org/forum/index.php?topic=11100.msg59329#msg59329

[lastzero]

Found this on https://askubuntu.com/questions/989646/exif-tool-and-video-files-which-are-saved-with-utc-timestamps 👇

According to Phil Harvey (exiftool's creator), Quicktime timestamps are supposed to be set to UTC time as per the standard. But it seems a lot of cameras don't do this, so exiftool doesn't assume a timezone and accepts the time as written. See third paragraph under Quicktime tags

Exiftool includes an option to correct for this. If you are running exiftool ver 9.40 or later, you can add -api QuickTimeUTC to the command and it will assume that the timestamps are correctly written as UTC and convert them to local time.

So basically as expected. May then be fixed for you, and broken for others. Need a camera model lookup table to get it right for everyone. Worst we can do is changing the behavior with every release.

[dror3go]

If it's an issue of "fix for some, broken to others" - shouldn't PhotoPrism aim to have it fixed for the majority of users? I'm not saying that my case is the same as for most users, but the quote you pasted states that UTC is the Quicktime standard in this case.

BTW, what about cross checking the timezone using GPS tags when available?

[lastzero]

If you knew how often we changed things back and forth already 😂

Impossible for us to know at development time who the majority is. We'll work something out, but after having the time to think about it and perform testing.

Thank you very much for looking this up in the Exiftool docs / forum! 🤗

[lastzero]

Added the Exiftool flag as requested, and started a new preview build:

https://drone.photoprism.app/photoprism/photoprism/1456

Let us know if this works for you!

[lastzero]

Had to tweak Exiftool parameters to make it work, and started a new preview build for testing:

https://drone.photoprism.app/photoprism/photoprism/1468

The new Docker image should be available within the next hour, unless the build fails and needs to be restarted (check link above).

[lastzero]

As it turns out, the exiftool -api QuickTimeUTC parameter converts CreateDate to local time using the server's time zone - which doesn't help as it will still be treated as local time by PhotoPrism instead of UTC.

[dror3go]

Was just about to try the preview build and test this.

So if I took a video in timezone Europe/Amsterdam and another video in timezone America/New_York and my server's timezone is set to Pacific/Auckland - exiftool -api QuickTimeUTC will treat all videos as if they were taken in timezone Pacific/Auckland as the local time?

[lastzero]

With this fix, MP4 and Quicktime video create dates will be explicitly stored as UTC if their metadata doesn't contain a specific time zone. Other video metadata needs to include an explicit time offset or will be assumed to be in local time. I'm starting a new preview build which should be available within the next one or two hours. Check our build server for this:

https://drone.photoprism.app/photoprism/photoprism

[lastzero]

Development preview and https://demo.photoprism.org/ have been updated. Feedback welcome!

[dror3go]

Hey @lastzero, sorry for the late reply - I struggled setting up a preview image alongside a latest image, I ended up using SQLite for that. Plus, I wanted to gather some relevant an irrelevant videos to test this.

Anyway - this seems to be working great!
I did noticed an issue of a mp4 not being recognized as a video but with a "live" tag (HTML class type-live instead of type-video), and so this fix wasn't applied to it - and so the timezone wasn't detected.
What are "live" files as opposed to "video" files? Is it an issue of file size and/or video length?

[lastzero]

Excellent, thanks for testing! Another user tested for us as well, so we thought this is working and I closed the issue.

Live photos are somewhat special in that there are "official" Apple LivePhotos and short videos we just classify as "live" so that you can hover with the mouse to watch them. The last case shouldn't result in other metadata as it's handled directly in the Exiftool JSON parser before the classification as "live" happens.

Can you provide us with live photos to debug the issue? Either attached to this issue, or send them to hello@photoprism.app if private.

[dror3go]

My bad - the timezone seems to be correct. I guess I was too fast to jump into conclusion.
Thanks again!