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

[Nicolas George]

Vittorio Giovara (12020-03-02):
> > You seem to have some basic misconceptions about how linking works,
> > which result in completely incorrect conclusions. Let me elaborate.
> I'd appreciate if we could keep the conversation cordial, rather than
> throwing assumptions on people.
> This is a pretty hard start, and I will not continue on this thread if this
> is the tone going forward.

My point was mostly a technical statement on your technical statement,
it was not less cordial than "missing error check" in a patch review.

I grant you, the first line was more personal, but it was meant
helpfully. I am professionally trained in guessing the invalid
assumptions that cause people to make errors. I was trying to not only
tell you that you are mistaken, but also emit an hypothesis about why
you are, so that you can remedy it if you want. It was not in any way a
statement on your self: a statement on somebody's knowledge, even
hypothetical, does not reflect on their person.

> First of all the "size" of any code is pretty much the least important
> aspect of development, unless we're talking the embedded world or assembly
> optimizations.

Then what is the problem you see with "monsterlibraries"?

> That does not mean one should be allowed to make the code purposely larger
> for no gain: so far I haven't heard any good motive for merging the
> libraries together,

A good motive has been given: making the avpriv mess really private and
eliminating the ABI compatibility problems it causes.

By the way, since you brought up the question of cordiality, I want to
says that acting as if I did not already point it to you feels quite
rude to me.

> while the ones for splitting them even more are pretty evident.

A few days ago, I have asked you to explicit them, and you did not. I
have given a lot of thought to the question, and the conclusion was that
the evidences were actually false evidences.

So, I ask again: if the benefits of splitting the library are evident to
you, please explain them to me.

Note that I will not hesitate to shoot down your arguments if they are
not technically sound. I suggest you take the little time needed to
check them instead of wasting more of your time arguing with me.

> > 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.
> In a perfect world, sure, but that is not the case. To my knowledge most
> compilers do not perform such pervasive code elimination, unless when
> configured with extremely obscure parameters. This presentation seems to
> illustrate the problem well
> https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf

This is not what I was talking about. What I was explaining to you is
the behavior of linkers since decades; this is about going even further.

Just test this:

#include <stdio.h>
#include <libavutil/avutil.h>
int main(void) {
    printf("%x\n", avutil_version());
}   

Compile this, link it statically with ALL the FFmpeg libraries, and tell
us how much of libavcodec it embeds.

> > But the "leak" is only a problem because the libraries are separate.
> No, it was a problem from a design point of view, there are different
> libraries dedicated to different things, merging everything together serves
> no purpose,

Already told you twice: it serves the purpose of making maintenance of
cross-library code easier. Please don't make me say it a fourth time.

>	      while separating them a bit more, would introduce new
> functionality and features in the project.

What new functionality and features? Anything that can be done with
split libraries can be made with one.

> > 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.
> This is very very anecdotal. Besides, you don't know how a library will be
> used by the application, I believe you'd be surprised.

We are talking about private APIs, there is no application, only our own
code.

That's the point: having several libraries forces us to make public
things that should be private.

> > 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.
> Well by that reasoning, why isn't everything compiled in-kernel? After all
> we're just wasting precious user memory when everything could run from
> kernel space right?
> Maybe encoding and decoding could go 1% faster!!!

I hope you can realize by yourself how irrelevant this argument is here.

> Whether you like it or not, there is value in designing separate tools and
> implementing separate tools and libraries for different use cases: even
> though the ffmpeg suite of library is closed together because they pertain
> the same subject (multimedia) it makes a lot of sense to keep them separate
> and try to identify portions of code that could work well enough in a
> library separated from the rest.

"It makes a lot of sense": well, tell us. Give us actual technical
arguments.

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/20200303/c957be4a/attachment.sig>