mp4trackdump: fix for integer underflow in display sample times

[GoogleCodeExporter]

In release 1.9.1 (Ubuntu 11.04 64bit) mp4trackdump outputs very strange time 
stamps. Something like this:

./mp4trackdump version 1.9.1
mp4file video.mp4, track 1, samples 42, timescale 48000
sampleId      1, size   499 duration     2048 time        0 00:00:00.000 S
sampleId      2, size   472 duration     2048 time     2048 00:00:00.042 S
sampleId      3, size   458 duration     2048 time     4096 
00:1000:18446744073649551.701 S
sampleId      4, size   466 duration     2048 time     6144 
00:2000:18446744073589551.744 S
...

This was caused by an integer underflow in util/mp4trackdump.cpp. There 
expressions like "UINT64_C( 3600 * 1000 )" where used to calculate the display 
time. However the UINT64_C macro only seems to work with number literals. At 
least this is what the man page says. I fixed it by replacing the expression 
with a proper literal like "UINT64_C( 3600000 )". It's not as nice but avoids 
the underflows.

After that fix proper sample times were displayed:

./mp4trackdump version 1.9.1
mp4file video.mp4, track 1, samples 42, timescale 48000
sampleId      1, size   499 duration     2048 time        0 00:00:00.000 S
sampleId      2, size   472 duration     2048 time     2048 00:00:00.042 S
sampleId      3, size   458 duration     2048 time     4096 00:00:00.085 S
sampleId      4, size   466 duration     2048 time     6144 00:00:00.128 S
...

The output of svn diff is attached below. Just 4 lines are affected.

Original issue reported on code.google.com by stephan....@helionweb.de on 13 Jul 2011 at 8:27

Attachments:

• fixed_display_time.diff

[GoogleCodeExporter]

Ah, thanks.  Yeah, that is definitely invalid for the UINT64_C macro:  

#define UINT64_C(x)  x ## ULL

...it'll basically end up looking like "3600 * 1000 ULL", which is flat out 
wrong...also sort of insidious because it avoids static code analysis (at least 
the stuff I do have).

I also fixed a similar issue in one other place in code, and checked to see if 
any of the other similar macro calls were in error as well..

This will get fixed in trunk; I'm probably not going to be doing a fix in the 
1.9.1 branch because I haven't been doing as good of a job migrating stuff from 
trunk to the branches as I should have.  Sorry.  I'd use trunk (r482) to get 
the fix, or wait for the 2.0 release.

Original comment by kid...@gmail.com on 13 Jul 2011 at 9:02

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for your fast response. I will check out trunk as soon as I can. :)

Original comment by stephan....@helionweb.de on 14 Jul 2011 at 11:40