apachisundari / mp4v2

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

mp4track changes fail on MP4 files >2 GByte on Certain Systems #124

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Pull r479 source from server to ReadyNAS Ultra (running Linux on Intel® 
Pentium Dual-core CPU)
2. Compile sources according to instructions
3. Use mp4track to enable/disable certain audio tracks on long list of files

What is the expected output? What do you see instead?
I just ran an auto-generated script to disable all but to the primary audio 
track on a list of a few hundred mp4s (stupid Apple iTunes/iPod/iWhatever will 
play *all* audio tracks unless you disable them, spoiling the experience for 
the kids with director voiceovers in alternate tracks--other software/hardware 
allows you just to select one track to play).

It worked fine on almost all files.  On a handful of files I got error messages 
that tracks could not be enabled/disabled.  The set of these files corresponds 
exactly to the files larger than 2 GBytes (mostly HD encodes, but smaller HD 
encodes worked fine).

What version of the product are you using? On what operating system?
See above.

Please provide any additional information below.
Looks like ye-olde signed-32-bit-int lseek bug.  Any way around that on a 
32-bit Linux as that ReadyNAS appears to be running?

Original issue reported on code.google.com by CarlEd...@gmail.com on 13 Nov 2011 at 2:45

GoogleCodeExporter commented 9 years ago
any wan you can provide a small program and file that reproduces the bug?

Original comment by jnor...@logitech.com on 28 Nov 2011 at 6:40

GoogleCodeExporter commented 9 years ago
There's the rub... a small program is easy, mp4track and I suspect most other 
mp4v2 tools provide examples.  But as the bug manifests itself exclusively on 
mp4 files larger than 2 GByte (and not on all architectures), providing an 
example file is well-nigh impossible.  

Perhaps a simple grep on use of lseek (rather than lseek64) on 32-bit 
architectures would uncover the problem?

Original comment by CarlEd...@gmail.com on 28 Nov 2011 at 8:01