[FFmpeg-trac] #9352(avfilter:new): loudnorm filter goofs loudness measurements in some cases

[FFmpeg]

#9352: loudnorm filter goofs loudness measurements in some cases
-------------------------------------+-------------------------------------
             Reporter:  Gregory      |                     Type:  defect
  Beauregard                         |
               Status:  new          |                 Priority:  normal
            Component:  avfilter     |                  Version:
                                     |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug: The loudnorm filter can badly goof the integrated
 loudness in certain situations (e.g. particular noise after a resample)
 resulting in significant distortion if attempting to use it.

 Using the attached file `loudnorm_samp.mkv` (4.7 MB), 48 kHz DTS-HD,
 analyze the loudness with loudnorm to get integrated loudness ~-21:
 `"input_i" : "-21.57"`:
 {{{
 ffmpeg -i loudnorm_samp.mkv -af
 aresample=ocl=stereo,loudnorm=print_format=json -f null -
 }}}

 However, when we reanalyze it by giving the resampler a dither and
 specifying 48 kHz, the loudnorm filter goofs the integrated loudness with
 0.13: "input_i" : "0.13"`:
 {{{
 ffmpeg -i loudnorm_samp.mkv -af
 aresample=ocl=stereo:dither_method=shibata:osr=48000,loudnorm=print_format=json
 -f null -
 }}}

 This results in really wrong re-normalization resulting in significant
 distortion. If we run `ebur128` to analyze the loudness instead of
 `loudnorm` in the situation where it goofs, `ebur128` outputs an expected
 -22.2 integrated loudness, and doesn't change between the two situations
 above:
 {{{
 ffmpeg -i loudnorm_samp.mkv -af
 aresample=ocl=stereo:dither_method=shibata:osr=48000,ebur128 -f null -
 }}}

 So there's some odd sensitivity in the `loudnorm` filter that's messing it
 up where `ebur128` is still ok.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9352>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker