[FFmpeg-devel] [PATCH] Merge libavcore into libavutil
Ronald S. Bultje
Thu Feb 10 03:46:03 CET 2011
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 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
>> ?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
> 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.
More information about the ffmpeg-devel