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

Fri Jul 9 15:53:27 CEST 2010

On Fri, Jul 09, 2010 at 01:07:40AM +0200, Stefano Sabatini wrote:
> 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.

i think a new lib is a good idea as it will solve the repeated fights
on what multimedia specific stuff to throw in libavutil

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100709/0c94cc3c/attachment.pgp>