When ffdshow tries to load ffmpeg.dll I get a message saying "Failed to load ffmpeg.dll"
Here is what I do: I download the current source code, I buid it (using rebuild_x86.bat). It builds perfectly and it creates the installer file. I run the installer file to install ffdshow. Then when an application loads ffdshow and tries to load ffmpeg.dll, I get an error message saying "Failed to load ffmpeg.dll". However the file ffmpeg.dll does exist.
When I debug ffdshow (under Visual Studio), it seems that this function:
Tdll(const char_t *dllName1,const Tconfig *config,bool explicitFullPath=false) {
in Tdll.h
has a problem at this line:
hdll=LoadLibrary(dllName3);
Indeed, LoadLibrary returns NULL and GetLastError() returns 998 (ERROR_NOACCESS).
And if I tell the debugger to catch the exceptions of type 0xC0000005 (Access violation), it says that there is one such exception when trying to load ffmpeg.dll with LoadLibrary.
A google search shows that lots of people experience a "Failed to load ffmpeg.dll" error message in the last months.
Does someone knows the cause of the problem and/or have a solution ? I precise that I don't have any other decoder installed (no k-lite codecs pack, no other ffdshow, etc…). I also put the path to ffmpeg.dll in the PATH environment variable. But I still have the problem.
And (this is is another problem) when ffmpeg.dll has not been loaded, there is a crash in Tconvert.cpp in function:
Tconvert::Tconvert(Tlibavcodec *Ilibavcodec, bool highQualityRGB, unsigned int Idx, unsigned int Idy, const TrgbPrimaries &IrgbPrimaries, int rgbInterlaceMode, bool dithering, bool isMPEG1):
TrgbPrimaries(IrgbPrimaries),
m_wasChange(false),
m_dstSize(0),
tmpcsp(0),
timer(L"color space conversion cost:")
at line:
init(Ilibavcodec,highQualityRGB,Idx,Idy,rgbInterlaceMode,dithering,isMPEG1);
I think it is due to the fact that first parameter Ilibavcodec is NULL.
As said before, ffmpeg.dll cannot be debugged step-by-step (or at least I don't know how) so I can't get into DLL's function init(…)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It says "c:\program files\ffdshow".
And when I debug ffdshow, in the constructor of Tdll, variable "dllName3" points to an existing file.
I really think that the DLL file is found, is open and that the problem comes from a memory exception (error code 998).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Delete the contents of the folder "obj" and then re-build. If the problem remains, you should try a different MinGW environment. We use this one: http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well… I deleted "trunk\obj" and rebuilt under MSYS (your version) with GCC 4.6.2 (your version).
It builds ffmpeg.dll without problem.
Then I re-registered ffdshow.ax (regsvr32 ffdshow.ax) but when I try to load ffdshow in GraphEdit, I still have the error message which says "Failed to load ffmpeg.dl".
I don't know what to try next.
Does someone have an idea ? Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any progress?
Which are you building x86 or x64?
Did you read this?
I would recommend to uninstall MSYS and mingw, and clean environment variables such as C_INCLUDE and LIBRARY_PATH.
Clean install of MSYS and migw from the link above should work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For some reason that I totally don't understand, it works now. I just did the same as before (deleting the obj folder, running rebuild_x86.bat with GCC 4.6.2).
Thanks for the help because I am not sure it would compile under GCC 4.6.2.
Now, I am facing the problem of debugging. Sometimes ffdshow crashes (with live RTP streams) and I cannot debug the crashed ffmpeg.dll so I am stuck on this point.
I guess the only solution would be to compile under MSVC (which seems impossible now) or under Code::Blocks (but I don't know if that's possible).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I didn't try this branch. Could you please explain me a bit more what this branch is?
Is it a better access unit parser or just a different one (which could also be worse than the "default" one) ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again for your help. Sorry for this late reply (I have been really busy these last days).
I tried to find this "parser branch" in the SVN but I can't find it. Could you please briefly explain me how to get this branch ?
I would also be interested to briefly know why this "parser branch" (and its "official AU parser of Libav") is better. So if you know why, could you please tell me more?
Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
parser branch has been integrated into trunk and deleted. All you have to do is "svn update".
If the upper stream filter used start code "00 00 01", ffdshow required access unit delimiter.
Access unit parsing was failing in that case. It was causing black screen.
Such issue has been fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you again for this fast reply.
I understand the new change but I don't think it will solve my problem because the problem I have is not when decoding starts.
My problem happens after several minutes (or even several hours) of decoding.
I perform RTP streaming with VLC, playing a TS file in loop and streaming it to a multicast address. Within another software (which creates a DirectShow graph and uses ffdshow), I receive the TS from multicast. Then the TS is demultiplexed and the video stream is decoded.
After a while (several minutes or several hours), the decoding stops (the image is frozen) or crashes (my application crashes, generally with memory access violation). Stopping and restarting the streaming in VLC doesn't solve the problem.
That's why I think that only "live debugging" could enable to find the line in the source code where the problems lies.
Kind regards,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ICL12 project files has been added to the latest SVN.
You need Intel Parallel Composer 2011 ($399 or 30 day evaluation) to use it.
Since GCC's inline asm is not supported by ICL, somewhat different code is used.
I cannot guarantee that you can reproduce the same issue you have in the debug builds.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When ffdshow tries to load ffmpeg.dll I get a message saying "Failed to load ffmpeg.dll"
Here is what I do: I download the current source code, I buid it (using rebuild_x86.bat). It builds perfectly and it creates the installer file. I run the installer file to install ffdshow. Then when an application loads ffdshow and tries to load ffmpeg.dll, I get an error message saying "Failed to load ffmpeg.dll". However the file ffmpeg.dll does exist.
When I debug ffdshow (under Visual Studio), it seems that this function:
Tdll(const char_t *dllName1,const Tconfig *config,bool explicitFullPath=false) {
in Tdll.h
has a problem at this line:
hdll=LoadLibrary(dllName3);
Indeed, LoadLibrary returns NULL and GetLastError() returns 998 (ERROR_NOACCESS).
And if I tell the debugger to catch the exceptions of type 0xC0000005 (Access violation), it says that there is one such exception when trying to load ffmpeg.dll with LoadLibrary.
A google search shows that lots of people experience a "Failed to load ffmpeg.dll" error message in the last months.
Does someone knows the cause of the problem and/or have a solution ? I precise that I don't have any other decoder installed (no k-lite codecs pack, no other ffdshow, etc…). I also put the path to ffmpeg.dll in the PATH environment variable. But I still have the problem.
And (this is is another problem) when ffmpeg.dll has not been loaded, there is a crash in Tconvert.cpp in function:
Tconvert::Tconvert(Tlibavcodec *Ilibavcodec, bool highQualityRGB, unsigned int Idx, unsigned int Idy, const TrgbPrimaries &IrgbPrimaries, int rgbInterlaceMode, bool dithering, bool isMPEG1):
TrgbPrimaries(IrgbPrimaries),
m_wasChange(false),
m_dstSize(0),
tmpcsp(0),
timer(L"color space conversion cost:")
at line:
init(Ilibavcodec,highQualityRGB,Idx,Idy,rgbInterlaceMode,dithering,isMPEG1);
I think it is due to the fact that first parameter Ilibavcodec is NULL.
As said before, ffmpeg.dll cannot be debugged step-by-step (or at least I don't know how) so I can't get into DLL's function init(…)
What does the dialog of ffdshow video decoder say in "Paths ffdshow:" in "Tray, dialog & paths"?
It says "c:\program files\ffdshow".
And when I debug ffdshow, in the constructor of Tdll, variable "dllName3" points to an existing file.
I really think that the DLL file is found, is open and that the problem comes from a memory exception (error code 998).
This can happen with a bad build of ffmpeg.dll
Delete the contents of the folder "obj" and then re-build. If the problem remains, you should try a different MinGW environment. We use this one: http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=
Thanks a lot for this quick reply.
a) When you say "the folder obj", you mean folder "trunk\obj" don't you?
Well… I deleted it then rebuilt using rebuild_x86.bat and it still seems that the DLL is badly made.
I already use MinGW version 4.6.1.
b) Do you think that using the same version as you (which seems to be 4.6.2) will fix the problem?
Well… I deleted "trunk\obj" and rebuilt under MSYS (your version) with GCC 4.6.2 (your version).
It builds ffmpeg.dll without problem.
Then I re-registered ffdshow.ax (regsvr32 ffdshow.ax) but when I try to load ffdshow in GraphEdit, I still have the error message which says "Failed to load ffmpeg.dl".
I don't know what to try next.
Does someone have an idea ? Thanks in advance.
Any progress?
Which are you building x86 or x64?
Did you read this?
I would recommend to uninstall MSYS and mingw, and clean environment variables such as C_INCLUDE and LIBRARY_PATH.
Clean install of MSYS and migw from the link above should work.
For some reason that I totally don't understand, it works now. I just did the same as before (deleting the obj folder, running rebuild_x86.bat with GCC 4.6.2).
Thanks for the help because I am not sure it would compile under GCC 4.6.2.
Now, I am facing the problem of debugging. Sometimes ffdshow crashes (with live RTP streams) and I cannot debug the crashed ffmpeg.dll so I am stuck on this point.
I guess the only solution would be to compile under MSVC (which seems impossible now) or under Code::Blocks (but I don't know if that's possible).
Did you try parser branch in the SVN?
The crash may be related to access unit parsing.
No, I didn't try this branch. Could you please explain me a bit more what this branch is?
Is it a better access unit parser or just a different one (which could also be worse than the "default" one) ?
> No, I didn't try this branch.
Does it take too long?
>Is it a better access unit parser or just a different one
It's an official access unit parser of Libav. It's better.
Hi h_yamagata,
Thanks again for your help. Sorry for this late reply (I have been really busy these last days).
I tried to find this "parser branch" in the SVN but I can't find it. Could you please briefly explain me how to get this branch ?
I would also be interested to briefly know why this "parser branch" (and its "official AU parser of Libav") is better. So if you know why, could you please tell me more?
Thanks in advance.
parser branch has been integrated into trunk and deleted. All you have to do is "svn update".
If the upper stream filter used start code "00 00 01", ffdshow required access unit delimiter.
Access unit parsing was failing in that case. It was causing black screen.
Such issue has been fixed.
Thank you again for this fast reply.
I understand the new change but I don't think it will solve my problem because the problem I have is not when decoding starts.
My problem happens after several minutes (or even several hours) of decoding.
I perform RTP streaming with VLC, playing a TS file in loop and streaming it to a multicast address. Within another software (which creates a DirectShow graph and uses ffdshow), I receive the TS from multicast. Then the TS is demultiplexed and the video stream is decoded.
After a while (several minutes or several hours), the decoding stops (the image is frozen) or crashes (my application crashes, generally with memory access violation). Stopping and restarting the streaming in VLC doesn't solve the problem.
That's why I think that only "live debugging" could enable to find the line in the source code where the problems lies.
Kind regards,
Thomas
ICL12 project files has been added to the latest SVN.
You need Intel Parallel Composer 2011 ($399 or 30 day evaluation) to use it.
Since GCC's inline asm is not supported by ICL, somewhat different code is used.
I cannot guarantee that you can reproduce the same issue you have in the debug builds.