Message ID | 20170801150137.8844-1-mfcc64@gmail.com |
---|---|
State | New |
Headers |
Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.46.211 with SMTP id u202csp80924vsu; Tue, 1 Aug 2017 08:09:20 -0700 (PDT) X-Received: by 10.223.165.12 with SMTP id i12mr15032400wrb.5.1501600160638; Tue, 01 Aug 2017 08:09:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501600160; cv=none; d=google.com; s=arc-20160816; b=ej2QLr44w9iZ21Buq4PQ4cPup813HUeKLgoaYnIQMLW7KctA9VKaFc8KZSoGXMZM6m vuGsyjx3rtn/wRj+G0blHuAug7svdWhdBFumbWLY5++WZb396iRr2y8iDdTGEP6IlWg4 cCYwbAPV1fZAkpnNMum1Vly7K7c07iEVngV+ZIHbK5nrprz53fuY3k6LY9RRWpd+vLA5 y1rmcn8NSlTAtkGuE+uuh/VFSNI4gkAzEqbvqMPUQwuROr4U6gdVtXoFMpBd4qpL0tCM rvCsPEr6zNLDxHbM+WCwbT/OFBU42d5iS9dSTF24nclAMzwFbhOfvKnuByVNQA+uGd/J 6VUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:reply-to:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:mime-version:message-id:date:to:from :dkim-signature:delivered-to:arc-authentication-results; bh=1alqxIDIvmaCEpjDUuKf5kcXFpaB6N7tZs9RD9FwgEM=; b=ITvzqi1xMc1ojCBFlZrtBmga4oM8nxaq6ObRb/7AfWhvuEDCuUULU6hfL2C8Yr5asX grhWjAJjcgBOzrSG/cpgYtot75RW71xjJzl9M+q2IwHNp+Nq4qP3Me1ZyhrGfwS0gg4m reufpi61Ijr0zZ6PgWf3qw3n9MWf9J1pOpGzoki2F5qHxCTOdj7Pz0LG8TVnqpikbHk/ Q6px1ph6rpyItScZ9NFbGiBwSd/6QFEQRCFomkMM+Iq0X+iZKahFNvKp9eQWgCauJ/y9 IeGlmP0ADXWNfd1ygVDKCaUGClyNEwRxX0uLRwo08YE35ResqV2s7hdoB1FKihjQqUX/ 5W0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com header.b=hyyzQ+b0; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id b92si8570379wrd.172.2017.08.01.08.09.20; Tue, 01 Aug 2017 08:09:20 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com header.b=hyyzQ+b0; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 338A168A465; Tue, 1 Aug 2017 18:09:15 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-pf0-f194.google.com (mail-pf0-f194.google.com [209.85.192.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 079BC68A335 for <ffmpeg-devel@ffmpeg.org>; Tue, 1 Aug 2017 18:09:08 +0300 (EEST) Received: by mail-pf0-f194.google.com with SMTP id e3so2840299pfc.5 for <ffmpeg-devel@ffmpeg.org>; Tue, 01 Aug 2017 08:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=7wl4JB/VGgHiPwb0l3fP/D7DUw1jOm5HP1dyNAvclcs=; b=hyyzQ+b06KzeJ3uc3hbjPvkCMcantUwN3D9fZsZLebNM+vXR9QJ4LFioIyKi6Vrn56 E5+Zdqky3r9G7N7kl1zoaJaUwGBnufmltZFvLZ+6QGIjxKLPnlnpnMjb8zVvEBCLv1hc kinhnfJ07j24FseEOTK3Z3IPdC4l0iJlEcQ8tqJcC3scw8kXXSmpnCeiuvsjHu1Qcvee tL2d+8xhi/CMdKRdeCqfvv5Rt7AeWB838QLQQ/aLQqV4/2DK5AEZltoYy5s7xQdKRs0B O7YaKNDuiqAUhnQ6uv0k1xFPOakBMJGrit4sj3/XAPHj8nQCA6RGyKLu1WtmVKWxWifA NX4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=7wl4JB/VGgHiPwb0l3fP/D7DUw1jOm5HP1dyNAvclcs=; b=pnK74EBQoWexrMAB1PGJnAli1UMbbJy/gClJs5gAN48TBvqapgP5+4jKtJNeEPG1VP /2tDpDu8AQ29VWwm8O8a/2Lp1fRpJHlTHcDkHt6b4EExjEnKK9a4ILCMfYZLswZYnZEV hgM6YVRbK/xXKq1kZumk0b22A5jLAq7/fpA40+0yG1Po6PviAPG6jBHWmx+7I6z+Yehi 2ewfJbQjkoCrxaKibF6x5EvGMMIU44RTGOcdMS9/GA/ZxPxfmuW+T39+JbeaNI2Fm3Op ibAN/I64oRF4TqJa2Q0F739Mxowq/o9Qv4qT9ANR2ckVhsTCua8xaJxjrq87rft410iD PmZg== X-Gm-Message-State: AIVw111ufjr2InxJk767T6xQq798l8z5azDWVCIJY32eNVvruOC7DVS1 zr8cPP5/QUHDEgOL X-Received: by 10.98.131.143 with SMTP id h137mr19150149pfe.132.1501599710443; Tue, 01 Aug 2017 08:01:50 -0700 (PDT) Received: from localhost.localdomain ([114.124.148.110]) by smtp.gmail.com with ESMTPSA id s87sm59510709pfa.86.2017.08.01.08.01.48 for <ffmpeg-devel@ffmpeg.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 08:01:49 -0700 (PDT) From: Muhammad Faiz <mfcc64@gmail.com> To: ffmpeg-devel@ffmpeg.org Date: Tue, 1 Aug 2017 22:01:37 +0700 Message-Id: <20170801150137.8844-1-mfcc64@gmail.com> X-Mailer: git-send-email 2.13.2 MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <http://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <http://ffmpeg.org/pipermail/ffmpeg-devel/> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> |
Commit Message
Muhammad Faiz
Aug. 1, 2017, 3:01 p.m. UTC
Fix Ticket6519.
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
---
libavfilter/vf_ssim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 01.08.2017 17:01, Muhammad Faiz wrote: > Fix Ticket6519. > > Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> > --- > libavfilter/vf_ssim.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c > index c3c204268f..dfd276e015 100644 > --- a/libavfilter/vf_ssim.c > +++ b/libavfilter/vf_ssim.c > @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) > for (i = 0; i < s->nb_components; i++) > s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; > > - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); > + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); > if (!s->temp) > return AVERROR(ENOMEM); > s->max = (1 << desc->comp[0].depth) - 1; > I confirm that the command doesn't crash anymore and the reports of "invalid read/write" in Valgrind are gone. However there are still some "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? Regards, Tobias
On Wed, Aug 2, 2017 at 2:10 PM, Tobias Rapp <t.rapp@noa-archive.com> wrote: > On 01.08.2017 17:01, Muhammad Faiz wrote: >> >> Fix Ticket6519. >> >> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >> --- >> libavfilter/vf_ssim.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >> index c3c204268f..dfd276e015 100644 >> --- a/libavfilter/vf_ssim.c >> +++ b/libavfilter/vf_ssim.c >> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >> for (i = 0; i < s->nb_components; i++) >> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >> sum; >> >> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 >> + (desc->comp[0].depth > 8))); >> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >> if (!s->temp) >> return AVERROR(ENOMEM); >> s->max = (1 << desc->comp[0].depth) - 1; >> > > I confirm that the command doesn't crash anymore and the reports of "invalid > read/write" in Valgrind are gone. However there are still some "use of > uninitialized value" reports remaining. Maybe use av_mallocz_array? Changed locally with av_mallocz_array. Thank's.
On 02.08.2017 12:31, Muhammad Faiz wrote: > On Wed, Aug 2, 2017 at 2:10 PM, Tobias Rapp <t.rapp@noa-archive.com> wrote: >> On 01.08.2017 17:01, Muhammad Faiz wrote: >>> >>> Fix Ticket6519. >>> >>> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >>> --- >>> libavfilter/vf_ssim.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >>> index c3c204268f..dfd276e015 100644 >>> --- a/libavfilter/vf_ssim.c >>> +++ b/libavfilter/vf_ssim.c >>> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >>> for (i = 0; i < s->nb_components; i++) >>> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >>> sum; >>> >>> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 >>> + (desc->comp[0].depth > 8))); >>> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >>> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >>> if (!s->temp) >>> return AVERROR(ENOMEM); >>> s->max = (1 << desc->comp[0].depth) - 1; >>> >> >> I confirm that the command doesn't crash anymore and the reports of "invalid >> read/write" in Valgrind are gone. However there are still some "use of >> uninitialized value" reports remaining. Maybe use av_mallocz_array? > > Changed locally with av_mallocz_array. LGTM then. Thanks for the fix. Regards, Tobias
Hi, On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp <t.rapp@noa-archive.com> wrote: > On 01.08.2017 17:01, Muhammad Faiz wrote: > >> Fix Ticket6519. >> >> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >> --- >> libavfilter/vf_ssim.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >> index c3c204268f..dfd276e015 100644 >> --- a/libavfilter/vf_ssim.c >> +++ b/libavfilter/vf_ssim.c >> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >> for (i = 0; i < s->nb_components; i++) >> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >> sum; >> >> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * >> (1 + (desc->comp[0].depth > 8))); >> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >> if (!s->temp) >> return AVERROR(ENOMEM); >> s->max = (1 << desc->comp[0].depth) - 1; >> >> > I confirm that the command doesn't crash anymore and the reports of > "invalid read/write" in Valgrind are gone. However there are still some > "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? Wait wait, before we do that, which values are uninitialized and what are they used for? Ronald
On 02.08.2017 14:04, Ronald S. Bultje wrote: > Hi, > > On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp <t.rapp@noa-archive.com> wrote: > >> On 01.08.2017 17:01, Muhammad Faiz wrote: >> >>> Fix Ticket6519. >>> >>> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >>> --- >>> libavfilter/vf_ssim.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >>> index c3c204268f..dfd276e015 100644 >>> --- a/libavfilter/vf_ssim.c >>> +++ b/libavfilter/vf_ssim.c >>> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >>> for (i = 0; i < s->nb_components; i++) >>> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >>> sum; >>> >>> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * >>> (1 + (desc->comp[0].depth > 8))); >>> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >>> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >>> if (!s->temp) >>> return AVERROR(ENOMEM); >>> s->max = (1 << desc->comp[0].depth) - 1; >>> >>> >> I confirm that the command doesn't crash anymore and the reports of >> "invalid read/write" in Valgrind are gone. However there are still some >> "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? > > > Wait wait, before we do that, which values are uninitialized and what are > they used for? Reads into s->temp seem to use uninitialized values on x86-64 when vf_ssim.asm routines are used (-cpuflags all), see attached Valgrind report. When vf_ssim.asm is not used (-cpuflags 0) no "use of uninitialized value" is reported. The difference of the reported SSIM scores between my asm and non-asm test runs was <= 10^-6. Regards, Tobias
Hi, On Wed, Aug 2, 2017 at 8:45 AM, Tobias Rapp <t.rapp@noa-archive.com> wrote: > On 02.08.2017 14:04, Ronald S. Bultje wrote: > >> On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp <t.rapp@noa-archive.com> >> wrote: >> >>> On 01.08.2017 17:01, Muhammad Faiz wrote: >>> >>>> Fix Ticket6519. >>>> >>>> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >>>> --- >>>> libavfilter/vf_ssim.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >>>> index c3c204268f..dfd276e015 100644 >>>> --- a/libavfilter/vf_ssim.c >>>> +++ b/libavfilter/vf_ssim.c >>>> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >>>> for (i = 0; i < s->nb_components; i++) >>>> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >>>> sum; >>>> >>>> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * >>>> (1 + (desc->comp[0].depth > 8))); >>>> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >>>> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >>>> if (!s->temp) >>>> return AVERROR(ENOMEM); >>>> s->max = (1 << desc->comp[0].depth) - 1; >>>> >>>> >>>> I confirm that the command doesn't crash anymore and the reports of >>> "invalid read/write" in Valgrind are gone. However there are still some >>> "use of uninitialized value" reports remaining. Maybe use >>> av_mallocz_array? >>> >> >> >> Wait wait, before we do that, which values are uninitialized and what are >> they used for? >> > > Reads into s->temp seem to use uninitialized values on x86-64 when > vf_ssim.asm routines are used (-cpuflags all), see attached Valgrind > report. When vf_ssim.asm is not used (-cpuflags 0) no "use of uninitialized > value" is reported. > > The difference of the reported SSIM scores between my asm and non-asm test > runs was <= 10^-6. Which function is causing the warnings? Isit dsp->ssim_4x4_line() or dsp->ssim_end_line()? (My gut feeling tells me it's ssim_4x4_line(), but I don't understand why, since the result should be unused in ssim_end_line().) It's really important to understand the source and implication of these warnings before we silence them - they may be causing actual inaccuracies in the result, which we don't want. Ronald
On Wed, Aug 2, 2017 at 6:48 PM, Tobias Rapp <t.rapp@noa-archive.com> wrote: > On 02.08.2017 12:31, Muhammad Faiz wrote: >> >> On Wed, Aug 2, 2017 at 2:10 PM, Tobias Rapp <t.rapp@noa-archive.com> >> wrote: >>> >>> On 01.08.2017 17:01, Muhammad Faiz wrote: >>>> >>>> >>>> Fix Ticket6519. >>>> >>>> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >>>> --- >>>> libavfilter/vf_ssim.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >>>> index c3c204268f..dfd276e015 100644 >>>> --- a/libavfilter/vf_ssim.c >>>> +++ b/libavfilter/vf_ssim.c >>>> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >>>> for (i = 0; i < s->nb_components; i++) >>>> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >>>> sum; >>>> >>>> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * >>>> (1 >>>> + (desc->comp[0].depth > 8))); >>>> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >>>> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >>>> if (!s->temp) >>>> return AVERROR(ENOMEM); >>>> s->max = (1 << desc->comp[0].depth) - 1; >>>> >>> >>> I confirm that the command doesn't crash anymore and the reports of >>> "invalid >>> read/write" in Valgrind are gone. However there are still some "use of >>> uninitialized value" reports remaining. Maybe use av_mallocz_array? >> >> >> Changed locally with av_mallocz_array. > > > LGTM then. Thanks for the fix. Seems that this doesn't fix all cases. It fails with width=344. Will post new patch. Thank's.
On Wed, Aug 2, 2017 at 8:57 PM, Ronald S. Bultje <rsbultje@gmail.com> wrote: > Hi, > > On Wed, Aug 2, 2017 at 8:45 AM, Tobias Rapp <t.rapp@noa-archive.com> wrote: > >> On 02.08.2017 14:04, Ronald S. Bultje wrote: >> >>> On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp <t.rapp@noa-archive.com> >>> wrote: >>> >>>> On 01.08.2017 17:01, Muhammad Faiz wrote: >>>> >>>>> Fix Ticket6519. >>>>> >>>>> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com> >>>>> --- >>>>> libavfilter/vf_ssim.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >>>>> index c3c204268f..dfd276e015 100644 >>>>> --- a/libavfilter/vf_ssim.c >>>>> +++ b/libavfilter/vf_ssim.c >>>>> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >>>>> for (i = 0; i < s->nb_components; i++) >>>>> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >>>>> sum; >>>>> >>>>> - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * >>>>> (1 + (desc->comp[0].depth > 8))); >>>>> + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >>>>> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >>>>> if (!s->temp) >>>>> return AVERROR(ENOMEM); >>>>> s->max = (1 << desc->comp[0].depth) - 1; >>>>> >>>>> >>>>> I confirm that the command doesn't crash anymore and the reports of >>>> "invalid read/write" in Valgrind are gone. However there are still some >>>> "use of uninitialized value" reports remaining. Maybe use >>>> av_mallocz_array? >>>> >>> >>> >>> Wait wait, before we do that, which values are uninitialized and what are >>> they used for? >>> >> >> Reads into s->temp seem to use uninitialized values on x86-64 when >> vf_ssim.asm routines are used (-cpuflags all), see attached Valgrind >> report. When vf_ssim.asm is not used (-cpuflags 0) no "use of uninitialized >> value" is reported. >> >> The difference of the reported SSIM scores between my asm and non-asm test >> runs was <= 10^-6. > > > Which function is causing the warnings? Isit dsp->ssim_4x4_line() or > dsp->ssim_end_line()? (My gut feeling tells me it's ssim_4x4_line(), but I > don't understand why, since the result should be unused in > ssim_end_line().) It's really important to understand the source and > implication of these warnings before we silence them - they may be causing > actual inaccuracies in the result, which we don't want. Because ssim_4x4_line never reads sums, I think the warnings are caused by ssim_end_line. Looking at the asm code: ssim_4x4_line writes to sums 32-bytes per loop, while ssim_end_line reads sum0/sum1 64-bytes per loop + 16-bytes overread Thank's
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..dfd276e015 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; - s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); + s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1;