MP4TextAtom::Read fails in MP4Atom::ReadProperties

[GoogleCodeExporter]

I have a user with a movie file that he used EncodeHD on (not sure that's the 
culprit, but it is the only unknown).  It will add with iTunes and can be read 
by AtomicParsley, but libmp4v2 dies trying to read it.  I've debugged it down 
to it having a text atom in trak->mdia->minf->stbl->stsd.

When MP4TextAtom:Read is called, it calls AddPropertiesStsdType and adds 19 
properties. But when MP4AtomRead is called, on the 3rd property it shows past 
the end of the file, and then throws an exception.  Now if I comment out the 
exception and just return, it works on this particular file, but obviously 
there's something else going on.

Any help would be appreciated.

Dan

Original issue reported on code.google.com by danahins...@gmail.com on 18 Mar 2012 at 10:51

[GoogleCodeExporter]

is there any way to make that file available so I can debug through it?

Original comment by kid...@gmail.com on 20 May 2012 at 8:06

[GoogleCodeExporter]

I've collected several files that get corrupted when tagged with:

mp4tags -a "artist"

They're in http://www.danhinsley.com/downloads/MP4V2 Test Data.

For each file there's the untagged, uncorrupted file, a corresponding .dmp that 
is the output of

mp4file --dump

And there's a file error.txt which shows the output of the mp4tags command.

So clearly there are some internal flaws with these (one clear offender is the 
Hauppauge video capture app, which created a couple of them), however, you can 
use Freemake to "convert" the file (mp4 to mp4) and then they can be tagged 
correctly.

So whatever is wrong with the files, media players and Freemake handle, but 
MP4V2 doesn't.

Anything I can do to help figure this out, I'd be glad to do.

Dan

Original comment by danahins...@gmail.com on 22 Nov 2012 at 10:17

[GoogleCodeExporter]

Another user, another corrupted file.  Any way this item could be moved to the 
top of the queue.  I really hate corrupting user's files, but trying to debug 
this myself, I just don't know enough about the internal workings of the 
library to see where the problem is.  I think it has something to do with a 
section having a bad size, that is bigger than the file.

Dan

Original comment by danahins...@gmail.com on 29 Jan 2013 at 8:23

• Added labels: Priority-High
• Removed labels: Priority-Medium