On 30 October 2012 13:21, Alex Cohn <span dir="ltr"><<a href="mailto:alexcohn@netvision.net.il" target="_blank">alexcohn@netvision.net.il</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr"></p><div class="im">On 30 Oct 2012 15:01, "Mark Kenna" <<a href="mailto:mark.kenna@sureviewsystems.com" target="_blank">mark.kenna@sureviewsystems.com</a>> wrote:<br>
><br>
> On 30 October 2012 10:55, Mark Kenna <<a href="mailto:mark.kenna@sureviewsystems.com" target="_blank">mark.kenna@sureviewsystems.com</a>> wrote:<br>
>><br>
>> On 30 October 2012 10:51, Nicolas George <<a href="mailto:nicolas.george@normalesup.org" target="_blank">nicolas.george@normalesup.org</a>> wrote:<br>
>>><br>
>>> Le nonidi 9 brumaire, an CCXXI, Mark Kenna a écrit :<br>
>>> > I am trying to find a way of allowing my application to be able to load<br>
>>> > multiple versions of the FFMpeg DLL's at the same time.<br>
>>><br>
>>> Why would you want to do that?<br>
>>><br>
>>> The simplest solution to your problem is probably to find out how not to<br>
>>> need it.<br>
>>><br>
>>> Regards,<br>
>>><br>
>>> --<br>
>>>   Nicolas George<br>
>><br></div><div class="im">
>> I need to do that because we constantly find ourselves having FFMpeg-based modules which overwrite our .dll files with older versions causing serious crashing. I just need to be able to stop "drop-ins" from interfering with the version that we are running.<br>


>><br>
>> Thanks,<br>
>> Mark.<br>
>><br>
><br>
> I have also explored the option of statically linking the libraries but this is not possible in MSVC++ right? Surely there has to be a way to do this!<br>
><br>
> Mark.</div><p></p>
<p dir="ltr">Have you read a similar recent discussion on stackoverflow( <a href="http://stackoverflow.com/questions/11701635/use-ffmpeg-in-visual-studio" target="_blank">http://stackoverflow.com/questions/11701635/use-ffmpeg-in-visual-studio</a>)?</p>


<p dir="ltr">Today zeranoe archives include version number in the dll names. Are you using a different source of precompiled Windows binaries?</p>
<p dir="ltr">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.</p>


<p dir="ltr">BR,<br>
Alex<br>
</p>
<br>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><br>
<div>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). 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).</div>
<div><br></div><div>Thanks,</div><div>Mark.</div><div><br></div>