Odd date/time problem with MP4 from Samsung camera, dates long in past or future

Started by yetanfou, February 01, 2021, 05:52:40 AM

Previous topic - Next topic
Print
Go Down Pages1
User actions

yetanfou

February 01, 2021, 05:52:40 AM Last Edit: February 01, 2021, 06:17:55 AM by yetanfou
In yet another attempt to order those tens of thousands of photos and videos so that (physically) distant family can partake of the pleasures of our lives here in the frozen north I turned to exiftool to organise them in a time-based hierarchy. This, for the most, works as intended, the media end up in directories according to their respective filemodifydate/createdate/datetimeoriginal . The problem arises with MP4 files produced by a specific Samsung WB2000 camera, the problem becomes clear by looking at the output of exiftool -time:all -g1 -a -s BY_DATE/1971/1971-02-19/19710219_192338_SAM_0808.MP4 (just to give an example of such a file):

Code Select
---- System ----
FileModifyDate                  : 2011:11:03 22:45:06+01:00
FileAccessDate                  : 2020:02:26 10:54:47+01:00
FileInodeChangeDate             : 2021:01:31 18:38:17+01:00
---- QuickTime ----
CreateDate                      : 1971:02:19 19:23:38
ModifyDate                      : 1971:02:19 19:23:38
---- Track1 ----
TrackCreateDate                 : 1971:02:19 19:23:38
TrackModifyDate                 : 1971:02:19 19:23:38
MediaCreateDate                 : 1971:02:19 19:23:38
MediaModifyDate                 : 1971:02:19 19:23:38
---- Track2 ----
TrackCreateDate                 : 1971:02:19 19:23:38
TrackModifyDate                 : 1971:02:19 19:23:38
MediaCreateDate                 : 1971:02:19 19:23:38
MediaModifyDate                 : 1971:02:19 19:23:38

Why, we're back in time... Another video, taken a bit earlier gives even more confounding dates:

Code Select
---- System ----
FileModifyDate                  : 2011:10:25 12:12:38+02:00
FileAccessDate                  : 2020:02:26 10:54:42+01:00
FileInodeChangeDate             : 2021:01:31 18:37:27+01:00
---- QuickTime ----
CreateDate                      : 2038:10:22 14:29:15
ModifyDate                      : 2038:10:22 14:29:15
---- Track1 ----
TrackCreateDate                 : 2038:10:22 14:29:15
TrackModifyDate                 : 2038:10:22 14:29:15
MediaCreateDate                 : 2038:10:22 14:29:15
MediaModifyDate                 : 2038:10:22 14:29:15
---- Track2 ----
TrackCreateDate                 : 2038:10:22 14:29:15
TrackModifyDate                 : 2038:10:22 14:29:15
MediaCreateDate                 : 2038:10:22 14:29:15
MediaModifyDate                 : 2038:10:22 14:29:15


Why, we're in the future, even beyond the Y2038 barrier...

What is going on here? Is this a byte order problem? A signed/unsigned error? Garbled dates in the files? I can of course sort these specific files by their FileModifyDate but that is a bit of a cop-out, it also makes those dates less useful since the camera did and does actually know the time and date when the video was made. That data is there in some way, what remains is to read it so that it makes sense...

Has anyone seen this type of date/time error before? It is not the normal "UTC offset" problem. Another point of data is how how ffprobe interprets these dates on two different machines, both running Debian, one machine running a 32-bit distro on a 32-bit CPU, the other 64-bit on 64-bit CPUs:

Machine 1, 32-bit

Code Select
$ ffprobe /net/media.example.org/photos/import/2011-10-25/SAM_0780.MP4

(useless guff elided)
  Metadata:
    creation_time   : 1902-09-16T08:00:59.000000Z

Machine 2, 64-bit:

Code Select
$ ffprobe /net/media.example.org/photos/import/2011-10-25/SAM_0780.MP4

(useless guff elided)
  Metadata:
    creation_time   : 2038-10-22T14:29:15.000000Z

The output for exiftool is identical on both machines.

Phil Harvey

#1
February 01, 2021, 07:20:42 AM
Can you show me the output of the exiftool -v3 option CreateDate and ModifyDate, like this?:

Code Select
  | | CreateDate = 3206613834
  | | - Tag 0x0001 (4 bytes, int32u[1]):
  | |     0014: bf 21 0b 4a                                     [.!.J]
  | | ModifyDate = 3363349439
  | | - Tag 0x0002 (4 bytes, int32u[1]):
  | |     0018: c8 78 a3 bf                                     [.x..]

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

yetanfou

#2
February 01, 2021, 07:27:53 AM
This is the output for the "2038" video:

Code Select
  | | CreateDate = 4254215355
  | | - Tag 0x0001 (4 bytes, int32u[1]):
  | |  bd6d534: fd 92 2c bb                                     [..,.]
  | | ModifyDate = 4254215355
  | | - Tag 0x0002 (4 bytes, int32u[1]):
  | |  bd6d538: fd 92 2c bb                                     [..,.]


This is for the "1971" video:

Code Select
  | | | TrackCreateDate = 35839418
  | | | - Tag 0x0001 (4 bytes, int32u[1]):
  | | |  1204880: 02 22 dd ba                                     [."..]
  | | | TrackModifyDate = 35839418
  | | | - Tag 0x0002 (4 bytes, int32u[1]):
  | | |  1204884: 02 22 dd ba                                     [."..]

Phil Harvey

#3
February 01, 2021, 07:34:32 AM Last Edit: February 01, 2021, 08:02:09 AM by Phil Harvey
Those are basically what I expected.  I can't see how/why ffprobe would show different values for these.  Any very low number (eg. 02 22 dd ba) should be close to 1970, and any high number (eg. fd 92 2c bb) should be close to 2038.  These numbers are always stored high byte first.

- Phil

Edit:  Hold on a sec.  QuickTime date/time values do not use the Unix epoch of 1970, so I need to rethink this...

Edit2: Actually, for the Unix epoch, 2038 is reached at 0x80000000, not 0xffffffff.  But QuickTime videos are supposed to use an epoch of 1904.  However, I've often seen them using the Unix epoch, so ExifTool includes a patch that will assume the Unix epoch if any date/time value based on the QuickTime epoch is before 1970.  The upper limit of the QuickTime date/time range is 2040 (0xffffffff seconds from 1904).  All a bit convoluted, but I still can't explain the ffprobe result.

Edit3: OK.  Maybe I understand ffprobe.  If you interpret 0xfd922cbb as signed relative to the Unix epoch, then you maybe get something around 1902.  And if you interpret it as unsigned relative to the QuickTime epoch, you get something around 2038.  So ffprobe probably has a patch similar to ExifTool that tries to decide which epoch is best.  But it is a "feature" that the 32-bit and 64-bit versions of ffprobe interpret the sign differently.
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

yetanfou

#4
February 01, 2021, 08:36:36 AM Last Edit: February 01, 2021, 10:14:32 AM by yetanfou
Here's a a few more datapoints from this camera. The camera allows the date to be set to anything between 2010-01-01 and 2050-12-31. In the first video the date was kept at the default 0f 2010-01-01, in the second it is set to the current date, the third at 2050-12-31 and the fourth at 2038-01-01. When reviewing the videos on the camera the dates are displayed correctly.

This is the "2010-01-01" video:
Code Select
  | | CreateDate = 2908133937
  | | - Tag 0x0001 (4 bytes, int32u[1]):
  | |   8bc974: ad 56 9a 31                                     [.V.1]
  | | ModifyDate = 2908133937
  | | - Tag 0x0002 (4 bytes, int32u[1]):
  | |   8bc978: ad 56 9a 31                                     [.V.

...which displays as...
---- QuickTime ----
CreateDate                      : 1996:02:25 22:58:57
ModifyDate                      : 1996:02:25 22:58:57


This is the "2021-02-01" video - notice the warning:
Code Select
  | | CreateDate = 606183198
  | | - Tag 0x0001 (4 bytes, int32u[1]):
  | |   68bbb4: 24 21 9f 1e                                     [$!..]
  | | Warning = [minor] Patched incorrect time zero for QuickTime date/time tag
  | | ModifyDate = 606183198
  | | - Tag 0x0002 (4 bytes, int32u[1]):
  | |   68bbb8: 24 21 9f 1e                                     [$!..]
...which displays as...
---- QuickTime ----
CreateDate                      : 1989:03:18 00:13:18
ModifyDate                      : 1989:03:18 00:13:18


This is the "2050-12-31" video:
Code Select
  | | CreateDate = 3962670639
  | | - Tag 0x0001 (4 bytes, int32u[1]):
  | |   e742b4: ec 31 8e 2f                                     [.1./]
  | | ModifyDate = 3962670639
  | | - Tag 0x0002 (4 bytes, int32u[1]):
  | |   e742b8: ec 31 8e 2f                                     [.1./]
...which displays as...
---- QuickTime ----
CreateDate                      : 2029:07:27 05:50:39
ModifyDate                      : 2029:07:27 05:50:39


This is the "2038-01-01" video, again notice the warning:
Code Select
  | | CreateDate = 1757657142
  | | - Tag 0x0001 (4 bytes, int32u[1]):
  | |   2f7554: 68 c3 b8 36                                     [h..6]
  | | Warning = [minor] Patched incorrect time zero for QuickTime date/time tag
  | | ModifyDate = 1757657142
  | | - Tag 0x0002 (4 bytes, int32u[1]):
  | |   2f7558: 68 c3 b8 36                                     [h..6]
...which displays as...
---- QuickTime ----
CreateDate                      : 2025:09:12 06:05:42
ModifyDate                      : 2025:09:12 06:05:42

Phil Harvey

#5
February 01, 2021, 09:18:22 PM
Those numbers look random as far as I can see.  I'm guessing the camera is getting the date from somewhere else.  Maybe try adding -ee2 (with ExifTool 12.16) to see what date/time is embedded in the video stream (assuming these are H264-encoded).

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

yetanfou

#6
February 02, 2021, 11:56:50 AM Last Edit: February 02, 2021, 06:43:06 PM by yetanfou
There is no other data in any of the streams, they all have the same as of yet undecipherable CreateDate. The numbers are not random though, there is a method to the madness. I made two series of short videos with dates set to 2010-01-01 to 2022-01-01, here are the resulting CreateDate data:

First series:

Code Select
2010:   | |   66314c: ad 56 65 6d                                     [.Vem]
2011:   | |   31e09c: 05 07 83 34                                     [...4]
2012:   | |   440e6c: 5c b8 af 1c                                     [\...]
2013:   | |   5047fc: b9 90 38 ab                                     [..8.]
2014:   | |   374ccc: 11 41 64 27                                     [.Ad']
2015:   | |   47a1bc: 68 f2 90 8c                                     [h...]
2016:   | |   2d7d2c: c0 a3 bd d8                                     [....]
2017:   | |   371be4: ad 56 54 a0                                     [.VT.]
2018:   | |   30b564: 75 2c 74 55                                     [u,tU]
2019:   | |   2c1ddc: cc dd 9c 8c                                     [....]
2020:   | |   44e30c: 24 8e e4 f4                                     [$...]
2021:   | |   31fd3c: 81 66 53 49                                     [.fSI]
2022:   | |   47895c: d9 17 7d 0f                                     [..}.]


Second series:
Code Select
2010:   | |   e1fc1c: ad 56 63 60                                     [.Vc`]
2011:   | |   2dd474: 05 07 84 2c                                     [...,]
2012:   | |   33898c: 5c b8 ad fb                                     [\...]
2013:   | |   32ee94: b9 90 36 3d                                     [..6=]
2014:   | |   456984: 11 41 64 31                                     [.Ad1]
2015:   | |   3cc8e4: 68 f2 8d d1                                     [h...]
2016:   | |   290bac: c0 a3 b9 d2                                     [....]
2017:   | |   2c84f4: 1d 7b 46 e8                                     [.{F.]
2018:   | |   2f1e7c: 75 2c 78 02                                     [u,x.]
2019:   | |   3d7e5c: cc dd 9a 7e                                     [...~]
2020:   | |   43e504: 24 8e c7 ac                                     [$...]
2021:   | |   28af4c: 81 66 4e be                                     [.fN.]
2022:   | |   33059c: d9 17 7e 20                                     [..~ ]


Notice the high word in both series being more or less identical, except for the year 2017. It *is* recording something there, the question is what.

I'm not going to waste more time on this now, nor should anyone else. These video's will have to be sorted by their file dates until I get the urge to delve deeper into this mystery.

Phil Harvey

#7
February 02, 2021, 01:14:45 PM
It actually looks like the date/time is being purposely encrypted/obfuscated somehow, but I can't think of why they would want to do that.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).
Print
Go Up Pages1
User actions