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

Kyle Swanson k at ylo.ph
Sun Jun 19 09:21:24 CEST 2016


On Sat, Jun 18, 2016 at 6:00 AM, Clément Bœsch <u at pkh.me> wrote:
> On Sat, Jun 18, 2016 at 12:58:59PM +0200, Paul B Mahol wrote:
>> On 6/18/16, Clement Boesch <u at pkh.me> wrote:
>> > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol 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.
>> >
>> > 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not
>>
>> But you are blocking other ebur128 implementation to be used in f_ebur128.c
>
> Yes but not because of licence issues.
>

Clément, you do great work here and I've used f_ebur128 for years.
Understand, I'm just trying to make improvements.

> --
> Clément B.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list