Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/3] avcodec/fmvc: buffer size is stride based not 4*width
Date: Fri, 2 Sep 2022 18:31:56 +0200
Message-ID: <20220902163156.GS2088045@pb2> (raw)
In-Reply-To: <20220613191319.GG396728@pb2>


[-- Attachment #1.1: Type: text/plain, Size: 4087 bytes --]

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 <anton@khirnov.net> wrote:
> > 
> > > Quoting Paul B Mahol (2022-06-13 11:34:44)
> > > > On Mon, Jun 13, 2022 at 11:10 AM Anton Khirnov <anton@khirnov.net>
> > > 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

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

  reply	other threads:[~2022-09-02 16:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 23:10 [FFmpeg-devel] [PATCH 1/3] avcodec/fmvc: Move frame allocation to a later stage Michael Niedermayer
2022-06-10 23:10 ` [FFmpeg-devel] [PATCH 2/3] avcodec/fmvc: buffer size is stride based not 4*width Michael Niedermayer
2022-06-11  8:47   ` Paul B Mahol
2022-06-11 14:55     ` Michael Niedermayer
2022-06-13  8:04       ` Paul B Mahol
2022-06-13  9:10         ` Anton Khirnov
2022-06-13  9:34           ` Paul B Mahol
2022-06-13  9:47             ` Anton Khirnov
2022-06-13 10:10               ` Paul B Mahol
2022-06-13 19:13                 ` Michael Niedermayer
2022-09-02 16:31                   ` Michael Niedermayer [this message]
2022-09-02 16:48                     ` Paul B Mahol
2022-09-04 21:42                       ` Michael Niedermayer
2022-09-08 20:54                         ` Michael Niedermayer
2022-06-10 23:10 ` [FFmpeg-devel] [PATCH 3/3] avcodec/fmvc: Require key frames to fill a non trivial part of the buffer Michael Niedermayer
2022-09-08 20:52 ` [FFmpeg-devel] [PATCH 1/3] avcodec/fmvc: Move frame allocation to a later stage Michael Niedermayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220902163156.GS2088045@pb2 \
    --to=michael@niedermayer.cc \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git