Import H264 Create Date into {File.DateTime}

[WebEngel]

As Is: When importing a M2TS file in H264 format, Imatch populates the {File.DateTime} with the timestamp from the file system and ignores the present H264 metadata (Date/Time Original).

To be: Imatch to populate the {File.DateTime} from the present H264 metadata (Date/Time Original), if it is available.

(And yes, the clock in my camera was offset by 2 min, sorry)

[Mario]

I can do that. IMatch does check many other tags for video files too (no standard).

It puzzles me why the folks who designed H264 and the metadata did not just use XMP and instead added yet another proprietary set of tags.
There are even some tags which one would usually expect in EXIF, like shutter speed or exposure time. But they did neither use EXIF nor XMP.
All the data stored in the H264 metadata would fit nicely into an XMP record.
I will never understand why camera and other vendors cannot just use an established metadata standard...

Question:

The time in the video file is recorded as 2020:07:06 21:04:37+02:00 DST. The DST suffix as an addendum to the time zone suffix is new to me.
The time is UTC +02:00 hours. But since there is a DST flag, the local time is actually +01:00 hours.
I think IMatch should just set the time zone offset to +01:00 when filling the XMP date created and date subject created on import. Correct?

[WebEngel]

Hi Mario,

I agree to your frustration with H264 metadata or movie metadata in general (still no easy way to find simple things like aperture, exposure time in movies).

I found

<H264:DateTimeOriginal>2020:07:06 21:04:37+02:00 DST</H264:DateTimeOriginal>

and I agree, this is double-counting.  I live at UTC+1 DST, and this is how the cam is setup.  I can live with either "+2" or "+1 DST", whatever is more common.

[Mario]

The problem is EXIF (no time zone) and XMP (no meaning of DST).
I just subtract one hour from the TZO when producing the date and time from the H264 proprietary data. This then gives the File.DateTime used by IMatch.