jdzyzh / mp4v2

Automatically exported from code.google.com/p/mp4v2
Other
0 stars 0 forks source link

MP4ConvertTime problems with not integer divisible timescale. #6

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
MP4ConvertTime() does not correctly handle the case when two timescale are not 
divisible in 
integer, and returns wrong duration. This causes QuickTime to read the track 
with a shorter length.

Original issue reported on code.google.com by damiog on 5 Dec 2008 at 3:43

GoogleCodeExporter commented 8 years ago
Please provide a short code-snippet which shows 2 cases; one where 
MP4ConvertTime() works as intended, and 
one where it returns wrong duration.

Original comment by Kona8l...@gmail.com on 8 Dec 2008 at 10:34

GoogleCodeExporter commented 8 years ago
For example: MP4ConvertTime(5618688, 48000, 600) returns 65844, while a correct 
value would be ~70234.

MP4ConvertTime(1000, 48000, 24000); works as advertised instead.

Well it seems the problem is that using integer to do this calculation may 
result in some approximation, I don't 
think it would do any harm to use float for everything.

Original comment by damiog on 8 Dec 2008 at 11:37

GoogleCodeExporter commented 8 years ago
I do not get the results you list -- how can you get negative; it's an unsigned 
64-bit int. Need more information, 
maybe it's your platform or compiler. The results I got are 70233 which is 
correct.

This would probably be easier if you dropped by IRC.freenode.net channel #mp4v2 
.

Original comment by Kona8l...@gmail.com on 8 Dec 2008 at 12:12

GoogleCodeExporter commented 8 years ago
Woops sorry, yes MP4ConvertTime is working fine, the bugs must be somewhere 
else. I'll try to track it down.
Btw I am not getting a negative number, but a smaller number. It was a tilde 
(~) not a - ;)

Original comment by damiog on 8 Dec 2008 at 1:49

GoogleCodeExporter commented 8 years ago
The problem was in void MP4Track::UpdateDurations(MP4Duration duration). It was 
transforming the duration of 
each sample to the new timescale and then it added it to the track duration. 
This was introducing a small 
conversion error for each sample that was accumulated over time. I fixed it by 
calculating a new media duration 
from the track duration.

Original comment by damiog on 8 Dec 2008 at 2:51

Attachments:

GoogleCodeExporter commented 8 years ago
patch applied to trunk@195

Original comment by Kona8l...@gmail.com on 24 Dec 2008 at 9:30

GoogleCodeExporter commented 8 years ago

Original comment by Kona8l...@gmail.com on 24 Dec 2008 at 9:30