[FFmpeg-devel] [RFC] New library for shared non-generic libav* utils

[Stefano Sabatini]

On date Wednesday 2010-07-07 23:29:31 +0200, Stefano Sabatini encoded:
> On date Wednesday 2010-07-07 20:42:23 +0200, Michael Niedermayer encoded:
> > On Wed, Jul 07, 2010 at 03:34:13PM +0100, M?ns Rullg?rd wrote:
> > > Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
> > > 
> > > > On date Wednesday 2010-07-07 14:31:57 +0200, Michael Niedermayer encoded:
> > > >> On Wed, Jul 07, 2010 at 12:24:18AM +0200, Stefano Sabatini wrote:
> > > >> > On date Tuesday 2010-07-06 14:31:05 +0200, Michael Niedermayer encoded:
> > > >> > > On Sat, Jul 03, 2010 at 10:13:07PM +0200, Stefano Sabatini wrote:
> > > >> > > > On date Saturday 2010-07-03 22:06:15 +0200, Michael Niedermayer encoded:
> > > >> > > > > On Sat, Jul 03, 2010 at 09:47:10PM +0200, Stefano Sabatini wrote:
> > > >> > > > > > On date Friday 2010-07-02 00:04:32 +0200, Michael Niedermayer encoded:
> > > >> > > > > > > On Thu, Jul 01, 2010 at 10:41:05PM +0200, Stefano Sabatini wrote:
> > > >> > > > > > > > ---
> > > >> > > > > > > >  libavcodec/avcodec.h |   24 ---------
> > > >> > > > > > > >  libavcodec/utils.c   |  127 --------------------------------------------------
> > > >> > > > > > > >  libavutil/avutil.h   |   24 +++++++++
> > > >> > > > > > > >  libavutil/utils.c    |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >> > > > > > > >  4 files changed, 151 insertions(+), 151 deletions(-)
> > > >> > > > > > > 
> > > >> > > > > > > this stuff imho does not belong to libavutil.
> > > >> > > > > > > but whatever #if vsrc_movie needs should be enough for this
> > > >> > > > > > 
> > > >> > > > > > I'm not sure you're approving this patch, another variant in
> > > >> > > > > > attachment. I prefer this one as it doesn't clutter avutil.h.
> > > >> > > > > 
> > > >> > > > > vsrc_movie can use libavformat
> > > >> > > > > libavformat depends on libavcodec
> > > >> > > > > so filters can use libavcodec under whatever #ifdef vsrc_movie is
> > > >> > > > 
> > > >> > > > My plan was to use this functions for other sources as well, for
> > > >> > > > example for the color source, and I don't want to make it depends on
> > > >> > > > lavc only for these functions.
> > > >> > > > 
> > > >> > > 
> > > >> > > > Also the functions look generic enough to deserve a place in lavu.
> > > >> > > 
> > > >> > > i dont want them in lavu, they dont belong there
> > > >> > 
> > > >> > Could you elaborate on this? Where should they stay if not in lavu?
> > > >> 
> > > >> libavutil is supposed to be a small generic util lib.
> > > >> video width/height belong in it as much as car manufactor lists.
> > > >> maybe we need a libavcommon for all the common multimedia code that is
> > > >> not multimedia independant utils.
> > > >
> > > > Are you saying that libavutil shouldn't contain multimedia-related
> > > > utils?
> > > 
> > > Let's go back to the beginning:
> > > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/23918
> > 
> > see doc/avutil.txt too
> > 
> > 
> > > 
> > > > But it already contains colorspace.h, pixfmt.h, pixdesc.h, AVMEDIA_*
> > > > macros and AVERROR_* error codes (which are possibly
> > > > multimedia-related).
> > 
> > headers are lightweight they dont increase the object size
> > and you will remember me mildly opposing some of these
> > 
> > 
> > > >
> > > > We could have a separate library, but this would increase the
> > > > complexity of the project, and we won't know where to put things in
> > > > many cases, as it's not always clear if something is related to
> > > > multimedia or not.
> > > >
> > > > Also I don't believe there is someone using libavutil in a
> > > > non-multimedia related project.
> > > 
> > > I agree trying to keep lavu strictly non-multimedia is odd, being part
> > > of ffmpeg and all...
> > 
> > yes but i think there are non multimedia projects out there that want to
> > use avl trees, crc, md5, sha1, good fast and portable random numbers,
> > cpu feature detection, simple expressiom evaluation, rational number
> > math, aes, des, lockless threadsafe fifos, portable ways to force functions
> > inline or non inline, base64 en/decoding, ...
> > 
> > if we fill avutil up with highly libavcodec/libavformat/libavfilter specific
> > stuff it will become less interresting for non multimedia projects and appear
> > bloated to them.
> 
> I don't think that we will add so many other things to lavu, I don't
> see the risk to make it really bloated, and if you think at it frame
> sizes/frame rates are not necessarily multimedia related stuff,
> although not very generic.
> 
> An exception may be the frame copy / allocation functions currently
> implemented in libavcodec/imgconvert.c (which are currently duplicated
> in lsws). A possible name for this new lib may be libavcore (which
> is IMO more descriptive than libavcommon).

So if we want to take seriously this idea, the new lib will end up to
contain pixfmt.h, pixdesc.h, AVMEDIA* macros, samplefmt.h,
sampledesc.h, picture allocation functions and possibly various parsing
utils (like av_parse_frame*), maybe some time functions may be placed
there as well.

The move of code which is currently placed in lavu will happen at the
next lavu major bump (no API/ABI breakages).

I propose libavcore (lavcore or lavco for friends) as the new name,
looks c00l3r than libavcommon and slightly more expressive.

This new lib will contain all code/utils which need to be shared
between more libav* libs, and are not enough generic to deserve a
place in libavutil, which is to be considered a collection of
generic/non-multimedia-related utilities.

If we agree on this I'll start to sketch some patches for creating the
new lib.

Regards.
-- 
FFmpeg = Fascinating and Frenzy MultiPurpose Egregious Gadget