[FFmpeg-devel] Splitting or merging libraries (was: Status and Plans for Subtitle Filters)

[Nicolas George]

Vittorio Giovara (12020-02-28):
> err a monsterlibrary is a monsterlibrary regardless of how it is linked,
> and it's good that you mention static linking since that would be one of
> the best reason to keep library separated

You seem to have some basic misconceptions about how linking works,
which result in completely incorrect conclusions. Let me elaborate.

First, if you take a monsterlibrary and configure it with
--disable-everything --enable-what-you-need, you get a tiny library.
Therefore, the maximum size of the library is not an issue for the
people who ship their own.

For static linking, it's even simpler. Static linking does not copy the
whole library, the linker only picks the object files it needs based on
the symbols the application uses. You can have a monsterlibrary; you can
have ten extra useless monsterlibraries, it will change nothing: the
resulting binary will contain exactly the code it needs.

For dynamic linking, there is an initial global phase of resolving
symbols, that depends on the amount of symbols the application actually
needs. Then the code is loaded on demand.

Overall, "monterlibraries" are not the problem you think they are.
Therefore, I suggest you revise your objections about them.

> err^2 wouldn't we want to change that? There are plenty of good APIs that
> could be used in the wild, but aren't because ffmpeg is a huge dependency
> in any project.

The reason people don't use our libraries for non-multimedia programs is
not the size of the library. It is in part because of the reputation:
they are multimedia libraries, there is no reason to use them for
something else.

And the other part is that our non-multimedia are pedestrian,
inefficient and poorly designed. When we'll malloc() frames with
thousands of pixels, we don't cringe at malloc()ing a six chars string.
We have a terrible and ugly logging infrastructure that can cause
unwanted noise. Etc.

Until that changes, considerations about the size of the libraries are
irrelevant when it comes to their adoption by non-multimedia projects.

And remember, we are not a commercial project: we have no urge to create
needs to gain market share.

> There are plenty of example in which imposing constraints on the code or
> language forces developers to write better code.

And there are plenty of examples where arbitrary constraints lead to
worse code.

> For example splitting the libraries would make sure that a private header
> does not "leak" to a dependent library, like in a patch that was published
> a few days ago.

But the "leak" is only a problem because the libraries are separate.

The fact is, we develop these libraries as a whole. Codecs, muxers and
filters are often written by the same person and use the same tables and
small utility functions. These are functions that are too specific and
anecdotal to be public functions. We can update them easily, including
their prototype, because they are used only at two or three places in
code we know.

If we stopped caring about separate libraries, we would just name them
ff_someobscurecodec_get_random_info() and call them whenever necessary.
But because people insist on split libraries, we have to jump hoops and
waste effort.

> Hard disagree on that one, but also quite off-topic, let's get back on
> subtitles.

This is an important discussion too. I changed the subject for people
who want to track accurately.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200301/ab6cbdc3/attachment.sig>