[FFmpeg-devel] [misc-filters PATCH 2/8] Move av_parse_frame_size() and av_parse_frame_rate() from libavcodec to libavutil. This way they can be used without to require a dependency on libavcodec.

Stefano Sabatini stefano.sabatini-lala
Wed Jul 7 23:29:31 CEST 2010


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).

Anyway while we're thinking at it, I'd like to commit the color
source (and the lavfi framework already depends on lavc).

Regards.
-- 
FFmpeg = Fast and Fast MultiPurpose Erratic Gadget



More information about the ffmpeg-devel mailing list