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

Alex Converse alex.converse
Thu Feb 10 09:42:52 CET 2011


On Wed, Feb 9, 2011 at 6:46 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> 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:
>>>>> Hi,
>>>>>
>>>>> 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.
>

Is it really wise to have enable/disable flags on API functions? It
seems like a compatibility disaster waiting to happen.

> The split between lavu and lavcore is completely random. The use case

What do you think in util belongs in core or vice-versa? Or do you not
see any sort of distinction between any either of them?

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

Agreed.

OTOH, what do various down streams find so onerous about libavcore?
Perhaps if people knew why it was so hated they would either fix it or
favor removal.

Regards,
Alex



More information about the ffmpeg-devel mailing list