Not calling MP4Close after MP4Modify corrupts an m4a file

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Download a sample m4a file such as
http://www.online.uillinois.edu/oakley/mp3/SteveJobs.m4a
2. Create a simple program that only calls MP4Modify on the file, without
calling MP4Close, and run it.

What is the expected output? What do you see instead?

After running the test program, the file should still be intact and
playable. However, the file will have become corrupted and can't even be
played anymore. Subsequent calls to MP4Modify on the file will fail too.

It doesn't make sense that calling a close function is required to keep the
file intact. A common close function should just do some cleanup, such as
closing the opened file and freeing up resources. If, for example, an
exception or crash would occur before the call to MP4Close, then this would
have the undesirable side effect that the opened file has become corrupted.

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

Revision 369 on Windows XP SP3.

Please provide any additional information below.

Using Visual Studio 2008 Professional to compile, in the 'Release Static'
configuration.

Original issue reported on code.google.com by tdebaets on 20 Aug 2009 at 6:55

[GoogleCodeExporter]

this is not a bug. documentation states that MP4Close writes out any pending 
changes.
You want this behavior to prevent unnecessary writes while the file is being 
changed.

Original comment by brand...@gmail.com on 15 Sep 2009 at 2:40

[GoogleCodeExporter]

I don't possibly see how that's a desirable behavior, and if what you're saying 
is
true, then forgetting to call MP4Close shouldn't corrupt the file.  I concur 
with the
OP; it seems like an obvious bug.

Original comment by kid...@gmail.com on 15 Sep 2009 at 4:31

[GoogleCodeExporter]

This seems like a pretty serious issue to me, yet there has been no news for 
almost a year. Are there any plans to fix this?

I could still easily reproduce this with the newest r390 revision. The link to 
the sample M4A file in my previous post is dead, but it seems to apply to all 
M4A files (and probably even to all MPEG-4 files), so that doesn't really 
matter.

Original comment by tdebaets on 26 Jul 2010 at 7:51

[GoogleCodeExporter]

tdebaets,

It does seem like a serious issue, and I'll try to look into it when I get 
time.  If you can, any debugging you could do on your end would help me isolate 
where the problem is.

Thanks

Original comment by kid...@gmail.com on 26 Jul 2010 at 8:13

[GoogleCodeExporter]

I'm afraid that the next 2 months will be too busy for me to do any serious 
debugging myself. Also, without any knowledge of the MPEG-4 format or the mp4v2 
code, it will be hard for me to know where to start. But if you want me to just 
quickly check some things, you can usually find me in #mp4v2 on freenode.

Original comment by tdebaets on 27 Jul 2010 at 12:45

[GoogleCodeExporter]

still a problem. another nice example is calling the unimplemented mp4subtitle 
--import routine, which begins by calling MP4Modify. it realizes it has no idea 
what to do next, quits, and leaves your file ruined.

Original comment by aaron.da...@gmail.com on 1 Jan 2013 at 8:41