[FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

Kyle Swanson k at ylo.ph
Sat Nov 12 06:55:45 EET 2016

On Fri, Nov 11, 2016 at 6:12 PM, Marton Balint <cus at passwd.hu> wrote:
> On Thu, 10 Nov 2016, Kyle Swanson wrote:
>> On Thu, Nov 10, 2016 at 4:16 PM, Marton Balint <cus at passwd.hu> wrote:
>>> On Thu, 10 Nov 2016, Kyle Swanson wrote:
>>>> On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson <k at ylo.ph> wrote:
>>>> These patches look good to me. If we're going to do this, we really
>>>> need to keep the true peak mode in the libebur128 port. This is a huge
>>>> part of the R128 spec, and it's important that it stays in. Of course
>>>> redundant code is bad, so we'll need to update f_ebur128 as well
>>>> (which has a true peak requirement.) I already have a patch for
>>>> f_ebur128. Marton, it might be easier for you to update the patch to
>>>> include true peak mode but I could do it as well. It'd be interesting
>>>> to benchmark the libebur128 FIR resampler vs. swresample.
>>> I'd rather push the patch as it is, then if you are interested, you can
>>> start working on true peak. OK?


> Ok, I applied it.

Awesome. Thanks for your work on this!

>> Cool, patch is attached. Resampling here is done via libswresample.
> Yeah, I think I mentioned earlier that the library has a problem with true
> peak measurement, notably it cannot measure true peak without any loudness
> measurement, which is a shame performance-wise, since the user might neeed
> true peak only.

I guess you're technically right about this, but if someone _only_
wanted true peak stats, they wouldn't/shouldn't be using the ebur128
API/filter. `-af aresample=192k,astats` already does the trick. The
EBU R128 spec says this: `A minimum feature set is required for all
EBU Mode loudness meters: an EBU Mode compliant meter shall be able to
measure and display the three main measures ‘Programme Loudness’,
‘Loudness Range’ and ‘Maximum True Peak Level’.` Basically, we need to
include true peak in our EBU R128 implementation, and it's clean and
convenient to leave it in as part of the API, just like libebur128
already has it.


> Also, I am not sure that everybody who wants to measure true
> peak will want no oversampling at an above 192KHz.

For EBU R128 / BS.1770, this is all the spec requires. There are
already many other ways to measure true peak if you're after another

> Have you considered the separete context idea? If we want our API to be
> similar to the external lib, we still can use the separete true peak context
> inside the EBUR128 context if the user wants true peak.

I totally get what you're saying, but it seems to unnecessary to write
this little abstraction on top of libswresample (I also don't know
where else it'd be useful.) libswresample is already the separate
context. :)

Take a look at my patch, it should be good. I'll also be sending a
patch (in a new thread) to update f_ebur128 for this new API soon.


>>> Since true peak calculation is so entirely different from loudness
>>> calculation, you might also create a separate API/Context for it. Just
>>> beacuse both loudness measurement and true peak is referenced in EBU R128
>>> recommendation, we don't necessarily have to use the same API for them.
>>> For
>>> example, for true peak measurement, you might want to specify the
>>> oversampling factor, but not the channel layout...
> Regards,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list