Re: [FFmpeg-devel] [PATCH] avfilter: merge loudnorm filter functionality into f_ebur128.c

[Paul B Mahol <onemda@gmail.com>]

On Sun, Nov 19, 2023 at 10:55 PM Marton Balint <cus@passwd.hu> wrote:

>
>
> On Sun, 19 Nov 2023, Paul B Mahol wrote:
>
> > On Fri, Nov 17, 2023 at 7:38 AM Kyle Swanson <k@ylo.ph> wrote:
> >
> >> Hi,
> >>
> >> On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol <onemda@gmail.com> wrote:
> >> >
> >> > Attached.
> >>
> >> Only had a few minutes to look at this. Seems like more than just
> >> merging two filters, I see a bunch of new filter options for example.
> >> Can you explain?
> >>
> >
> > The linear mode and scanning, both input to filter and filter output
> itself
> > should give similar results.
> > The dynamic mode now actually can be configured how aggressively it will
> > expand / compress audio.
> > Because current state of filter have numerous issues:
> >
> > - using unmaintained old libebur128 module, when same functionality is
> > already available in existing filter.
> > - code duplication and functionality duplication due the above
> > - buggy limiter - causing clipped samples randomly
> > - buggy first and final frame filtering
> > - over-complicated flow path for dynamic code in filter
> > - excessive compressing of audio dynamic range, causing extreme smaller
> > LRU from output audio
> > - and probably more that I forgot
> >
> > Some options from this patch can be probably removed, like attack/release
> > options, and just use defaults as currently in patch.
>
> Previously ebur128 functionality was decoupled from specific filters, so
> there was a chance that multiple filters can use it. Unfortunately
> f_ebur128.c was never migrated to use internal ebur128 lib, as far as I
> remember the maintaner rejected the idea for some reason back then.
>

Because its pointless, both use histograms, and this is just duplicated
code.
Also f_ebur128.c code/filter come first, even though its scanner only and
have visuals.


> IMHO having some generic ebur128 functionality would be preferable. I
> have an old patch for example which adds EBUR128 mode to af_dynaudnorm,
> see attached for reference. Looks much cleaner than af_loudnorm, which was
> always a bit overcomplicated and slightly buggy, as you mentioned.
>
> So please consider two things:
>
> - Can you keep some generic ebur128 functionality which can easily reused
>    by multiple filters? I don't mind if it is the old code from ebur128 lib
>    or current code from f_ebur128, but it should be reusable internal ff_
>    functions.
>

That can be done, I already done something similar in this patch, but it
can be extended and improved.


>
> - Does it make sense to maintain a separate loudnorm filter for EBUR128
>    loudness, or it can be integrated into af_dynaudnorm? Because I kind of
>    think that having this as a option of af_dynaudnorm would be
>    cleaner, at least for the dynamic normalization functionality. For the
>    linear mode, well, we already have compressor filters, so I am not sure
>    if that mode is worth keeping. But maybe it is easier for the end user,
>    I don't know.
>

dynaudnorm filter is using different approach completely. It can have delay
less than second and more that 30 seconds depending on parameters.

ebur128 is using 3 second window and also history of previous measurements,
and minimal delay is 1/10 of second.
Also ebur128 applies special biquad before calculating gains...
So the approach of loudnorm vs dynaudnorm is completely different and does
not make sense to put it into dynaudnorm. (one could add optional
side-chain stream to dynaudnorm but that is max where i would go)

Linear mode of loudnorm filter is just volume filter. It just set single
gain factor by interpreting parameters from input. (The only drawback is
that you rescan audio again, twice, input of filter and output of filter,
so there are 4 scans in 2-pass mode, when there is only 1 scan pass needed
for linear mode....)
Also linear mode is used heavily by other users/project as can be found on
net.
Dynamic mode (for real-time streams) is also used, even in its current
state, thats why I wanted to cleanup it.


>
> Thanks,
> Marton_______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".