How to deal with incorrect quicktime timestamps?

[cowwoc]

Per https://exiftool.org/forum/index.php?topic=7911.msg40318#msg40318:

The problem lies in the specification of the QuickTime date fields. These are 32 bit integers measuring the time in seconds since 1904, however many brain dead programs (as Phil rightly calls them) used the “unix” standard of 1970 as starting point. To cater for this (common) error, Phil decided to assume 1970 as starting point for dates before 1970 (when counting from 1904). Effectively this means exiftool, by default, does not show you the correct date for dates < 1970.

This brings up some questions:

• Do we apply the same adjustment automatically in this library?
• Do we document this recommended behavior in the Javadoc?
• Do we add an option to optionally enable this behavior?

I mention this because I'm getting some MP4 timestamps returning 1946 with this library and 2012 with exiftool and I know for a fact the latter is correct. I am applying the above adjustment manually in the application layer but it took me a while to track down the cause.

[drewnoakes]

~Sounds like a bug, so long as the specification is clear.~ We have examples of using different epochs in the code today. Want to take a look at fixing this? It shouldn't be too hard to find the relevant bit of code. I'd applying the transformation when reading from the QuickTime data, and setting a DateTime on the Directory.

Edit: re-read the quoted comment and understand the problem better now. Yeah, it's less clear. It is possible that some system digitized old footage and set the date for that footage before 1970, in which case this transformation would give an incorrect date. That seems less likely than the other bug though, so I guess it's a fair trade off.

Longer term I'd like to allow controlling this kind of thing with 'feature flags' for the library, to allow finer grained control over these kinds of workarounds, giving an escape hatch for times when they get in the way.

[drewnoakes]

Also, if you have a small file that repros this we should add it here (so long as none of the existing files repro it).

[cowwoc]

@drewnoakes I've got an MP4 file with this problem. Unfortunately, it is not short and family members are in the video so it's not something I'd like to publish on the internet. I tried truncating the video to 1 video frame using Handbreak but doing so loses all metadata. I tried transferring the metadata from the old video to the new one but exiftool insists on fixing the timestamp in transit so I can't transfer the "bad" metadata over unchanged. Any ideas?

[Nadahar]

I've successfully used FFmpeg to truncate video files without losing metadata before, but MP4 can be tricky since it might put the metadata last AFAICR. It's still worth a shot. If that doesn't work, MP4Box might do the trick.

[cowwoc]

@Nadahar I haven't been able to make this work in ffmpeg and the server containing binary builds of MP4Box (some server in France) is currently timing out. I'm open to suggestions. If you've got a specific command-line that works for you in ffmpeg, let me know. When I tried it just now it dumped all metadata in the output file.