[FFmpeg-devel] [PATCH] Merge libavcore into libavutil

[Alexander Strasser]

Hi

Luca Barbato wrote:
> On 02/14/2011 01:15 AM, Alexander Strasser wrote:
> >   The first library mentioned is lavc and the split library is lavu.
> > So as you can conclude for yourself there is at least one application
> > that depends only on lavu but not necessarily on lavc. Finding out the
> > name of that application is left as an exercise to the reader.
> 
> The readers couldn't find it so far... That's one of the requests that
> cropped up and had been deserted...

  That application is MPlayer.

> Beside that, could you tell me which are the content of libavutils that
> are useful for your application? My ideal usage for libavutils would be
> as replacement of glib or eina, Reimar's is as replacement of libcrypto.

  Sorry I am not 100% sure I understood your question correctly. I will
from here on assume with "useful for your application?" you meant thoughts
on usage of libavutil and not application in the sense of a program suite
(executable code) that I am the author of.

  Maybe it was my primary mistake to not make things exactly clear
in the beginning when I laid out the first version of libavutil.
But soon Micheal partly corrected my initial mistake by committing
the document doc/avutil.txt. Also it seems appropriate here to
mention that from my point of view Micheal was and is doing a very
good job maintaining libavutil.

  So to answer your question I will first take my turn describing lavu:
(NOTE: I will not be to formally nor fully complete here to get the
       idea across and to be faster in getting this mail out.)

  I think of lavu as an addition to the ISO standard C library.
It provides additional routines in following main categories:
  * crypto
  * mathematics
  * data structures/algorithms
  * auxiliary routines of all sorts
    (I should probably mention some subcategories here, but I am
     afraid I am to tired for that)

  There is no main topic of lavu: think of standard libraries, they
are some set of routines considered to be available to you on all
platforms the language runs on. There are enormous differences in
the philosophies and extents of standard libraries among different
programming languages. The difficult part here is limiting the scope
and size (in some regards it will always be somewhat arbitrary).
Anyway good standard library functions are not specific to a concrete
application software (like ffmpeg). So adding more to lavu certainly is 
possible but it should not be done with a copy and paste approach
(slight refactoring might still fall into this category) and of course
it should be done with the help and acknowledgement of the maintainer
which is (at least for me) Micheal.

  Now to answer the usage question: lavu can potentially be used in
every application the same way you usually use parts of the C standard
library in most applications.
 

> libavcore right now contains some audio/image layout bits, a parser and
> other useful stuff, overall just small things (it's 100k with debug
> symbols et all). I don't see how the libavutil-only user would have
> issues with having that additional code around, given that we have at
> least already two really different candidate users from my and reimar's
> understanding of the library interesting features.

  What I have written above also applies here. If someone wants to argue
for some of the lavco stuff to be included in lavu she should pick one
of those things and make a new thread where it can be discussed separately.
If it is approved to be useful to have in lavu, the re-design (if needed)
and other steps necessary for inclusion can be worked out there.

  The mentality of just merging lavco into lavu because we want to get
rid of lavco is not fair in respect to lavu. Also there might very well
be other ways to get rid of lavco if it is really such a big problem.
Of course that would require careful thinking and rethinking through
the problem and its possible solutions. But unfortunately pressuring a
merge of lavco into lavu is working into the opposite direction :(


  Alexander