-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MP4 time stamps still a muddle #460
Comments
From what I can see, the reported dates are correct. I'm curious why That said, Thus, your goal of actually finding the local light conditions and automatically compensating for this seems impossible unless you have the location/time-zone information from another source than the MP4 metadata. If you have this information on the other hand, it should be easy to format the date for that time zone. |
Sorry if I seem obtuse, but what does EDT have to do with the time stamp on that MP4? This is like having the aperture on a JPG that's f5,6 but having M-E tell me that it's f2,8 EDT, and if I don't like that, I can do my own conversion. The local time zone of the user is not relevant. Period. Why bother reporting it at all? And if my application has other information with which it can determine the actual local time (like grabbing the file name in this case, though I naturally wouldn't do that - too many chances to screw it up), the EDT information is of no value. Ever. All I need from M-E is, literally, 2017:07:22 11:37:03. If my application wants to change the metadata to 2017:07:22 13:37:03 to reflect the local reality, it certainly doesn't want M-E then turning around and second-guessing what I've done. I hate to mention the competition, but exiftool gets this right, and has for years. |
You're missing an essential issue. Exiftool is an application, although a command line one. It formats the output for the end user. Metadata-extractor is a Java library which can't be used by end users directly. You need a (Java) application to operate Metadata-extractor's API to use it. Metadata-extractor simply provides a Java If somebody use Metadata-extractor to make a command line tool, like Exiftool, that command line tool would be responsible for not applying the local time-zone when reporting dates. |
I think the underlying problem is that the time stamp in an MP4 isn't really a Date object, or at least can't be treated like one. Unlike the EXIF date in a JPG, it creates its own reality. It wouldn't be so bad if you could easily add your own "real date and time" to the metadata of an MP4, but that appears to be a tall order, especially since they don't seem to support xmp, which would be the ideal solution. Where I'm coming from is that I have users who want to display the time stamp on their videos in their web albums. The metadata in the MP4 doesn't contain enough information to cough up the real date and time. Only the user can supply the missing info ("I was in the Fextal!"). But then there's no way for him to plug the real date and time back into the MP4 for future use. If he changes the existing timestamp, the next time he uses that video in a project, M-E is going to assume that it still contains GMT when, in fact, it's been "corrected" by the user. Theory is all very nice, but the real world is looking for something else. |
Your criticism here is really that of the MP4 metadata themselves, specifically the lack of time-zone information. If you read the relevant part of the MPEG-4 standard that I referred to here: #408 (comment) ..you will see that the standard dictates that the timestamp in the metadata must be in UTC. So, if a user "corrects" the timestamp by compensating for the time-zone, he or she is really "corrupting" the information. I don't understand how Metadata-extractor could do anything other than "assume" that it's in UTC, since that's what it is by definition. The real problem is the lack of time-zone/geographical information in the MP4 metadata. |
Yes, I almost can't believe that they screwed that up. My camera knows what time it is, and my phone certainly does. Neither one has any problem recording the local time on a JPG. Standards-writing by committee. |
I browsed a bit in the standard, and it turns out it's more complicated. From what I understand, the current information is retrieved from the "Movie Header Box" (8.2.2) with code In addition, a whole host of other "boxes" can be included with further metadata in the So, it seems that there absolutely is support in the standard to store further information. The problem is that this seems to be optional, so one would need to figure out what information is "usually" available in actual encoder/muxer implementations. I don't know enough about MP4 to know this, but it might be that a "box" could be found where this information can usually be found. I don't think Metadata-extractor supports very many box types as of now though, I think only the "basic boxes" are implemented. So, if someone puts enough effort into researching this, it might turn out that there is a way one can, usually, figure out the time-zone. |
At a minimum, I'd suggest that a single format be adopted for the six common dates - BTW, I'm just using Drew's own script to extract this stuff - I'm not doing anything strange to the output:
|
This is where you apply the time-zone: printStream.println(tag) By not explicitly formatting it, and only using the implicit |
So why don't I see the same result with all 6 |
My guess is that there are some slight differences in the |
The MovieHeader tags have a bit more manipulation to them seen here:
#416 For some context |
@payton Indeed, it seems like this 1904 Epoch doesn't apply to for example the track header:
Still, as they are stored as |
@Nadahar Ah, yes, that too. There is also the media header box that may need to be changed
|
Actually, the track header seems like a bug to me. According to
This means that the same Epoc conversion should be applied there as well, AFAICU. |
@payton Maybe a search for Edit: The Epoc is the same for the MediaHeaderBox (8.4.2.3), and the same is probably true for all "standard" boxes where dates appear. |
@Nadahar I was just checking the documentation, too. Yeah, it seems like all dates should be formatted that way. |
@payton I'm not familiar enough with the logic for these directories, I see in For the |
@Nadahar I'm confusing myself, but it may be getting set properly here metadata-extractor/Source/com/drew/metadata/mp4/Mp4MediaHandler.java Lines 40 to 51 in ef906fb
This part gets a little more confusing because media boxes such as sound or video are all within the same "type" of box, so I introduced a context object to account for the current type of box being processed. I believe this should set all media type dates as we expect, so I'm not sure why we are seeing the difference that @EarlyOut pointed out. |
@payton I have a suspicion that the difference is in the code that generates |
@Nadahar Well, there is what's in the TagDescriptor class metadata-extractor/Source/com/drew/metadata/TagDescriptor.java Lines 83 to 88 in 81143f7
However, I don't believe I created any special descriptors for the creationDate/modificationDate since they were just set as dates. |
@payton That formatting looks suspect to me, what exactly does the replace do? This also goes back to the long-standing problem that |
With v2.13, the timestamps returned by M-E are better than they were, but are still a bit of a muddle.
Let's start with one important fact: AFAIK, there is only one piece of time information in the metadata of a standard MP4, and that's the time the video was created, in GMT. There is no localization information in the file.
Take an example: (file removed). The file name tells part of the story - July 22, 2017, at 13:36:49, local time. Summer in the Alps, so Central European time, daylight saving time in effect. But the only information in the metadata is the creation time in GMT: 2017:07:22 11:37:03 (it took the phone a few seconds to stash the video in its memory). That's the only number that is of any use to anyone.
But M-E is telling me the following (among other things):
[MP4] Creation Time - Sat Jul 22 07:37:03 EDT 2017
[MP4 Video] Creation Time - Sat Jul 22 07:37:03 -04:00 2017
[MP4 Sound] Creation Time - Sat Jul 22 07:37:03 -04:00 2017
It seems to think that the fact that I'm currently sitting in Connecticut (GMT-5, daylight time not in effect) is somehow relevant. But it's not. It would be like pulling the exposure time from a JPG, realizing that the user is currently traveling close to light speed, and telling him how to adjust for relativistic time dilation. It just doesn't matter - the only useful piece of information is the exposure time recorded by the camera. The same is true here - what time it was in Connecticut when that video was shot is a useless data point.
True, the application could derive the correct GMT timestamp from the information provided, but it shouldn't have to. M-E should be returning only the information it has:
[MP4] Creation Time - Sat Jul 22 11:37:03 2017
[MP4 Video] Creation Time - Sat Jul 22 11:37:03 2017
[MP4 Sound] Creation Time - Sat Jul 22 11:37:03 2017
Instead, it's trying to do me a "favor."
The text was updated successfully, but these errors were encountered: