[FFmpeg-devel] FFMPEG DLL proposal

[Pierre Chatelier]

>> A dependency to an external exe is less practical than a shared  
>> library resolution.
> Why?
Let's consider I have a "main application" that plans to use ffmpeg  
under the hood

With a library :
-Propagating context information, and errors values/messages/ 
diagnostics are easier in the shared memory space than through  
system() calls.
-The main application won't launch if the shared library is not  
present; otherwise, tests must be made with the exe being present and  
flagged executable.
-If the exe happens to be deleted/corrupted, it must be reinstalled by  
the application itself; so one should consider installing the exe by  
extracting it from the application's resources at run-time. (And  
manage user permissions for that, and handle errors). That's more work.
-if we want the shared library to be part of "main application" and  
not shared with others, it could apply to code-signing and prevent the  
main application to launch if it has been changed.
-batch processing is easier/more efficient for a bunch of very little  
tasks.
-debugging can explore the library itself

I am not sure to convince you, but these are some points that sound  
important to me. And it's just one or two hours to remove static  
variables of ffmpeg.c and cmdutils. The point I could not solve was  
building the library in the FFMpeg config/Makefile architecture, which  
is difficult (for me) to tune.

Regards,

Pierre Chatelier

PS : Once again, I can cope with the exe if it is the last resort :-)