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

[Alex Converse]

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