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

Diego Biurrun diego
Thu Feb 10 09:37:03 CET 2011

On Wed, Feb 09, 2011 at 09:46:03PM -0500, Ronald S. Bultje wrote:
> On Wed, Feb 9, 2011 at 5:50 PM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote:
> > Le 9 f?vr. 2011 ? 23:28, Alexander Strasser a ?crit :
> >> Reimar D?ffinger wrote:
> >>> On Wed, Feb 09, 2011 at 09:11:02AM -0500, Ronald S. Bultje wrote:
> >>>> 2011/2/9 M?ns Rullg?rd <mans at mansr.com>:
> >>>>> Reinhard Tartler <siretart at tauware.de> writes:
> >>>>>> It is pretty hopeless that other considerable projects will adopt
> >>>>>> libavutil alone in other projects. Projects that need small footprint
> >>>>>> are better off with more specialized libraries such as gnulib or rather
> >>>>>> just copy the necessary parts that they need. With this in mind, nobody
> >>>>>> is helped by having libavutil and libavcore split. In order to ease
> >>>>>> maintenance inside and around FFmpeg and to reduce confusion where to
> >>>>>> put common code, avcore's functionality is merged (back) to avutil.
> >>>>>
> >>>>> OK
> >>>>
> >>>> OK with me also.
> >>>
> >>> Do people disagreeing get a say?
> >>> Also is there any specifc reason why it would ease maintenance (less
> >>> major version bumps or anything like that?).
> >>> I also don't think the reference to gnulib makes sense, I do not
> >>> see any significant overlap between gnulib and avutil (not even in
> >>> the goals, I don't have the impression that gnulib is especially
> >>> bloat-averse).
> >>
> >> ?Also it should be mentioned that copying the necessary parts is
> >> much less desirable and creates a way greater burden for projects
> >> using that approach. And maybe even worse, it just makes the statement
> >> for libavutil is only a utility lib for ffmpeg and there is no point
> >> in using it elsewhere (which is against the very thoughts of its
> >> creation).
> >>
> >
> > If someone want to use only one part of the library, he can create a static libavutil library, and the linker will take care of stripping unused modules automatically.
> Or, as I've said before, create independent modules that can be
> enabled/disabled automatically, similar to --disable-decoders or
> --disable-decoder=X,Y,Z in ./configure for lavc/lavf.
> The split between lavu and lavcore is completely random. The use case
> has been mentioned numerous times ("lavu can be used outside
> multimedia applications") but whenever we request evidence that it's
> actually widely used - say, similarly widely as lavcodec or lavformat
> - everybody ignores these requests. That's frustrating and makes us
> not bother considering the objections.


It has also never been marketed as something to be used outside of
programs that directly use FFmpeg.  Without some marketing this will
never happen.  There are billions of lines of code out there, you
need to tell people that there is a good reason to read these particular
ones.  I haven't seen any of this in the past and I do not expect it
in the future.


More information about the ffmpeg-devel mailing list