Error setting date/time for mp4 files

[hberndt]

Hello,

I am trying to set the timestamp for mp4 files:

Code Select Expand

$ ~/bin/Image-ExifTool/exiftool -ver -quicktime:createdate="2025:01:29 18:43:06" PXL_20250129_184102134.mp4
13.17
Error: No data reference for sample description 0 for Track1 - PXL_20250129_184102134.mp4
    0 image files updated
    1 files weren't updated due to errors
I've seen this error mentioned several times in other threads, but the solution was always to upgrade to exiftool version 12.41. Since my system installation came with v12.40, I pulled the latest version of exiftool, as you can see in the print, but unfortunately I still have the same issue.

I've also read that there were issues especially with videos created from Google Pixel cell phones, so it might be worth noting that the videos in question were recorded with a Pixel 8a.

Any ideas?

Thanks, Holger

[StarGeek]

Can you provide a sample file?

[hberndt]

Hi StarGeek, sure, I have a 2sec / 5.7M sample here. Is that ok to attach here, or how would I provide it?

[StarGeek]

You can attach it here. I think 5MB is under the max limit the forum allows. Otherwise a link to a site like Dropbox/Google Drive/etc works.

[hberndt]

So here we go. Thanks for having a look!

[StarGeek]

The first track is a data track. That's very weird. Normally, the first track is a video track, followed by one or more audio tracks, then any other tracks.

I don't know if that is what the problem is. Phil will have to take a look at the file to see what's going on.

Ffprobe output

Code Select Expand

PS C:\> ffprobe -hide_banner Y:\!temp\x\y\PXL_20250129_184102134.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Y:\!temp\x\y\PXL_20250129_184102134.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 131072
    compatible_brands: isomiso2mp41
    creation_time   : 2025-01-29T18:41:06.000000Z
    location        : +48.7455+8.9590/
    location-eng    : +48.7455+8.9590/
    com.android.capture.fps: 30.000000
    com.android.model: Pixel 8a
    com.android.manufacturer: Google
  Duration: 00:00:02.35, start: 0.000000, bitrate: 20234 kb/s
  Stream #0:0[0x1](eng): Data: none (mett / 0x7474656D), 42 kb/s (default)
      Metadata:
        creation_time   : 2025-01-29T18:41:06.000000Z
        handler_name    : MetaHandle
  Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 193 kb/s (default)
      Metadata:
        creation_time   : 2025-01-29T18:41:06.000000Z
        handler_name    : SoundHandle
        vendor_id       : [0][0][0][0]
  Stream #0:2[0x3](eng): Video: hevc (Main) (hvc1 / 0x31637668), yuvj420p(pc, bt709), 1920x1080, 19988 kb/s, SAR 1:1 DAR 16:9, 29.80 fps, 29.83 tbr, 90k tbn (default)
      Metadata:
        creation_time   : 2025-01-29T18:41:06.000000Z
        handler_name    : VideoHandle
        vendor_id       : [0][0][0][0]
      Side data:
        displaymatrix: rotation of -90.00 degrees
Unsupported codec with id 0 for input stream 0
PS C:\>

[Phil Harvey]

This is going to take some time to research.  Upon first inspection the format of the sample description box for track 1 looks wrong.  I need to spend some time reading the MP4 specification to understand what is going on.

- Phil

[hberndt]

Thank you, too, Phil.

[Phil Harvey]

I have another MP4 sample (from a Google Pixel 4a) that shows this same problem.

While the MP4 specification is poorly written and confusing, my understanding is that the format of each SampleEntry in the sample description box is:

1. int32u entry size
2. int32u entry type
3. int8u[6] reserved
4. int16u data_reference_index
5. (followed by type-specific data)

However, in this specific case (entry type "mett"), the reserved bytes and the data_reference_index entries are missing, which is why ExifTool gives an error when writing this video.  Unfortunately the data_reference_index is required to determine if the data exists in an external file (which is unusual, but possible, and in this case the data offsets should not be updated when the file is rewritten).

According to the specification, the "mett" box is derived from the standard SampleEntry box, so should have the above format.  I have two other MP4 samples from other devices (drones) that use the "mett" box, and both contain the required data_reference_index.

I am convinced this is a bug in the software that wrote this video.  But since this problem appears in videos from both the Google Pixel 4a and 8a, it is likely that it is widespread across other Google phones as well, so I feel that ExifTool should be able to write these files anyway.

Having said all this, ExifTool 13.12 and earlier were more forgiving of sample description problems in non-audio/video tracks, and would rewrite this file.

I'll patch ExifTool 13.17 to revert to the previous behaviour, even though I believe this is a bug in the way the file is written, rather than an ExifTool bug.

Thanks for this report.

- Phil

[hberndt]

Hello Phil, thanks a lot for the explanations and the willingness to workaround this presumably widespread bug in camera software. I can confirm that with exiftool version 13.12 I am able to set the "createdate" field for that video.