Wrong recognizing of Video recoring date (3gp)
Submitted by an unknown user
Assigned to Lucas Beeler
Link to original bug (#717384)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-03-09 15:34:00 -0800 ----
Original Redmine bug id: 3314
Original URL: http://redmine.yorba.org/issues/3314
Searchable id: yorba-bug-3314
Original author: over 2 years
Original description:
Hey there,
Videos, recorded by my HTC Desire, are always recognized as recorded in the year 1945.
This absolutely makes no sense, since pictures are recognized correctly.
The format of thos videos is 3gp.
If I can somehow help you, please comment.
What also'd be nice, is the option to edit the recording date etc manually, so the problem could be solved that way.
Thank you :)
Related issues:
- related to shotwell - 4166: [android] wrong date for video mp4 import from some Samsu... (Open)
- related to shotwell - 3300: use file mtime as timestamp if EXIF information missing (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:39:00 -0700 ----
History
Comment 1
Updated by Jim Nelson over 2 years ago
- Target version set to 0.9
- Priority set to High
Could you make the video available to us? If it's too large to attach to this ticket, please post it through a file sharing service so we can examine the metadata.
I should note that we've seen another camera record an improper timestamp in its movies. It may simply be a bug with the camera.
Comment 2
Updated by Anonymous over 2 years ago
So, just attached some videos and a picture.
I dont think the probleme is related to the camera (mobile phone), since the date is showed properly, clicking on details in the camera menu.
Comment 3
Updated by Adam Dingle over 2 years ago
- Status changed from Open to 5
- Resolution set to invalid
- % Done changed from 0 to 0
-
Target version deleted (
<strike>
_0.9_</strike>
)
The qtdump utility shows that the date/time embedded in these files appears to be 1945:
$ qtdump '/home/adam/Desktop/VID_20110310_110647.3gp' | strings | grep time
quicktime_dump
creation_time 1945-03-09 03:06:54 (1299751614)
modification_time 1945-03-09 03:06:54 (1299751614)
...
But perhaps the 3GP specification (which I haven't read) says that the creation/modification times in a 3GP file should be interpreted differently than in a!QuickTimefile. Or maybe this is a bug in your camera or its settings.
Comment 4
Updated by Adam Dingle over 2 years ago
I downloaded a sample 3GP from from HTC's own web site at http://masds03.htc.com.tw/sm/basictesting.htm and examined it with qtdump:
adam@natoma:~$ qtdump '/home/adam/Desktop/H264_15f_128k_5KF_qvga.3gp' | strings | grep time
quicktime_dump
creation_time 2006-11-06 22:20:42 (3245725242)
modification_time 2006-11-06 22:20:42 (3245725242)
That time looks normal. So it appears that 3GP files store their dates in the same way as other QuickTime-based files. I now think this is a bug in your camera or in the settings on it.
Comment 5
Updated by Anonymous over 2 years ago
Ok, thanks, think you're right. Will add a bug report to my ROM (Oxygen).
While its not supposed to be posted here, do somebody know how to edit this datum tag?
Comment 6
Updated by Adam Dingle over 2 years ago
Unfortunately you can't adjust the video's date/time in Shotwell yet -- see #3066 (closed). Hopefully for 0.10.
Comment 7
Updated by Abe Pazos over 2 years ago
- Description updated (diff)
- Priority changed from High to Normal
I'm having the same problem on my HTC Nexus One.
The video with a Modified date of Wed 20 Jul 2011 03:48:28 goes to the %(=Apple-style-span){=border-collapse: collapse; color: rgb(51, 51, 51); font- family: arial, sans-serif; font-size: 13px; }folder %%(=Apple-style-span ){=border-collapse: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; font-size: 13px; }/1945/07/19.%
It is possible that the date is incorrect inside the file, but I can think of an easy workaround: the exact date and time are part of the file name
p{=margin-top: 1em; margin-right: 1em; margin-bottom: 1em; margin-left: 1.6em; padding-top: 2px; padding-right: 2px; padding-bottom: 2px; padding-left: 0px; background-color: rgb(250, 250, 250); border-top-width: 1px; border-right- width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top- style: solid; border-right-style: solid; border-bottom-style: solid; border- left-style: solid; border-top-color: rgb(218, 218, 218); border-right-color: rgb(218, 218, 218); border-bottom-color: rgb(218, 218, 218); border-left- color: rgb(218, 218, 218); width: auto; overflow-x: auto; overflow-y: hidden; }.
VID_20110310_110647.3gp
So the problem could be solved in Shotwell, or wait for it to be fixed by Google / Android, which may take very long or never happen.
Is there any chance we could have the date being read from the file name or from the file creation date?
Comment 8
Updated by Thomas Novin over 2 years ago
That workaround doesn't work on my phone with the same problem. My video files are just called VIDEONNNN.3GP.
More details on my post to the ML here: http://lists.yorba.org/pipermail/shotwell/2011-July/002574.html
Comment 9
Updated by Abe Pazos over 2 years ago
I suggested "read from the file name or from the file creation date".
So we could say that if the exif date is previous to the invention of the digital camera, take the file creation date. Or?
Comment 10
Updated by Thomas Novin over 2 years ago
That would work, when you import the files from the phone they will under normal circumstances always have the correct date.
On 3gp-import:
if date.year = 1945 ; then use file date instead; fi
:)
Comment 11
Updated by Alexey Fisher over 2 years ago
I use HTC Desire and this bug do not affect me, my Timestamps are displayed correctly. The reason of this timestamp problem is an epoch problem. The time used in "brocken files" based on unix time, also seconds sinece 1970. The time in "correct files" based on Apple time since 1904. Looks like quictime/mp4/3gp files normally use 1904 epoch. To convert appletime to unixe time you need remove 2082844800 seconds, thes what libquictime and other apps doing.
Since this problemm exist i suggest to add epoch conversation, to "fix" this files.
Comment 12
Updated by Adam Dingle over 2 years ago
Abe and Thomas, could you each run the qtdump command on one of your video files to reveal the date/time stored inside it? You'll first need to install it on your machine (on Ubuntu, it lives in a package called quicktime-utils). Then run this:
$ qtdump <video-file-name>
| strings | grep time
And post the output here. Thanks!
Comment 13
Updated by Abe Pazos over 2 years ago
Here is the result: http://pastebin.com/yBm6AmDv
The correct date can be seen in the file name, which matches the file time stamp.
Comment 14
Updated by Alexey Fisher over 2 years ago
Abe Pazos wrote:
bq.
Here is the result: http://pastebin.com/yBm6AmDv
qtdump read:
creation_time 1945-04-06 17:28:19 (1302190099)
if you handle 1302190099 as unixtime (not appletime) and convert to human time:
date -u -d @1302190099
Do 7. Apr 15:28:19 UTC 2011
or: Do 7. Apr 17:28:19 CEST 2011
Sudennly i can't find what epoch 3gp/mp4 should use. If it is not defined, then we have a big problem.
Comment 15
Updated by Adam Dingle over 2 years ago
- Status changed from 5 to Open
- Priority changed from Normal to High
-
Resolution deleted (
<strike>
_invalid_</strike>
)
Hm - this is odd. It seems that several different cameras record a date of 1945 in 3GP videos. All these cameras are made by HTC. I think this is probably a bug in HTC's code. Nevertheless I'm reopening this since it seems to be affecting a number of Shotwell users and might be worth working around.
Comment 16
Updated by Thomas Novin over 2 years ago
I saw some post to the ML about someone with a Google Nexus that had the same problem. Although the phone is actually made by HTC aswell the SW is Google- only so I think there are other phones out there with the same problem, not just HTCs.
Comment 17
Updated by dave42 - over 1 year ago
- Description updated (diff)
I can confirm the same problem with my Nexus One and Nexus S. If the problem is on the device side, it's in Google's code.
Either way, it sure would be nice if Shotwell could handle this. There are a lot of Android users out there. It shouldn't be too hard to recognize these crazy dates and automatically correct them, should it?
Comment 18
Updated by Alexey Fisher over 1 year ago
Search by phone neame is not good. It is possible to fix it in firmware, and if it will be fixed say in CyanogenMod then we will get same problemm again. But some way to fix the date for old video will be good.
Comment 19
Updated by Alexey Fisher over 1 year ago
Just added report here:
http://code.google.com/p/cyanogenmod/issues/detail?id=5956
will see if we will get some response.
Comment 20
Updated by dave42 - about 1 year ago
Asking for a fix in cyanogenmod is a good thing, but it has some 3 million users, out of more than 600 million Android users today. So a fix there is only going to reach a tiny number of people. This bug (or unusual behaviour) exists in the base AOSP code, so it affects all Nexus devices, and any other devices where the manufacturer hasn't reimplemented this, which we know includes the massive selling Samsung Galaxy phones, too.
Wouldn't it make sense to help people out by recognizing and accommodating that bug in Shotwell? You wouldn't need to search by phone name. A simple sanity check on the value itself would suffice. For example, if the date is before January 1, 2000, make the adjustment. That would cover us off until 2066, which seems like long enough to be worth doing.
Why not do it?
Comment 21
Updated by Jim Nelson about 1 year ago
- Target version set to 0.14.0
dave42, we've considered this. It's possible the best solution here is to look for a sane date, and if not found, use the file's modification time. We'll see if we can get this in for 0.14.
Comment 22
Updated by Thomas Novin about 1 year ago
I have Android 4.1.2 (JB, CM10) and this is still a problem. So this will continue to be a problem with many (all?) Android-phones for many years to come.
Edit: The workaround in http://redmine.yorba.org/issues/4166#note-19 could probably be used to fix this for videos already imported. I will have a go at re-writing the script when and if I get the time.
Comment 23
Updated by dave42 - about 1 year ago
Jim,
Thanks for your willingness to try to fix this in 0.14.
I'd recommend not using the file's modification time, though. The metadata IS available. The problem is just that there are two ways to interpret it: seconds since 1904 or seconds since 1970. Fortunately, for a given value, only one of those interpretations makes sense for the next 50 years or so.
Comment 24
Updated by Jim Nelson about 1 year ago
I haven't looked at this bug in quite a while, so I might be mistaken here, but I thought the problem with HTG was not simply that the offset was different (I believe that's accounted for in the Quicktime metadata code), but that it was recording a bogus date outright.
Comment 25
Updated by dave42 - about 1 year ago
Jim,
The problem in AOSP that's reported to cyanogenmod (in comment 19 above) and that I've personally experienced in two different Nexus devices is just the offset. It looks to me that all of the comments on this bug are referring to the same issue: they're all reporting videos dated 1945 in 2011. That's off by 66 years, which is the difference between 1970 (unix) and 1904 (quicktime).
I don't see any sign of other problems reported in this bug.
Comment 26
Updated by Jim Nelson 11 months ago
- Category set to video
Comment 27
Updated by Jim Nelson 9 months ago
It doesn't look like this is getting fixed in the firmware and there's a lot of people being burned by this. We'll add a sanity check to Shotwell to detect old videos and correct them.
Comment 28
Updated by Jim Nelson 9 months ago
- Assignee set to Lucas Beeler
Comment 29
Updated by Lucas Beeler 9 months ago
- Status changed from Open to 5
Applied in changeset f6065c18.
Comment 30
Updated by Lucas Beeler 9 months ago
- Resolution set to fixed
Comment 31
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:51 UTC ---
This bug was previously known as bug 3314 at http://redmine.yorba.org/show_bug.cgi?id=3314 Imported an attachment (id=261974) Imported an attachment (id=261975) Imported an attachment (id=261976) Imported an attachment (id=261977) Imported an attachment (id=261978)
Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.14.0
Resolution: RESOLVED FIXED