[FFmpeg-devel] FFMPEG DLL proposal
Pierre Chatelier
ktd
Wed Jan 21 19:13:43 CET 2009
>> 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 :-)
More information about the ffmpeg-devel
mailing list