[FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

Marton Balint cus at passwd.hu
Fri Nov 4 06:19:20 EET 2016


On Thu, 3 Nov 2016, Hendrik Leppkes wrote:

> On Mon, Oct 17, 2016 at 5:20 PM, Moritz Barsnick <barsnick at gmx.net> wrote:
>> On Mon, Oct 17, 2016 at 17:09:15 +0200, wm4 wrote:
>>> Does this copy parts of libebur128 to FFmpeg?
>>> Why?
>>
>> There was a long discussion regarding this patch:
>>
>> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192668.html
>>
>> (in summary: "please don't require yet another small external library,
>> rather port it to ffmpeg and maintain it") leading to this one:
>>
>
> The generic idea was not to just copy/paste an external library into
> internal code, but extend the ebur128 code we already have - at least
> that way we get code written by one of our maintainers, code he knows
> and can properly maintain.

I copied the external library because we needed an API. The way the 
internals work, I used the library code because it was simply easier, than 
factoring out f_ebur128 stuff, also there are some features which 
f_ebur128.c does not have (variable sample rate support), and there 
was the licensing issue GPL v.s. LGPL.

> If you just copy the implementation of a library, you might as well
> just use that library - thats what it exists for. Why do we want to
> increase the maintenance burden of our project when other people (ie.
> the authors of libebur128) are already doing it as well?

In general I agree with people who think that for small code, it is better 
to integrate it into our codebase, because
- it can benefit from features we already have (e.g. resampling)
- makes it easier for developers to work on features based on this
- code gets more review than code in a small 3rd party library
- code and/or improvements have stronger requirements performance-wise
- code is better audited (Coverity, etc)

Yes, some additional maintenance burden is the price we pay for this, 
which is IMHO in this case is acceptable.

Regards,
Marton


More information about the ffmpeg-devel mailing list