Which date best for dates on Video (MP4) files?

[Redintention]

Hi,

Current scenario: photos and videos are automatically synced from phone to PC with date and time in filename. Whatsapp and other messenger apps have metadata stripped, while those taken on phone are fine.

What I want: I want exiftool to take the date from the filename and tag photos and videos that don't have the date/time embedded already, while ignoring those that do. Ultimately will be uploaded to Google Photos so would like a tag recognised by this.

What I have done with photos: I run:  exiftool.exe -if "not $DateTimeOriginal" "-AllDates<filename" "-FileCreateDate<filename" "-FileModifyDate<filename" "Path to folder" -r

I would like to do the same with videos, but I'm confused as to what to use instead of $DateTimeOriginal and whether -AllDates is still a valid option. My confusion is coming from getting "No data reference for sample description 0 for Track1" when I try to run the command on MP4 files taken with the phone so I am thinking I must not be able to use $DateTimeOriginal?

Any help appreciated!

Thank you   

[StarGeek]

I would like to do the same with videos, but I'm confused as to what to use instead of $DateTimeOriginal and whether -AllDates is still a valid option. My confusion is coming from getting "No data reference for sample description 0 for Track1" when I try to run the command on MP4 files taken with the phone so I am thinking I must not be able to use $DateTimeOriginal?

There is a DateTimeOriginal that is available for videos, but it's not always read by many programs.  The most commonly used tag for videos is the Quicktime:CreateDate tag.

Setting the timestamps in a video with AllDates will work with video files and it will set the Quicktime:CreateDate tag, but you need to be aware of the fact that video timestamps are different than image timestamps.  See the fourth paragraph on the Quicktime tags page.. The major video timestamps, CreateDate, ModifyDate, and the various track timestamps are supposed to be set to UTC, not the local time as in image files.  You can tell exiftool to adjust the time with the -api QuickTimeUTC option if  the video was taken in same timezone as the computer is currently in.  If it's not in the same timezone, you'll need to add the timezone when you write the tag.

For example, if I take a video in my current time zone, Pacific Time (Daylight time is automatically adjusted for), then I could run
exiftool "-AllDates<Filename" -api QuickTimeUTC File.mp4
But if I go to New York and take a video, then I need to set the time zone exactly, accounting for Daylight time.  So it would be
exiftool "-AllDates<Filename -05:00" -api QuickTimeUTC File.mp4
or for Daylight savings
exiftool "-AllDates<Filename -04:00" -api QuickTimeUTC File.mp4

Also, the Quicktime:CreateDate always exists.  It will be set to all zeroes if it isn't set or 1903:12:31/1904:01:01 (depending upon your timezone) if you use the -api QuickTimeUTC option.  So you can't just run -if "not $CreateDate".  You have to run -if "$CreateDate=~/0000:00:00/" if you don't use the -api QuickTimeUTC option or -if "$CreateDate#=~/1903:12:31/" or -if "$CreateDate#=~/1901:01:01/" if you do use the -api QuickTimeUTC option, depending upon your timezone.

My confusion is coming from getting "No data reference for sample description 0 for Track1" when I try to run the command on MP4 files taken with the phone so I am thinking I must not be able to use $DateTimeOriginal?

This may be a problem due to the way the file is formatted.  It previously popped up in a Pixel 4a video and exiftool may not be able to edit the file.

[Redintention]

Wow. Thank you SO much. There's a lot there for me to make some decisions on but that's given me a complete picture (no pun intended) of where I need to go. I really appreciate it.

That's very interesting about the file itself. Interestingly this is a Pixel 6 Pro so it would appear that Google have stuck to this which is frustrating. That is not a Pixel exclusive I think I'm going to like. I'll use that other thread to get information for a bug report I think and see if it gets anywhere. No harm in trying.

Really appreciate the assistance and expertise there - thank you.