On Monday, November 17th, 2025 at 3:48 PM, Tobias Rapp via ffmpeg-devel <[email protected]> wrote: > > > On 11/11/2025 03:33, Michael Niedermayer via ffmpeg-devel wrote: > > > Hi > > > > adding niklas to the CC so its not missed > > but i agree the patch LGTM > > > > On Tue, Nov 04, 2025 at 08:52:36PM +0100, Nicolas George via ffmpeg-devel > > wrote: > > > > > Carl Hetherington via ffmpeg-devel (HE12025-11-03): > > > > > > > Since 3b26b782eeded9b9ab7fac013cd1a83a30d68206 it would only look at the > > > > first channel. > > > > > > > > Signed-off-by: [email protected] > > > > --- > > > > libavfilter/f_ebur128.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Hi. Thanks for the patch. I suspect the issue has been here for a longer > > > > time, if only on one branch of the conditional build: > > > > > > #if CONFIG_SWRESAMPLE > > > … > > > const double sample = fabs(swr_samples[i * nb_channels]); > > > #endif > > > > > > versus > > > > > > const double *restrict samples_ch = &samples[ch]; > > > … > > > const double sample = fabs(samples_ch[nb_channels * i]); > > > > > > Anyway, the fix looks good to me. > > > > > > Niklas, it has become mostly your code, what do you make of it? > > > Now that n8.0.1 will be tagged soonish it would be great if this fix > could be included. > > Regards, Tobias
Hi Tobias, Sorry for the delay in responding. I agree that this seems to be a bug that has been around for quite a while, and that your fix seems correct. I also don't suspect the performance will be impacted as a result, unless the compiler is really very clever to eliminate the common subcalculation by reassociating the FFMAX calls. Thanks, Niklas P.s. In the future, it's probably faster if you submit patches directly on https://code.ffmpeg.org/ _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
