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 3429C4421B for ; Fri, 2 Sep 2022 16:45:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9166168B99B; Fri, 2 Sep 2022 19:45:53 +0300 (EEST) Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2E02068B406 for ; Fri, 2 Sep 2022 19:45:48 +0300 (EEST) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-344f8f691e2so9585047b3.2 for ; Fri, 02 Sep 2022 09:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=0fgpcgotdyxnnHdGhq4dXVCkrKTpocwYUrP3iAO3FeQ=; b=MBwg+IwPvY2rY1aPPcLsU7q2aEytNsz+KdVERRUahRlhWu62GtI09N77kx5JpSQqEb POHbzWYUXvsg7yYEpyqSTGXarkoCI+u2u7bcGzFvjVNec5uHmhyhACwOQhbClW3LNYbj Vjw/+BrhDMpje5S33vsFchyJ+I/SF5EDa2J4pctMKMTYBso/M4r5TUxwAwwhxLUpMV/5 ZluL+MUH1GfILIIj0BJKEAb7mwiZvantPW/rG1dinNw4jUgbRlemTtvrn8G0FUgHYx0n LcAPGamg7XeK7F+cd2VwS3Et7JOIPhp/Bw/CQm2ExZQub6yq9H+k5erbVsmCMVFy2MSR /2ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=0fgpcgotdyxnnHdGhq4dXVCkrKTpocwYUrP3iAO3FeQ=; b=Jn1lJU3wvne8ZOb6pegbOd3tDCnI/rHHu/YAu/HmF2ZWp0sABv9xOHLlb4p4FC1yR1 T884CxzVuvbcYSVKCZ2bdT1ZzG+Nurhcrof0kXyp6S3ZY5ocfh8g9+T5Ojrlr9f2IeMV BDnpBZbYGnp4SWq2vIezivLflPvsy/bVa8QZ2OjMdncQzQlcQPnMjbqeCsKnrrNUmdYo oQlzu3XvCgp5rcRaUEQWlM8FBmV9Nv3soTEMrBFyfreYENNMeiibDa+HV52ClTmdOp85 Fy5NFwOy010hBGiUof/T7x839XHc2EQUuOt4C2G1AvqBSHF9ze72IbFI7VrTX2Sj8D7U llfw== X-Gm-Message-State: ACgBeo31uyNulT+cT6U1x1/bF+t1tY3ViuWXXqonB2R7Ebxa9ObogaGH husucIOEyWs7WKU/iEri2tD2XuQl3wsKA9cmyKjtpLeW X-Google-Smtp-Source: AA6agR6KRkbexOqJjoJGerHalxFLOFIpH11tgB8cLn7aeoDdEWjK7KgQMCQpJSpSqdkMmI2ir5GNDodeBhsVKeZ5Y94= X-Received: by 2002:a81:1211:0:b0:335:ff9b:d981 with SMTP id 17-20020a811211000000b00335ff9bd981mr18048480yws.40.1662137146447; Fri, 02 Sep 2022 09:45:46 -0700 (PDT) MIME-Version: 1.0 References: <20220610231045.9760-1-michael@niedermayer.cc> <20220610231045.9760-2-michael@niedermayer.cc> <20220611145528.GD396728@pb2> <165511144493.13099.15326407212118049404@lain> <165511367625.5088.3673342022457056713@lain.khirnov.net> <20220613191319.GG396728@pb2> <20220902163156.GS2088045@pb2> In-Reply-To: <20220902163156.GS2088045@pb2> From: Paul B Mahol Date: Fri, 2 Sep 2022 18:48:57 +0200 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 2/3] avcodec/fmvc: buffer size is stride based not 4*width 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, Sep 2, 2022 at 6:32 PM Michael Niedermayer wrote: > On Mon, Jun 13, 2022 at 09:13:19PM +0200, Michael Niedermayer wrote: > > On Mon, Jun 13, 2022 at 12:10:44PM +0200, Paul B Mahol wrote: > > > On Mon, Jun 13, 2022 at 11:48 AM Anton Khirnov > wrote: > > > > > > > Quoting Paul B Mahol (2022-06-13 11:34:44) > > > > > On Mon, Jun 13, 2022 at 11:10 AM Anton Khirnov > > > > wrote: > > > > > > > > > > > Quoting Paul B Mahol (2022-06-13 10:04:04) > > > > > > > On Sat, Jun 11, 2022 at 4:55 PM Michael Niedermayer < > > > > > > michael@niedermayer.cc> > > > > > > > wrote: > > > > > > > > > > > > > > > On Sat, Jun 11, 2022 at 10:47:57AM +0200, Paul B Mahol wrote: > > > > > > > > > Have you actually tested this "change" ? > > > > > > > > > > > > > > > > On every file i found > > > > > > > > 6-methyl-5-hepten-2-one-CC-db_small.avi > > > > > > > > fmvcVirtualDub_small.avi > > > > > > > > skrzyzowanie4.avi > > > > > > > > fmvc-poc.avi > > > > > > > > > > > > > > > > are there any other files i should test it on ? > > > > > > > > > > > > > > > > > > > > > > Yes, the ones where stride != width. > > > > > > > > > > > > Give examples of such files then. And add more tests. > > > > > > > > > > > > You really should try to be more helpful if you care about this > code > > > > > > working. > > > > > > > > > > > > > > > Code works perfectly from start. There are always attempts to > break it. > > > > > Your attempts to belittle my work are futile. > > > > > > > > Perfect code should live in an external repository that is locked > > > > against modification. > > > > > > > > The ffmpeg repository is only for imperfect code that evolves with > time, > > > > and so requires changes. > > > > > > > > > > > I dunno what Michael attempts to fix. Decoder works fine with valid > files. > > > I doubt that encoder would encode random bytes or padding into valid > file > > > bitstream. > > > > the stride*4 / width*4 change was because of 2 things. > > first with AV_PIX_FMT_BGR24 the data stored is not width*4 > > > > stride is in units of 4 bytes for some reason, so stride*4 > > fixes this > > The 2nd issue is that the code addresses it by "s->stride * 4" > > so the buffer allocation should be stride*4 if we belive the > > other code is correct > > > > src = s->buffer; > > ... > > for (y = 0; y < avctx->height; y++) { > > ... > > src += s->stride * 4; > > > > width*4 works because its bigger than stride*4 for BGR24 which is what > all > > samples i have use. > > > > also > > ssrc = s->buffer; > > ... > > for (y = 0; y < avctx->height; y++) { > > ... > > ssrc += s->stride * 4; > > and > > dst = (uint32_t *)s->buffer; > > > > for (block = 0, y = 0; y < s->yb; y++) { > > int block_h = s->blocks[block].h; > > uint32_t *rect = dst; > > > > for (x = 0; x < s->xb; x++) { > > int block_w = s->blocks[block].w; > > uint32_t *row = dst; > > > > block_h = s->blocks[block].h; > > if (s->blocks[block].xor) { > > for (k = 0; k < block_h; k++) { > > uint32_t *column = dst; > > for (l = 0; l < block_w; l++) > > *dst++ ^= *src++; > > dst = &column[s->stride]; > > } > > } > > dst = &row[block_w]; > > ++block; > > } > > dst = &rect[block_h * s->stride]; > > } > > > > Again, if you have fmvc files with more odd widths or other pixel formats > > these would be very welcome. I can just say the code as is in git is > wrong > > and the buffer size as is in git is wrong. I noticed this when i added > > a check to see if the buffer is only partly filled and realized its > > always partly filled even when the whole image is actually touched > > If there are no objections aka noone sees a bug in this then id like > to apply this > Since when are partially filled buffers are bad thing? > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > What does censorship reveal? It reveals fear. -- Julian Assange > _______________________________________________ > 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". > _______________________________________________ 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".