Wrong takestamp on some videos

[ikosa]

i cant get the correct takestamps on videos other than quicktime. I have tried to change timezone at app.php and also at mysql and restart after that but nothing changes, i guess i'm missing a point. Also i have tried to run "php artisan config:cache" after timezone change.

As i detect quicktime videos have correct time zones but the others are on zulu timezone i'm on +3 so it has to be 12:49.19 in this example: `object(PHPExif\Exif)#1884 (2) { ["data":protected]=> array(10) { ["width"]=> int(1920) ["height"]=> int(1080) ["framerate"]=> float(29.982983550766) ["duration"]=> string(9) "29.383333" ["creationdate"]=> object(DateTime)#1885 (3) { ["date"]=> string(26) "2017-08-20 16:34:45.000000" ["timezone_type"]=> int(1) ["timezone"]=> string(6) "+03:00" } ["make"]=> string(5) "Apple" ["camera"]=> string(8) "iPhone 6" ["FileName"]=> string(12) "IMG_7763.MOV" ["FileSize"]=> string(8) "56472993" ["MimeType"]=> string(15) "video/quicktime"

object(PHPExif\Exif)#1883 (2) { ["data":protected]=> array(11) { ["width"]=> int(1920) ["height"]=> int(1080) ["framerate"]=> float(29.879816737124) ["duration"]=> string(8) "4.117000" ["creationdate"]=> object(DateTime)#1882 (3) { ["date"]=> string(26) "2016-07-24 09:49:19.000000" ["timezone_type"]=> int(2) ["timezone"]=> string(1) "Z" } ["latitude"]=> string(8) "+39.9837" ["longitude"]=> string(9) "+032.8752" ["gps"]=> string(18) "+39.9837,+032.8752" ["FileName"]=> string(23) "VID_20160724_124914.mp4" ["FileSize"]=> string(8) "10722475" ["MimeType"]=> string(9) "video/mp4" } `

[tmp-hallenser]

Could you share a sample? That would be helpful.

Am 25.07.2020 um 01:36 schrieb ikosa notifications@github.com:

 i cant get the correct takestamps on videos other than quicktime. I have tried to change timezone at app.php and also at mysql and restart after that but nothing changes, i guess i'm missing a point. Also i have tried to run "php artisan config:cache" after timezone change.

As i detect quicktime videos have correct time zones but the others are on zulu timezone i'm on +3 so it has to be 12:46.19 in this example: `object(PHPExif\Exif)#1884 (2) { ["data":protected]=> array(10) { ["width"]=> int(1920) ["height"]=> int(1080) ["framerate"]=> float(29.982983550766) ["duration"]=> string(9) "29.383333" ["creationdate"]=> object(DateTime)#1885 (3) { ["date"]=> string(26) "2017-08-20 16:34:45.000000" ["timezone_type"]=> int(1) ["timezone"]=> string(6) "+03:00" } ["make"]=> string(5) "Apple" ["camera"]=> string(8) "iPhone 6" ["FileName"]=> string(12) "IMG_7763.MOV" ["FileSize"]=> string(8) "56472993" ["MimeType"]=> string(15) "video/quicktime"

object(PHPExif\Exif)#1883 (2) { ["data":protected]=> array(11) { ["width"]=> int(1920) ["height"]=> int(1080) ["framerate"]=> float(29.879816737124) ["duration"]=> string(8) "4.117000" ["creationdate"]=> object(DateTime)#1882 (3) { ["date"]=> string(26) "2016-07-24 09:49:19.000000" ["timezone_type"]=> int(2) ["timezone"]=> string(1) "Z" } ["latitude"]=> string(8) "+39.9837" ["longitude"]=> string(9) "+032.8752" ["gps"]=> string(18) "+39.9837,+032.8752" ["FileName"]=> string(23) "VID_20160724_124914.mp4" ["FileSize"]=> string(8) "10722475" ["MimeType"]=> string(9) "video/mp4" } `

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kamil4]

FYI, I was aware of this problem when I first implemented the extraction of the metadata from video files. However, I didn't know how to distinguish between files that use the local time vs UTC for takestamp, so I ignored the problem, figuring that a takestamp offset by a few hours is better than no takestamp at all (which is how it was in Lychee until that point).

The data provided by @ikosa, however, indicates that at least for Apple-generated files the time zone is embedded? That's news to me. I'll need to check with the files from my Android phone and the digital camera(s).

[ikosa]

This is also from my android phone. https://drive.google.com/file/d/1UJ8-fKndA2pUoPlMRnbepGQ-RqPtFsMH/view?usp=drivesdk @kamil4 fyi my quicktime movies from Canon 500D has also embeded time zone and there is also a comment about this on ffprobe mapper

[kamil4]

@ikosa How does your Canon 500D embed the time zone? Could you provide a sample from it or at least a relevant output from ffprobe?

I just checked on my Olympus E-M5.3 and unfortunately it appears to store local time while claiming that it's Zulu ("Z" at the end of creation_time). But that's a bug in the camera as far as I can tell and there's nothing we can do about that...

I have a patch for PHPExif to convert Zulu timestamps to local time of the server. That's not necessarily correct either (the server could be in a different time zone than you) but it's probably less surprising than the current behavior. Ideally I think it would be nice if this field was user-editable via the GUI.

[d7415]

I have a patch for PHPExif to convert Zulu timestamps to local time of the server. That's not necessarily correct either

Ideally the devices would store either UTC or with a specified TZ and then we could convert in the UI based on preference. But standards aren't very standard :(

[tmp-hallenser]

Sorry for the late response and I didn't look deeper into the example.

If I understood the standards correctly, then timezone "Z" means that the timezone has not been stored. This seems to be the case for some videos. Unless I missed something, this is exactly the behavior the extractor shows (potentially with some bugs :))

IMHO, the ideal solutions for lychee should look like:

1. We store the timezone in the db
2. timezone is shown on front an can be edited

If timezone is missing in the exif data, I see three options (user should be able to specify behavior, e.g. I'd prefer 1 or 3 on my installation at most of my video are taken on vacation not being in my normal timezone)

1. Leave timezone in db blank
2. Gestimate timezone be server timezone
3. Try to obtain timezone from latitude + longitude (see https://stackoverflow.com/a/16086964 for different options)

[ikosa]

sorry for my late response. @kamil4 sorry that was my bad. I figure ot that that file was not from 500D. Here is the output, i'll share an example file in a few hours. There is no timezone embedded in this file, it is also in zulu timezone like the file from my phone but in this file time is correct for my timezone (i mean it is time on +3:00 but recorded in zulu) But in the file from my phone it is converted into zulu timezone and recorded like that, means you have to add 3 hours to get the correct time.

Seems like two cituations conflicts with each other.

Canon 500D: object(PHPExif\Exif)#1883 (2) { ["data":protected]=> array(8) { ["width"]=> int(1280) ["height"]=> int(720) ["framerate"]=> float(30) ["duration"]=> string(9) "65.800000" ["creationdate"]=> object(DateTime)#1882 (3) { ["date"]=> string(26) "2010-05-23 07:11:30.000000" ["timezone_type"]=> int(2) ["timezone"]=> string(1) "Z" } ["FileName"]=> string(12) "MVI_3339.MOV" ["FileSize"]=> string(9) "220718393" ["MimeType"]=> string(15) "video/quicktime" } ["rawData":protected]=> array(44) { ["index"]=> int(0) ["codec_name"]=> string(4) "h264" ["codec_long_name"]=> string(41) "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10" ["profile"]=> string(20) "Constrained Baseline" ["codec_type"]=> string(5) "video" ["codec_time_base"]=> string(4) "1/60" ["codec_tag_string"]=> string(4) "avc1" ["codec_tag"]=> string(10) "0x31637661" ["width"]=> int(1280) ["height"]=> int(720) ["coded_width"]=> int(1280) ["coded_height"]=> int(720) ["has_b_frames"]=> int(0) ["pix_fmt"]=> string(8) "yuvj420p" ["level"]=> int(40) ["color_range"]=> string(2) "pc" ["color_space"]=> string(9) "smpte170m" ["color_transfer"]=> string(5) "bt709" ["color_primaries"]=> string(5) "bt709" ["chroma_location"]=> string(4) "left" ["refs"]=> int(1) ["is_avc"]=> string(4) "true" ["nal_length_size"]=> string(1) "4" ["r_frame_rate"]=> string(4) "30/1" ["avg_frame_rate"]=> string(4) "30/1" ["time_base"]=> string(6) "1/3000" ["start_pts"]=> int(0) ["start_time"]=> string(8) "0.000000" ["duration_ts"]=> int(197400) ["duration"]=> string(9) "65.800000" ["bit_rate"]=> string(8) "26835062" ["bits_per_raw_sample"]=> string(1) "8" ["nb_frames"]=> string(4) "1974" ["disposition"]=> array(12) { ["default"]=> int(1) ["dub"]=> int(0) ["original"]=> int(0) ["comment"]=> int(0) ["lyrics"]=> int(0) ["karaoke"]=> int(0) ["forced"]=> int(0) ["hearing_impaired"]=> int(0) ["visual_impaired"]=> int(0) ["clean_effects"]=> int(0) ["attached_pic"]=> int(0) ["timed_thumbnails"]=> int(0) } ["tags"]=> array(4) { ["major_brand"]=> string(4) "qt " ["minor_version"]=> string(9) "537331968" ["compatible_brands"]=> string(8) "qt CAEP" ["creation_time"]=> string(27) "2010-05-23T07:11:30.000000Z" } ["filename"]=> string(12) "MVI_3339.MOV" ["nb_streams"]=> int(2) ["nb_programs"]=> int(0) ["format_name"]=> string(23) "mov,mp4,m4a,3gp,3g2,mj2" ["format_long_name"]=> string(15) "QuickTime / MOV" ["size"]=> string(9) "220718393" ["probe_score"]=> int(100) ["MimeType"]=> string(15) "video/quicktime" ["filesize"]=> int(220718393) } }

[ikosa]

https://drive.google.com/file/d/1I6zHLN1eMkTkZNoPX_O9ZsubSSg8hpAD/view?usp=sharing

recorded at 15:55 local time (according to the camera settings) with Canon EOS 500D aka Rebel T1i

[tmp-hallenser]

I had a quick look the the provides examples:

1. Example URL: https://drive.google.com/file/d/1UJ8-fKndA2pUoPlMRnbepGQ-RqPtFsMH/view?usp=drivesdk ExifTool CreateDate: 2020:07:25 08:03:03 -> Correct?

2. Example URL: https://drive.google.com/file/d/1I6zHLN1eMkTkZNoPX_O9ZsubSSg8hpAD/view?usp=sharing ExifTool CreateDate: 2020:07:27 15:55:37 -> Correct?

The example from the first post seems to be a different file.

[kamil4]

1. Example
   URL: https://drive.google.com/file/d/1UJ8-fKndA2pUoPlMRnbepGQ-RqPtFsMH/view?usp=drivesdk
   ExifTool CreateDate: 2020:07:25 08:03:03 -> Correct?

No. As you can gather from the file name, the local time was actually 11:03 (11:02:58 when the recording started, I guess).

2. Example
   URL: https://drive.google.com/file/d/1I6zHLN1eMkTkZNoPX_O9ZsubSSg8hpAD/view?usp=sharing
   ExifTool CreateDate: 2020:07:27 15:55:37 -> Correct?

Yes.

And that's exactly the problem. As far as I can tell, apart from Apple-generated files (which include a timezone), there is no way for us to reliably distinguish between the local vs UTC creation times for movie files.

Here's what I would suggest:

1. For MP4 files, default to UTC. That's what the specs say and at least Android phones follow it.

2. For MOV files, default to local. The specs are unclear but popular digital cameras seem to put the local time.

3. Provide means to override the above defaults via new server configs (one per file type?).

4. Longer-term, enhance the front end so that the creation time is a user-editable field (you know, one of those fancy pop-up calendar buttons where one can specify the date/time).

[d7415]

4\. you know, one of those fancy pop-up calendar buttons where one can specify the date/time

Or even just the offset... Full editing would still be useful for bad/missing times, so maybe offset as part of it?

[tmp-hallenser]

Thanks for the explanation, that was helpful.

BTW, I just checked my videos on the iPhone and they have a proper timezone, e.g. [QuickTime] CreationDate : 2019:01:12 21:01:30+11:00

And that's exactly the problem. As far as I can tell, apart from Apple-generated files (which include a timezone), there is no way for us to reliably distinguish between the local vs UTC creation times for movie files.

Given what you've described below, you could use coordinate + time to determine timezone (if data is available, I'd guess it's often available on Android phones). Example 1 has been shot somewhere in Turkey, so we would need to convert it to UTC+03:00. Example 2, I agree that we have no chance in determining where this was shot.

Here's what I would suggest:

1. For MP4 files, default to UTC. That's what the specs say and at least Android phones follow it.

2. For MOV files, default to local. The specs are unclear but popular digital cameras seem to put the local time.

3. Provide means to override the above defaults via new server configs (one per file type?).

4. Longer-term, enhance the front end so that the creation time is a user-editable field (you know, one of those fancy pop-up calendar buttons where one can specify the date/time).

[ikosa]

I had a quick look the the provides examples:

1. Example URL: https://drive.google.com/file/d/1UJ8-fKndA2pUoPlMRnbepGQ-RqPtFsMH/view?usp=drivesdk ExifTool CreateDate: 2020:07:25 08:03:03 -> Correct?

As @kamil4 mentioned filename states the correct timestamp: 11:03:03

2. Example URL: https://drive.google.com/file/d/1I6zHLN1eMkTkZNoPX_O9ZsubSSg8hpAD/view?usp=sharing ExifTool CreateDate: 2020:07:27 15:55:37 -> Correct?

Yes that file has correct timestamp.

The example from the first post seems to be a different file.

Yes

[kamil4]

Given what you've described below, you could use coordinate + time to determine timezone (if data is available, I'd guess it's often available on Android phones). Example 1 has been shot somewhere in Turkey, so we would need to convert it to UTC+03:00.

Yes, agreed, it's an elegant solution in that case. It doesn't scratch my particular itch though as my files hardly ever have the location data, so I will focus instead on what I outlined. The two approaches strike me as inherently complementary anyway. @tmp-hallenser, are you planning to work on the location-timezone mapping or should we perhaps create a new issue in search for external contributors?

[tmp-hallenser]

My suggested would be the following:

• You get started with your implementation (and I'd vote for doing the time-zone conversion in Lychee and not in php-exif; I see the latter as the metadata extractor and Lychee adds some logic on top of it - similar to the decoding of coordinates into city, state, country etc.)

• Add some placeholder into the logic for someone to implement the time zone extraction via coordinates (and create a new issue)

  Just more thought: One could also try to estimate the timezone based on other photos/videos in the folder. Let's say, if all have the same time zone (omitted ones w/o a timezone), it could be a fair assumption that the new element was taken in the same time zone. In any case, we should add some config parameters for the user to specify the behaviour.

Am Di., 28. Juli 2020 um 23:05 Uhr schrieb Kamil Iskra < notifications@github.com>:

Given what you've described below, you could use coordinate + time to determine timezone (if data is available, I'd guess it's often available on Android phones). Example 1 has been shot somewhere in Turkey, so we would need to convert it to UTC+03:00.

Yes, agreed, it's an elegant solution in that case. It doesn't scratch my particular itch though as my files hardly ever have the location data, so I will focus instead on what I outlined. The two approaches strike me as inherently complementary anyway. @tmp-hallenser https://github.com/tmp-hallenser, are you planning to work on the location-timezone mapping or should we perhaps create a new issue in search for external contributors?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LycheeOrg/Lychee/issues/675#issuecomment-665282479, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOILSKUTFE6TFQH7ITZZDTR544RJANCNFSM4PHE4JQQ .

[kamil4]

Agreed about doing the conversion in Lychee rather than php-exif. I closed my initial PR yesterday for that reason (note that I have three more PRs waiting there for somebody's attention, hint, hint! :smile:).

[ildyria]

I just want to point out that when I did my all around the word trip, I did not change the time of my camera each moment I passed a time zone... :)

[ikosa]

selecting multiple photos and adding/subtracting time will be a life saving feature when:

if Lychee cant get the correct TZ of the photo (because of the reasons stated in this thread) if time settings in your device is not right if you visit someone abroad and their devices are on different TZ

actually i prefer to make this corrections on orijinal files but it will be enough for most of the people to do it on the Lychee and also that will shorten the process (remove and readd the files) for people like me.

[ildyria]

@ikosa actually you can already do it by directly modifying it... in the database. :innocent:

[kamil4]

So the https://github.com/LycheeOrg/Lychee/pull/680 PR I just submitted should address the original complaint. It's server-side-only; there are no GUI changes. I agree with the GUI change ideas that were discussed here but those are left for future work.