On Wed, Apr 6, 2016 at 10:02 AM, Clément Bœsch <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, Clément Bœsch <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? >> > >> > [...] >> > >> > -- >> > Clément 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. > >> 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). > > -- > 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
