Distinguish UTC vs local video takestamps #680
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ildyria
reviewed
Jul 30, 2020
| @@ -237,7 +272,7 @@ public function extract(string $filename, string $type): array | |||
| $metadata['position'] = implode(', ', $fields); | |||
| } | |||
|
|
|||
| if (strpos($type, 'video') !== 0) { | |||
There was a problem hiding this comment.
yeap I'm reading I'm reading. :) I just quickly commented. :p
ildyria
reviewed
Jul 30, 2020
| @@ -82,7 +82,7 @@ public function extract(string $filename, string $type): array | |||
| $is_raw = true; | |||
| } | |||
|
|
|||
| if (strpos($type, 'video') !== 0) { | |||
There was a problem hiding this comment.
Pretty sure... It's because of those crazy MPG files being identified by mime_content_type as image/x-tga. So I added image/x-tga to $validVideoTypes, fixed file_type to do what it was actually supposed to (so that it actually returns 'video' for video files), and then replaced all these ad-hoc tests by the more robust checks based on the value returned by file_type.
Handle MPG videos correctly. Handle WMV videos with Exiftool extractor correctly. Fix the broken PhotoFunctions::file_type method which would not distinguish between images and videos. Don't extract a video frame if FFmpeg is disabled in the config.
kamil4
force-pushed
the
fix-video-takestamps
branch
from
4fdc87f
to
4395b79
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
ildyria
approved these changes
Aug 17, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #675.
This adds a heuristic to determine whether the takestamp embedded in a video file is in UTC or in local time. The heuristic is based on the filename extension. There is a new config variable,
local_takestamp_video_formats, that provides a list the extensions for files that should be treated as having a takestamp in the local time zone. It defaults to AVI and MOV, as those are the two most commonly used in digital cameras, which typically use the local time zone. For files that don't match (such as MP4 files from Android phones) the takestamp is considered to be in UTC and is converted at import time to the local time zone of the server.While working on this I noticed several bugs that this PR also fixes. In particular:
MPG files were treated as image files because at least on my system that's what the MIME says (
image/x-tga)?!file_typemethod inPhotoFunctionswas fundamentally broken; it would returnphotofor video files. Fixing its twisted logic required a complete refactoring.With that fixed, I was able to replace all the ad-hoc tests for video files based on MIME, which didn't work for MPG files (see above).
WMV videos misbehaved when using the Exiftool metadata extractor because of conflicting MIME data (Exiftool identifies them as
video/x-ms-wmv). There were many other issues when using Exiftool instead of FFmpeg for video files' metadata, which were addressed in Video fixes php-exif#22 (now merged).If FFmpeg is disabled in the config, we shouldn't try to use it to for anything, including extracting a video frame for the thumb. I fixed that particular use case but it appears that there may be more left in the new live photos support? I'm not familiar with that feature so I didn't touch it. @tmp-hallenser?