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

Michael Niedermayer michaelni
Mon Jul 19 02:40:41 CEST 2010


On Sat, Jul 17, 2010 at 07:05:41PM +0200, Stefano Sabatini wrote:
> On date Friday 2010-07-09 18:33:05 +0200, Michael Niedermayer encoded:
> > On Fri, Jul 09, 2010 at 04:41:59PM +0100, M?ns Rullg?rd wrote:
> > > Michael Niedermayer <michaelni at gmx.at> writes:
> > > 
> > > > On Fri, Jul 09, 2010 at 09:54:11AM -0400, Ronald S. Bultje wrote:
> > > >> Hi,
> > > >> 
> > > >> On Thu, Jul 8, 2010 at 7:07 PM, Stefano Sabatini
> > > >> <stefano.sabatini-lala at poste.it> wrote:
> > > >> [.. cut ..]
> > > >> > 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.
> > > >> 
> > > >> Disregard me if majority says otherwise, I just wanted to
> > > >> bikesheddishly note that my personal humble opinion is that less libs
> > > >> is good, so I'd not have any problems with media-related stuff going
> > > >> into libavutil. I think the chance that people use a FFmpeg lib for
> > > >> something unrelated to multimedia is relatively small and should not
> > > >> be our main focus. Reminds me of not allowing media-specific stuff in
> > > >> libgstreamer.so. It only causes headaches and distractions. There is
> > > >> no practical advantage.
> > > >
> > > > as maintainer of libavutil i object.
> > > 
> > > You are not the sole maintainer.
> > > 
> > > > We can have a seperate lib for common code.
> > > 
> > > If ever there were an exercise in work creation, this is it.
> > 
> > for us yes, but libavutil is usefull to other projects, ive myself
> > used code from it for many things unrelated to ffmpeg. Its not used
> > much by outsiders but i think thats more because its not well known.
> > 
> > 
> > > 
> > > > Iam not stopping people from having their common lib which prior to
> > > > libavfilter was libavcodec. But now due to libavfilter not depending
> > > > on libavcodec this is no longer possible.
> > > >
> > > > But trying to kill my effort of a util lib
> > > 
> > > Perhaps conducting that effort inside FFmpeg, the most
> > > multimedia-focused project the world has ever known, wasn't such a
> > > bright idea.
> > 
> > it depends, we do need all the code in libavutil anyway, putting it in a
> > seperate lib that others can use too doesnt seem all that wrong.
> > and it is now available in most distros, thus it can actually be used
> > 
> > what non bloated alternatives exist for similar functionality?
> > 
> > 
> > > 
> > > > is simply another thing that is purely provocating.
> > > 
> > > People have a right to express their opinions without you being offended.
> > 
> > of course
> > 
> > 
> > > 
> > > > I spended alot of time on libavutil and its only goal was to become
> > > > a general utils lib
> > > 
> > > Said who?  It wasn't even your idea to begin with.  It was suggested
> > > and implemented by Alexander Strasser.
> > 
> > svn blame of *.c *.h says:
> > ...
> >     102      ramiro
> >     108       takis
> >     110      benoit
> >     111      lucabe
> >     123     bellard
> >     126   michaelni
> >     157          al
> >     185    gpoirier
> >     285      kostya
> >     351       aurel
> >     918      reimar
> >    1295       diego
> >    1349         mru
> >    1616     stefano
> >    2398     michael
> > 
> > so id say, yes iam still the primary maintainer and author, even if
> > we consider that blame is not the worlds most idiot proof way to
> > check this
> 
> Here it is a patch, it's not yet clear how many people are going to
> accept this.
> 
> As for me I already explained that, while I dislike the added
> complexity, I also appreciate the idea of a minimal generic libavutil
> which could be used in other non multimedia related projects.
> 
> Since Michael dislikes the idea of pushing multimedia-related shared
> stuff to lavu, I find the addition of a new library an accptable
> compromise.
> 
> As for the name, Michael proposed libavcommon, I don't like much this
> name so I'm proposing libavcore (like -> multimedia core
> utilities). Other ideas: libavmediacore or libavmediautils.
> 
> I plan to move here the imgconvert stuff and some parsing utils from
> lavc, and pixfmt/pixdesc + media macros from lavu at the next lavu
> major bump.
> 
> Regards.
> 

>  Makefile              |    1 
>  cmdutils.c            |    3 ++
>  common.mak            |    2 -
>  configure             |    9 ++++++-
>  libavcore/Makefile    |    9 +++++++
>  libavcore/avcore.h    |   58 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  libavcore/libavcore.v |    4 +++
>  libavcore/utils.c     |   40 ++++++++++++++++++++++++++++++++++
>  8 files changed, 124 insertions(+), 2 deletions(-)
> f3318ff992327d0408560b9b986134fb5e64659b  0001-Add-libavcore.patch
> >From 04cdf8ce20d4aaaa030873518210f91289cc4264 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini <stefano.sabatini-lala at poste.it>
> Date: Sat, 17 Jul 2010 17:38:28 +0200
> Subject: [create-lavcore PATCH] Add libavcore.
> 
> The new library is meant to contain the core multimedia utilities for
> FFmpeg, to make them shareable between more libav* libraries.

iam ok with this as far as it falls under my maintainership

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20100719/e3cd3104/attachment.pgp>



More information about the ffmpeg-devel mailing list