On Sat, Jun 18, 2016 at 6:00 AM, Clément Bœsch <u...@pkh.me> wrote: > On Sat, Jun 18, 2016 at 12:58:59PM +0200, Paul B Mahol wrote: >> On 6/18/16, Clement Boesch <u...@pkh.me> wrote: >> > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: >> >> On 6/18/16, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >> >> > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes <h.lepp...@gmail.com> >> >> > wrote: >> >> >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson <k...@ylo.ph> wrote: >> >> >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson <k...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel