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

[Ronald S. Bultje]

Hi,

On Thu, Feb 10, 2011 at 3:42 AM, Alex Converse <alex.converse at gmail.com> wrote:
> On Wed, Feb 9, 2011 at 6:46 PM, Ronald S. Bultje <rsbultje at gmail.com> 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.
>
> Is it really wise to have enable/disable flags on API functions? It
> seems like a compatibility disaster waiting to happen.

I agree. My opinion is that people using special ./configure flags
will know what to expect. Similar to people using
--disable=decoder=h264 --disable-avfilter. No ffh264dec, plus no
lavfilter. I guess they want it. And that has consequences for API
(lavfilter) and functionality (ffh264dec) as well.

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

Honestly, I see no difference.

This split between multimedia and non-multimedia is hackish and
awkward. Not to start a complete new trollwar, but GStreamer's core is
completely multimedia-unaware. That's great. Do people use it as the
backend of DBus now? I mean, both are ways of sending messages across
a pipe. No they don't, because people suffer from NIH. And that's
fine.

FFmpeg is a (set of) multimedia library/ies and tool(s), and we should
optimize all parts of it for that particular use.

Ronald