[FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port

[Paul B Mahol]

On 6/18/16, Paul B Mahol <onemda at gmail.com> wrote:
> On 6/18/16, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>> On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes <h.leppkes at gmail.com>
>> wrote:
>>> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson <k at ylo.ph> wrote:
>>>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson <k at ylo.ph> wrote:
>>>>>
>>>>> 0001-avfilter-add-libebur128-port.patch
>>>>> This first patch ports libebur128 to ffmpeg. I haven't re-indented
>>>>> these yet, so please diff `ebur128.c' and `ebur128.h' with the
>>>>> original libebur128 files[1][2] to see what has changed. Also included
>>>>> is `queue.h' which comes from BSD, which AFAIK should be distributable
>>>>> if we decide to go this route. All these files still need their
>>>>> license header, as libebur128 is MIT licensed and needs its own
>>>>> copyright message. One other thing to take a look at is the section
>>>>> with the sse2 optimizations - does FFmpeg already have a macro we
>>>>> could use for this?
>>>>>
>>>>>
>>>>> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch
>>>>> This patch removes the libebur128 dependency for the loudnorm and uses
>>>>> the new internal ebur128 API.
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Two updated patches attached. This is the libebur128 port and the
>>>> af_loudnorm update. Please review if you can, as I'd like to try push
>>>> these before v3.1. Updates to af_astats and f_ebur128  to use this new
>>>> API will be coming in the near future as well.
>>>>
>>>
>>> The libebur128 port still contains global state (ie. static data
>>> initialized at runtime), as commented on in the earlier reviews can
>>> you get rid of those and move them into a library context (ie. not
>>> static globals)?
>>> We really don't like global state like this because of thread safety
>>> issues.
>>>
>>
>> Also, in general I must say I really don't like the idea or the
>> precedence this sets of porting complex external libraries into the
>> avfilter code.
>> Whats wrong with simply linking the library when you want to use it?
>> This is how it works for everything else, what makes this different to
>> warrant such a step?
>
> Because f_ebur128 is GPL and unlikely to get relicensed.
>

Also, it is better to avoid extrenal libraries if it is simple.