[FFmpeg-devel] [PATCH] Merge libavcore into libavutil
Wed Feb 16 10:39:41 CET 2011
On Tue, 15 Feb 2011, Reimar D?ffinger wrote:
> On Tue, Feb 15, 2011 at 08:26:45PM +0100, Diego Biurrun wrote:
>> On Tue, Feb 15, 2011 at 08:17:06PM +0100, Reimar D?ffinger wrote:
>>> On Tue, Feb 15, 2011 at 11:16:44AM +0100, Gwenole Beauchesne wrote:
>>>> On Tue, 15 Feb 2011, Janne Grunau wrote:
>>>>>>> I support the merge because "libavcore/" complicates tab-completion of
>>>>>> we could rename libavcore to libavbase or libavbloat
>>>>> That option has all disadvantages for downstreams for the single gain of
>>>>> easier developer tab-completion.
>>>> BTW, what are the real disadvantages for downstreams with this extra
>>>> libavcore library? It's not even a compilation problem, should
>>>> downstream use pkg-config. An extra lib to package? Not a big issue
>>>> either. I understand Loren's point though, since this indeed
>>>> disrupted tab completion. :)
>>>> OTOH, since FFmpeg 0.6 did not have libavcore, merging libavcore
>>>> back now should not be an issue for an upcoming FFmpeg 0.7.
>>> I very much object to disregarding projects that are more progressive
>>> than staying with ancient releases in such a way.
>>> Not that I consider it a major issue, but compared with the advantages
>>> I don't really see either...
>> MPlayer? That one is on me to fix, I'll gladly do it, so...
> No, I did not mean anything specifically, I mean generally, this
> kind of attitude is certain to discourage people from using or even
> supporting an up-to-date FFmpeg and I very much dislike that.
I don't want to diverge from this thread, but anyway, I don't think
libavcore vs. libavutil is the main reason that would discourage people
from using or even supporting an up-to-date FFmpeg. Most notably because
which tree should he be using now that both diverge? I for one switched to
videolan.org partly because it's nearest to me, thus the fastest. :)
I think this would also depend on who makes the next major FFmpeg release
and what distributors will choose to ship. The worst case would be that
both are making releases and distributors start shipping different
things... So, minimizing API/ABI changes would be the better thing,
likewise Michael's call to use AVOptions more.
> In general I think the "but nobody used it" or "that's not how you were
> supposed to use it" (even though even some developers didn't know that
> and it certainly wasn't documented) excuse is used too lightly to sneak
> in API/ABI changes (not claiming it is necessarily wrong).
I fully agree with this. There were reasons why the split was done, though
I admit I didn't remember/follow them, but how come those are now
More information about the ffmpeg-devel