From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 7E67C493F1 for ; Fri, 9 Feb 2024 19:19:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BD0BC68D02A; Fri, 9 Feb 2024 21:18:58 +0200 (EET) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0CC8868CD0C for ; Fri, 9 Feb 2024 21:18:52 +0200 (EET) Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4101eb5a115so11933415e9.1 for ; Fri, 09 Feb 2024 11:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707506331; x=1708111131; darn=ffmpeg.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=6qzVYSb3He2Qo6McGrURhZ5vpB6HH+3/kXG7r7efDTs=; b=eDlkHJSboDyZSC/Nhkcg7DA/o/pss3vKmo/n+oBZyY/cS8ii6QUz7hgrivwq4nut6S Ybc0QX9TpYzZ0zPCBjpWmxtJJ9aHjcBYj5pYCf28gC17yxnzRG5G1rb1Lcldz+5+H43e faOZZ5g4A+SnU3V/0Gl97vuLToia/6+W+DDLBFn5/TCk0+AmILCdjT9JOuvxYpogqmEU n1UuNxCA3fzyKZVt84JYEXNFPlCQDaWuBWmV8VHwIkSDeYv4vFG8VWD40td3QSbSvxvG uPRuUmcu2xKyDVnxsu7dQpUozn7/Es2kCOeGG2VtFWJHJVdpO8+1ZJ+iza+I/O+j8GgZ PZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707506331; x=1708111131; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6qzVYSb3He2Qo6McGrURhZ5vpB6HH+3/kXG7r7efDTs=; b=FbmrbtFGS02nqW53q24rEGsb9GVcI1V2hecnymvOht93lbgU9G46GXnmr0hzCtWYBt ktZCM7zOMreOLUdm1AGgBKwvx/NFCJ05XKcsnnlvbS4oy59bbFjv4RzfcSZVNlAVhz5k HEHbuGP3I55WSp38IHgFSFNMAKuh5J/dEfRwCB5yop8naL8rzFsLfsgj3Eg91cMH2SjV Saam/dpHCRfWNy72sA6j32GPBUbqbRgGnV4+EBuztVGpS9bi6UqI7EDHMOT+g67x1m/s rVvNFelbI3SlDlwOX39OavnRrVByQHfDRpYS4FfS/jzQr3LLDEnS+y5Hwr5dryfYM8RQ pGNA== X-Gm-Message-State: AOJu0YzoFJKhSQdrGtglS9RL7wY3/otviqcwuAnZDvpr4xXoVLO/NluP kllis0kjLYe6uvmWUhdgHnFT0v7n35Wr973+1vng7q1nx/e7+DXEaEeRDRqD X-Google-Smtp-Source: AGHT+IHgux0xZGabUNNLU8r9vOt4JvBANB7hiqt1katMDRiCsdpc5CRIBKSDGy+xRa2BEgA5FhEYBQ== X-Received: by 2002:adf:fe03:0:b0:33b:4ec0:8166 with SMTP id n3-20020adffe03000000b0033b4ec08166mr1670055wrr.37.1707506330959; Fri, 09 Feb 2024 11:18:50 -0800 (PST) Received: from kusa (2a01cb040b6872000000000000000afa.ipv6.abo.wanadoo.fr. [2a01:cb04:b68:7200::afa]) by smtp.gmail.com with ESMTPSA id n11-20020a05600c3b8b00b004105017f83fsm1490459wms.31.2024.02.09.11.18.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 11:18:50 -0800 (PST) Date: Fri, 9 Feb 2024 20:18:38 +0100 From: Matthieu Bouron To: FFmpeg development discussions and patches Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avfft: avoid overreads with RDFT API users X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, Feb 09, 2024 at 06:27:50PM +0100, Lynne wrote: > The new API requires an extra array member at the very end, > which old API users did not do. > > This disables in-place RDFT transforms and instead > does the transform out of place by copying once, there shouldn't > be a significant loss of speed as our in-place FFT requires a reorder > which is likely more expensive in the majority of cases to do. > > Patch attached. > > From 763f2e8941dc3dd4282ad42574bd8d451a256a53 Mon Sep 17 00:00:00 2001 > From: Lynne > Date: Fri, 9 Feb 2024 18:17:54 +0100 > Subject: [PATCH] avfft: avoid overreads with RDFT API users > > The new API requires an extra array member at the very end, > which old API users did not do. > > This disables in-place RDFT transforms and instead > does the transform out of place by copying once, there shouldn't > be a significant loss of speed as our in-place FFT requires a reorder > which is likely more expensive in the majority of cases to do. > --- > libavcodec/avfft.c | 31 +++++++++++++++++++++++++------ > 1 file changed, 25 insertions(+), 6 deletions(-) > > diff --git a/libavcodec/avfft.c b/libavcodec/avfft.c > index 999b5ed79a..485f216427 100644 > --- a/libavcodec/avfft.c > +++ b/libavcodec/avfft.c > @@ -152,7 +152,7 @@ RDFTContext *av_rdft_init(int nbits, enum RDFTransformType trans) > return NULL; > > ret = av_tx_init(&s->ctx, &s->fn, AV_TX_FLOAT_RDFT, trans == IDFT_C2R, > - 1 << nbits, &scale, AV_TX_INPLACE); > + 1 << nbits, &scale, 0x0); > if (ret < 0) { > av_free(s); > return NULL; > @@ -162,17 +162,35 @@ RDFTContext *av_rdft_init(int nbits, enum RDFTransformType trans) > s->len = 1 << nbits; > s->inv = trans == IDFT_C2R; > > + s->tmp = av_malloc((s->len + 2)*sizeof(float)); > + if (!s->tmp) { > + av_tx_uninit(&s->ctx); > + av_free(s); > + return NULL; > + } > + > return (RDFTContext *)s; > } > > void av_rdft_calc(RDFTContext *s, FFTSample *data) > { > AVTXWrapper *w = (AVTXWrapper *)s; > - if (w->inv) > - FFSWAP(float, data[1], data[w->len]); > - w->fn(w->ctx, data, (void *)data, w->stride); > - if (!w->inv) > - FFSWAP(float, data[1], data[w->len]); > + float *src = w->inv ? w->tmp : (float *)data; > + float *dst = w->inv ? (float *)data : w->tmp; > + > + if (w->inv) { > + memcpy(src, data, w->len*sizeof(float)); > + > + src[w->len] = src[1]; > + src[1] = 0.0f; > + } > + > + w->fn(w->ctx, dst, (void *)src, w->stride); > + > + if (!w->inv) { > + dst[1] = dst[w->len]; > + memcpy(data, dst, w->len*sizeof(float)); > + } > } > > av_cold void av_rdft_end(RDFTContext *s) > @@ -180,6 +198,7 @@ av_cold void av_rdft_end(RDFTContext *s) > if (s) { > AVTXWrapper *w = (AVTXWrapper *)s; > av_tx_uninit(&w->ctx); > + av_free(&w->tmp); av_free(w->tmp); > av_free(w); > } > } > -- > 2.43.0.381.gb435a96ce8 > Hi, I tested the patch with the av_free() adjustment and it fixed the crash / memory corruption I was encountering on macOS. Thanks, Matthieu _______________________________________________ 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".