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

[Kyle Swanson]

On Sat, Jun 18, 2016 at 3:49 AM, 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?

Hi,

af_loudnorm currently links libebur128. The port makes sense because
libebur128 is tiny, MIT-licensed, has a good API, and would be useful
in several filters. Perceptual loudness has become an important topic
in broadcasting and audio in general, and it'd be nice to provide
these filters to everybody without having to link an external library.

FFmpeg already has some ebur128 logic in f_ebur128, which I was
initially interested in breaking out into something reusable, but
found libebur128 was better suited for this. This was discussed last
month when the loudnorm filter was pushed, and also with the
expectation that libebur128 would be ported to FFmpeg. Briefly,
libebur128 allows several modes of measurement, custom channel
mappings, doesn't require resampling the input stream, is faster, and
has a reusable API.

Thanks,
Kyle

>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel