On Wed, Apr 6, 2016 at 5:31 PM, Paul B Mahol <one...@gmail.com> wrote: > On 4/6/16, Kyle Swanson <k...@ylo.ph> wrote: >> On Wed, Apr 6, 2016 at 10:02 AM, Clement Boesch <u...@pkh.me> wrote: >>> On Wed, Apr 06, 2016 at 09:52:51AM -0500, Kyle Swanson wrote: >>>> On Wed, Apr 6, 2016 at 12:45 AM, Clement Boesch <u...@pkh.me> wrote: >>>> > On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote: >>>> >> Here's another audio filter. I hinted at this a few months ago, but I >>>> >> found out that >>>> >> finishing the last 5% took almost as long as the first 95%. This is an >>>> >> EBU R128 >>>> >> dynamic loudness normalization filter. This filter uses libebur128 >>>> >> v1.1.0[1] and must be >>>> >> configured with `--enable-libebur128'. Please also see the >>>> >> accompanying blog post[2] >>>> >> which has an algorithm description, as well as some usage >>>> >> instructions. >>>> >> >>>> >> [1] https://github.com/jiixyj/libebur128 >>>> >> [2] http://k.ylo.ph/2016/04/04/loudnorm.html >>>> >> >>>> >> Thanks! >>>> >> Kyle >>>> >> >>>> >> Signed-off-by: Kyle Swanson <k...@ylo.ph> >>>> >> --- >>>> >> Changelog | 1 + >>>> >> MAINTAINERS | 1 + >>>> >> configure | 5 + >>>> >> doc/filters.texi | 42 +++ >>>> >> libavfilter/Makefile | 1 + >>>> >> libavfilter/af_loudnorm.c | 905 >>>> >> ++++++++++++++++++++++++++++++++++++++++++++++ >>>> >> libavfilter/allfilters.c | 1 + >>>> >> libavfilter/version.h | 4 +- >>>> >> 8 files changed, 958 insertions(+), 2 deletions(-) >>>> >> create mode 100644 libavfilter/af_loudnorm.c >>>> >> >>>> > >>>> > Mmh. That's nice and all but... why not use/adjust the native ebur128 >>>> > filter we have instead of relying on an external library? >>>> > >>>> > [...] >>>> > >>>> > -- >>>> > Clement B. >>>> >>>> This could be an option for the future. We'll need to break all the >>>> EBU R128 logic out into utility functions >>> >>> why? what do you need exactly from the filter? The meta are exported in >>> each audio frame. >> >> That could work, but in this filter there is a second internal >> loudness measurement. Frame meta would only work for the input stream. > > Couldn't code from ebur128 filter be refactored in such way so it > could be used by loudnorm? >
Yeah, that's what I was saying. It could be done, but might take a little while. I figure libebur128 could work fine in the meantime. Would probably also be useful for filters like astats. >> >>> >>>> and update it to use the newest version BS.1770 so it can be used by >>>> both filters. Using libebur128 is a >>>> good option because it is widely used, actively developed, and updated >>>> whenever the spec changes. >>> >>> except it's an external dependency and we have code builtin available, >>> doing the same thing, and with no open issue (afaik). >>> >>> -- >>> Clement 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 >> > _______________________________________________ > 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
