I've found that a particular MP4 file will open just fine with the MediaInfo GUI. However, when you try to open it with the MediaInfoDLL_0.7.1.2_Win32 DLL in C# using an extern call, it generates a null reference exception, and the MediaInfo_Open call is wedged after that; additional calls to MediaInfo_Open will hang, but other MediaInfo calls continue to respond.
I copy the DLL to my bin directory, and I have [DllImport] directives to import the functions, e.g.:
[DllImport("MediaInfo.dll")]private static extern int MediaInfo_Open(IntPtr Handle, [MarshalAs(UnmanagedType.LPWStr)] string FileName);
But the following C# code blows up:
private void test()
{
string check = MediaInfo_Option((IntPtr) 0, "Info_Version", version + ";ACE;" + version);
if (check == null || check.Length == 0)
{
throw new Exception("Installed MediaInfo.DLL version is not compatible with " + version);
}
handle = MediaInfo_New();
MediaInfo_Option(handle, "Internet", "No");
MediaInfo_Open(handle, "0.mp4")
}
When you run it on the test file, you'll get a NullReferenceException, somewhere down deep in the DLL.
After the null reference, MediaInfo_Open stops responding; you can try doing a MediaInfo_Close call, and that returns, but when you call MediaInfo_Open on a different file, the call appears to hang.
This call does work on other files that I've tried (AVI, MPEG, other MP4 files); but this one kills it.
If you have any insight, I'd love to hear it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
* Surprising that there is no crash with your file. At home, this crashes ;-)
* your file is not a MP4 file, but a Apple Quicktime file (there is no MPEG-4 header). if you rename it in .mov, this will work (but with strange behaviour, i must work on it. What is the software used to create this? What is it exactly? If you have other files like this, I am interested)
* the library I use for MP4 parsing seems to be a lot buggy when used with other things than MPEG-4... You are the second person to have crash with it. I think I will develop my own parser...
So, I think I will change quickly the parsing order, to not have crash. Later, I will work to have correct results with this kind of file.
If you have more example files, I am interested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. The header starts with HEX 00 00 87 74 6D 6F 6F
this is rather a type of .mov NOT an .mp4 header.
2. The Object Descriptors & Binary Format for Scenes tracks are located BEFORE the 2 Video and Audio streams
please check here: http://www.erightsoft.com/MediaInfo/before.gif
After correcting the header to read an ISMA MP4 and swapping the Object Descriptors & Binary Format for Scenes tracks by putting them AFTER the the Video and Audio streams, the file is perfectly detected by MediaInfo
please check here: http://www.erightsoft.com/MediaInfo/after.gif
You may download the corrected file and try it http://www.erightsoft.com/MediaInfo/10.mp4
Conclusion: IMHO, the file was created "handmade"
using mp4box or similar, the user didn't realize how to create correctly a valid mp4 file.
thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why did you say that the header HEX 00 00 87 74 6D 6F 6F is not MP4 nor MOV?
For me, this is a standart Atom (4 first bytes are the size, 4 next byte syas "moov" atom, as in MOV files or MP4 files, except for MP4 files there is not the "ftyp" atom)?
In all case, I don't like to crash MediaInfo, so I will modify it... And keep out the used mp4 library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the analysis. I don't know the provenance of this file; I believe I grabbed it off the Internet a few months ago, but I didn't author it.
My project has to handle arbitrary files thrown at it, however, and it runs in an unattended mode, so what I was really hoping to address was the hanging behavior.
It's fine if the attempt to verify the file tosses exceptions, throws sparks, etc.; for most verifiers, I capture a bad file, and just leave the metadata for the file blank.
But what I'm seeing with MediaInfo is the call gets wedged after the NPE thrown during the verification attempt, and all subsequent threads that try to verify different files hang on the "Open" call, until I run out of threads.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We work for the same goal : unattended mode ;-)
I already added exception handles around the DLL, but it does not work in this case.
The problem is that it is not my code which have a problem in your case, but a third-party library, mpeg4ip. You have a problem with a third-party library, I have this problem too ;-)
I see that mpeg4ip is not protected against malformed files.
I plan to create my own code for MP4/MOV parsing, to avoid this library.
But this takes a long time, and I will not be able to do this for the next release.
I will only add some workarounds for this case, but not a 100% safe method.
And later, I will change the code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've found that a particular MP4 file will open just fine with the MediaInfo GUI. However, when you try to open it with the MediaInfoDLL_0.7.1.2_Win32 DLL in C# using an extern call, it generates a null reference exception, and the MediaInfo_Open call is wedged after that; additional calls to MediaInfo_Open will hang, but other MediaInfo calls continue to respond.
Here's a link to the test file:
http://release.theplatform.com/content.select?pid=E1zN8Mz2sQVFC01hIIZZKTaklKPALUeo&UserName=SourceForge
It doesn't seem to be corrupted.
I copy the DLL to my bin directory, and I have [DllImport] directives to import the functions, e.g.:
[DllImport("MediaInfo.dll")]private static extern int MediaInfo_Open(IntPtr Handle, [MarshalAs(UnmanagedType.LPWStr)] string FileName);
But the following C# code blows up:
private void test()
{
string check = MediaInfo_Option((IntPtr) 0, "Info_Version", version + ";ACE;" + version);
if (check == null || check.Length == 0)
{
throw new Exception("Installed MediaInfo.DLL version is not compatible with " + version);
}
handle = MediaInfo_New();
MediaInfo_Option(handle, "Internet", "No");
MediaInfo_Open(handle, "0.mp4")
}
When you run it on the test file, you'll get a NullReferenceException, somewhere down deep in the DLL.
After the null reference, MediaInfo_Open stops responding; you can try doing a MediaInfo_Close call, and that returns, but when you call MediaInfo_Open on a different file, the call appears to hang.
This call does work on other files that I've tried (AVI, MPEG, other MP4 files); but this one kills it.
If you have any insight, I'd love to hear it.
* Surprising that there is no crash with your file. At home, this crashes ;-)
* your file is not a MP4 file, but a Apple Quicktime file (there is no MPEG-4 header). if you rename it in .mov, this will work (but with strange behaviour, i must work on it. What is the software used to create this? What is it exactly? If you have other files like this, I am interested)
* the library I use for MP4 parsing seems to be a lot buggy when used with other things than MPEG-4... You are the second person to have crash with it. I think I will develop my own parser...
So, I think I will change quickly the parsing order, to not have crash. Later, I will work to have correct results with this kind of file.
If you have more example files, I am interested.
1. The header starts with HEX 00 00 87 74 6D 6F 6F
this is rather a type of .mov NOT an .mp4 header.
2. The Object Descriptors & Binary Format for Scenes tracks are located BEFORE the 2 Video and Audio streams
please check here:
http://www.erightsoft.com/MediaInfo/before.gif
After correcting the header to read an ISMA MP4 and swapping the Object Descriptors & Binary Format for Scenes tracks by putting them AFTER the the Video and Audio streams, the file is perfectly detected by MediaInfo
please check here:
http://www.erightsoft.com/MediaInfo/after.gif
You may download the corrected file and try it
http://www.erightsoft.com/MediaInfo/10.mp4
Conclusion: IMHO, the file was created "handmade"
using mp4box or similar, the user didn't realize how to create correctly a valid mp4 file.
thank you
Why did you say that the header HEX 00 00 87 74 6D 6F 6F is not MP4 nor MOV?
For me, this is a standart Atom (4 first bytes are the size, 4 next byte syas "moov" atom, as in MOV files or MP4 files, except for MP4 files there is not the "ftyp" atom)?
In all case, I don't like to crash MediaInfo, so I will modify it... And keep out the used mp4 library.
There's a mis-understanding, here's what i said:
it is rather a type of .mov
NOT an .mp4 header
I see it more as a MOV file than as an MP4
that's all.
Thanks for the analysis. I don't know the provenance of this file; I believe I grabbed it off the Internet a few months ago, but I didn't author it.
My project has to handle arbitrary files thrown at it, however, and it runs in an unattended mode, so what I was really hoping to address was the hanging behavior.
It's fine if the attempt to verify the file tosses exceptions, throws sparks, etc.; for most verifiers, I capture a bad file, and just leave the metadata for the file blank.
But what I'm seeing with MediaInfo is the call gets wedged after the NPE thrown during the verification attempt, and all subsequent threads that try to verify different files hang on the "Open" call, until I run out of threads.
We work for the same goal : unattended mode ;-)
I already added exception handles around the DLL, but it does not work in this case.
The problem is that it is not my code which have a problem in your case, but a third-party library, mpeg4ip. You have a problem with a third-party library, I have this problem too ;-)
I see that mpeg4ip is not protected against malformed files.
I plan to create my own code for MP4/MOV parsing, to avoid this library.
But this takes a long time, and I will not be able to do this for the next release.
I will only add some workarounds for this case, but not a 100% safe method.
And later, I will change the code.