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

[Marton Balint]

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.

> 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. Also, I am not sure that everybody who wants to 
measure true peak will want no oversampling at an above 192KHz.

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.

>>
>> 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