[Ffmpeg-devel] Shared Libraries

[charlie]

Hi all,

I am definitely not wanting to start a flamewar regarding the use of
shared objects as I'm well aware of the policy regarding this. 

However, I am just wondering if there is a particular reason why
libavformat.so links with libavcodec.so?

The reason I ask this is because I load all media libraries via a shared
object and I have wrappers that are linked as shared objects against
their libs (of which avformat is one). These get loaded the first time
an application requests handling of a particular file type or service.

AFAICT, it's not recommended to link static libs to my .so wrapper, and
if I push the ffmpeg libs statically to every application that uses my
library, the distribution size becomes unwieldy (to say the least...
there are quite a number of applications involved - from GUI NLE
applications, previewers, command line test tools, server applications,
script language bindings and others - an additional 3Meg per tool seems
rather excessive to me....).

So my work around is this - I have a private instance of ffmpeg and
instead of installing libavformat.so and libavcodec.so directly, I
install libmltavformat.so and libmltavcodec.so and link my wrapper to
these (thus, if the user installs normally from cvs or a release
version, there's no clash). 

But this fails simply because of the line in libavformat/Makefile which
reads:

AVCLIBS+=-lavcodec -L../libavcodec

With this line in place, my version of libmltavformat.so needs
libavcodec.so, so it doesn't matter how I install and link them (at
least on linux).

When I remove this, I can safely install the files as I need.

I also tend to stay pretty much lockstep with ffmpeg's API changes so I
don't see a particular reason to fork to satisfy this (and if I did, I
would miss out on the stuff you guys are working on - the recent
timestamp modifications are very much appreciated for example :-)).

My feeling is that a distributor could use this approach to create a
stable package which isn't going to break anything else... Taking this a
step further, they could even build a larger suite which also share this
particular build.

If need be, I'll just apply a patch to remove this line prior to the
build and all will be well on my test system, but maybe there's a reason
it's there (other than the obvious 'it simplifies linking with
libavformat')? Maybe there's a simpler mechanism than the one I'm
suggesting? 

I am open to any suggestions.

Cheers,

Charlie