Opened 4 years ago

Last modified 4 years ago

#8786 reopened defect

af_loudnorm: FINAL_FRAME handling does not update loudness anymore

Reported by: Sebastian Dröge Owned by:
Priority: normal Component: avfilter
Version: unspecified Keywords: loudnorm
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


At the last frame there will be up to 3s of samples left in the buffer. These are currently copied out into a new AVFrame and then handled specially. While they were all already passed to the input EBUR128 context and the corresponding gain adjustments for them were stored in the deltas array in the previous INNER_FRAME processing, the whole last frame in the FINAL_FRAME handling is using the same index into that array.

Currently the last 30 gain adjustments stored in the deltas array are not used at all

In theory every 100ms (i.e. up to 30 times) the index into the deltas array would have to be incremented in the FINAL_FRAME handling, and like in the INNER_FRAME handling it would make sense to do linear interpolation between the current/next gain.

I've found this while porting the filter to Rust for a GStreamer plugin, the code of which can be found here: ​ . This also contains lots of code comments for all the steps, which might be helpful to take over to the ffmpeg code too.

My solution for this might not be the best or most simple approach, but during my testing they worked so feel free to adapt them for the ffmpeg code.

You can find the solution for this issue here:

If you agree that the above approach (incrementing the index every 100ms and linear interpolation as for INNER_FRAME) is the right thing to do here, I can also prepare a patch for the C code in ffmpeg.

Change History (4)

comment:1 by Carl Eugen Hoyos, 4 years ago

Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket or send your patch - made with git format-patch to the FFmpeg development mailing list, there is no patch discussion on this bug tracker.

comment:2 by Sebastian Dröge, 4 years ago

There is no patch, at this point this is a bug report. I can prepare a patch if this if you consider this a bug and my proposed solution is acceptable, or someone else can fix it.

comment:3 by Carl Eugen Hoyos, 4 years ago

Resolution: needs_more_info
Status: newclosed

Please feel free to reopen this bug report if you can provide the missing information, a patch sent to the FFmpeg development mailing list is much more appreciated though.

comment:4 by Elon Musk, 4 years ago

Resolution: needs_more_info
Status: closedreopened
Note: See TracTickets for help on using tickets.