Bug 479676

File date and metadata date of a video file may differ. Some devices store a UTC date in the metadata or vice versa, but do not set the UTC flag correctly. We need a test video sample to reproduce it.

Maik

I am sharing a sample MP4 straight from the camera. I tried to get the smallest file but it is still over the attachment limit, so I am dropping it somewhere on a file host. 

Oddly enough, some MP4 generated by FFMPEG and all of my MOV files do not have this problem. One of the generated MP4 is like 5 minutes behind. 

https://file.io/6ft18AiCrNu3

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

The original file host has expired. I'm sharing it from a Dropbox account that should not be automatically deleted.

https://www.dropbox.com/scl/fi/b12q85fq3g4twbbjg2b3y/DJI_20240112072750_0360_D.MP4?rlkey=87952qhvleotmec14ilvgibxw&dl=0

I imported the video here under digiKam-8.3.0. A creation date of 2024/12/01 15:27 is displayed. ExifTool shows exactly the same date/time. I don't see any error.

Maik

Created attachment 165277 [details]
Original MP4 Downloaded from Camera on Day when it was Shot

Created attachment 165278 [details]
Same MP4 Downloaded from Dropbox

Created attachment 165279 [details]
Sampe MOV File from Dropbox

Created attachment 165280 [details]
Window Explorer date fields

Created attachment 165281 [details]
Windows Explorer Media Date Metadata (the Correct One)

Created attachment 165282 [details]
Adjusting Date Time via Digikam

Created attachment 165283 [details]
Original MOV file

Created attachment 165284 [details]
Exif Data from MOV File (Quicktime)

Created attachment 165285 [details]
Exif Data from MOV File (Exif)

Created attachment 165286 [details]
Adjust date time digikam - invalid dates

Thanks for looking into this Maik.

The 2024/12/01 15:27 is the correct time in UTC but what I would have preferred is the local time. I made several tests including downloading the same files I uploaded to Dropbox as that will change some date fields and I want to see the differences.

In the original MP4 file https://bugs.kde.org/attachment.cgi?id=165277, The File date in the file properties is the "correct" local time though digiKam read the UTC time. In the same MP4 file downloaded from Dropbox https://bugs.kde.org/attachment.cgi?id=165278, that correct file date is now changed. 

I repeated the test with a MOV (MVI_0313) file https://www.dropbox.com/scl/fi/xcepg8dbzjy99fefl2qc2/MVI_0313.MOV?rlkey=bwwenrncrcms7hy9cxdm6y20n&dl=0 
and digikam read the correct local date in either case.

Looking into the date files with Windows Explorer https://bugs.kde.org/attachment.cgi?id=165280, I find that the "Date" column gives the desired information and it seem to map to the Media created date listed under the Origin section when I inspected the details. https://bugs.kde.org/attachment.cgi?id=165281.

I dug further into the ExifData and I see that the correct local time is recorded in the Exif section but not the Quicktime section. The Exif section does not exist for the MP4 file. Further to the confusion, another Mov file (MVI_0392) https://www.dropbox.com/scl/fi/f1dtcdtl740d1oj5vh7l0/MVI_0392.MOV?rlkey=dgyld8q2nz73x93o4stt5ksaf&dl=0 from the same camera behaves like the MP4. 

If I were to adjust the timestamp manually in digiKam, it is the "file name timestamp" option https://bugs.kde.org/attachment.cgi?id=165282, but trying to adjust the timestamp for MVI_0392, it says invalid date. https://bugs.kde.org/attachment.cgi?id=165286

Hope you can reproduce the various scenarios with the MOV files. 

Thanks.

Git commit aca13364f3b83040bbd0be3d29cea521cfab4621 by Maik Qualmann.
Committed on 29/01/2024 at 19:29.
Pushed by mqualmann into branch 'master'.

fix video date/time for the Osmo Pocket 3

M  +3    -1    core/libs/metadataengine/dmetadata/dmetadata_video.cpp

https://invent.kde.org/graphics/digikam/-/commit/aca13364f3b83040bbd0be3d29cea521cfab4621

Git commit c9620f24b9d7e936a62b779fffb9be9b53630b1b by Maik Qualmann.
Committed on 29/01/2024 at 19:55.
Pushed by mqualmann into branch 'master'.

assume UTC with Canon QuickTime video container

M  +6    -5    core/libs/metadataengine/dmetadata/dmetadata_video.cpp

https://invent.kde.org/graphics/digikam/-/commit/c9620f24b9d7e936a62b779fffb9be9b53630b1b

To understand this problem, there are video devices that store UTC, but do not set the UTC flag, other devices store local time, but set the UTC flag, etc. Most smartphones have this implemented relatively correctly, but camera devices are confused.
We actually have to try to recognize the video based on the metadata.

Note that the metadata will need to be read from the video files again when a version with these changes is available.

Another thing and another problem is that the local time is relative, as the video files usually do not contain time zone information.

Maik

Thanks for the fix along with the details. 

It is unfortunate that you have to make all these special exceptions in the code base to accommodate their lack of consistency. Hopefully DJI doesn't decide to "fix" their end in a future firmware update. 

Thanks.