Have you read a similar recent discussion on stackoverflow(
http://stackoverflow.com/questions/11701635/use-ffmpeg-in-visual-studio)?
Today zeranoe archives include version number in the dll names. Are you
using a different source of precompiled Windows binaries?
Anyway, it's good practise to install the DLLs in your app directory, next
to the executable that will load them, and not in a shared directory where
other applications could override them or be hit because your installation
overwrought the files they relied upon.
BR,
Alex
I've seen that link, it describes how to dynamically link rather than
statically link. Also, some of the file name's in the automated builds are
not incremented so older version will break them (swscale for example).
Fair enough.
Statically linking so that I no longer require the .dll files at runtime
would solve my issue, the other alternative is to try and change the PE to
reference modified filenames (which is crazy).
The other alternative is to deploy your preferred versions of the
dynamic libraries to a private directory of your application. Unlike
Unix, you are guaranteed that the system loader will prefer to pick up
the DLL files that are in the same directory as the executable that
needs them.
I had to go round and round with this a few times. A static link would be best but as I undertand it, it may not work. I have not
tried it personally and you can find some info about that on zeranoe. Outside of ffmpeg I static link other libraries. If someone is
successful static linking using ffmpeg under windows and using MSVC please let us know.
o - it's not always possible to put the dlls in the same place as the application. This has to do with the application might be a
dll and being used as a plugin. Then the calling application will also think the ffmpeg dlls should also be listed as plugins.
o - I created a utility that will rename the dll's and all refereneces in the lib and dll's. Beware of the rules for renaming the
ffmpeg dll's. This is useful if the names of ffmpeg dlls change and you don't want to build acummulation of old dlls. Also useful if
you want to indentify the ffmpeg dlls are part of your app. The utility is something thats a raw development tool and not intended
to hand out but email me on it if interested.
o - If you can't put the dll's in the same directory as the application for some reason, then use a subdirectory or some specific
application directory. In this case you can use LoadLibrary but beware loading all the ffmpeg functions can eat memory and so best
to use some kind of thunk for it. An alternative is to use an interface dll which you do a LoadLibrary on that links to the ffmpeg
dlls. Now before you to do LoadLibrary on interface DLL, add to the DLL search order by calling SetDLLDirectory.
You can also try using delay loading which gives you the oportunity to change
on the fly, where to look for your dlls.
http://msdn.microsoft.com/en-us/library/151kt790.aspx
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
